• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    EVOK TCP-Modbus only responding to loopback address

    Official EVOK API
    3
    6
    1488
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      alydersen last edited by

      Hi!

      After enabling "allow_register_access" I can access port 502 with telnet locally, but all other connections are not responded to. This used to work, but after an upgrade it seems to binding to the loopback interface only.
      evok.conf:

      [NEURON_1]
      global_id = 1                                                   ; Mandatory, REQUIRED TO BE UNIQUE
      allow_register_access = True
      scan_frequency = 10                                             ; Optional, 10 default, scanning frequency in [Hz]
      scan_enabled = True
      

      Output from netstat -lptu

      root@L513-sn24:/home/pi# netstat -lptu
      Active Internet connections (only servers)
      Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
      tcp        0      0 0.0.0.0:http            0.0.0.0:*               LISTEN      1001/nginx: master  
      tcp        0      0 0.0.0.0:http-alt        0.0.0.0:*               LISTEN      773/python          
      tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      997/sshd            
      tcp        0      0 localhost:502           0.0.0.0:*               LISTEN      867/unipi_tcp_serve 
      tcp6       0      0 [::]:http-alt           [::]:*                  LISTEN      773/python          
      tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      997/sshd            
      udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                           982/dhcpcd          
      udp        0      0 0.0.0.0:48767           0.0.0.0:*                           899/avahi-daemon: r 
      udp        0      0 0.0.0.0:mdns            0.0.0.0:*                           899/avahi-daemon: r 
      udp6       0      0 [::]:mdns               [::]:*                              899/avahi-daemon: r 
      udp6       0      0 [::]:58202              [::]:*                              899/avahi-daemon: r
      
      1 Reply Last reply Reply Quote 0
      • A
        alydersen last edited by

        BTW: Version is Repository:evok ActiveBranch:[master] PrecedingRelease:v.2.0.7b PrecedingRevision:326(aacb3a9) LatestCommit:Mon Sep 10 11:39:34 CEST 2018

        Martin Kudláček 1 Reply Last reply Reply Quote 0
        • Martin Kudláček
          Martin Kudláček @alydersen last edited by Martin Kudláček

          Hello @alydersen
          yes, this a security feature, because ModbusTCP doesn't have any autentization.

          The unipitcp service is maintained by systemd and the startup parameters are defined in /lib/systemd/system/unipitcp.service. You can modify the ExecStart attribut in this file and add -l 0.0.0.0 to start the service listening on all IP address, not just default loopback.

          The result should look like this:

          [Unit]
          Description=Unipi Neuron/Axon Modbus/Tcp Server
          Before=mervisrt.service
          Before=evok.service
          
          [Service]
          Type=simple
          Environment="FIRMWARE_UPDATE=1"
          EnvironmentFile=-/etc/default/unipi-modbus-tools
          ExecStartPre=/bin/sh -c 'if [ "${FIRMWARE_UPDATE}" = "1" ]; then /opt/unipi-bin/fwspi --auto; fi'
          ExecStart=/opt/unipi-bin/unipi_tcp_server -p 502 -l 0.0.0.0
          TimeoutStopSec=3
          SyslogLevel=debug
          SyslogIdentifier=unipi
          WorkingDirectory=/opt/unipi-bin
          
          Restart=always
          
          [Install]
          WantedBy=unipispi.target
          

          Then reload the systemd: systemctl daemon-reload
          And reload the unipitcp service: systemctl restart unipitcp

          Regards,
          Martin

          A 1 Reply Last reply Reply Quote 0
          • A
            alydersen @Martin Kudláček last edited by

            @martin-kudláček Thanks! That worked! Maybe you could update your docs?

            Martin Kudláček 1 Reply Last reply Reply Quote 0
            • Martin Kudláček
              Martin Kudláček @alydersen last edited by

              @alydersen That will be a tough decision where to put it, but I'll think of something.

              Thanks for the feedback,
              Martin

              T 1 Reply Last reply Reply Quote 0
              • T
                tomas_hora administrators @Martin Kudláček last edited by

                @martin-kudláček Already noted on the prepared knowledge base.

                1 Reply Last reply Reply Quote 1
                • First post
                  Last post