Ethoscopes not showing in UI

[roaldarbol]

This seems to be a very similar issue to #111 (and maybe #161 and #138) , but in case it's different I'll make a new issue. Feel free to merge.

I've been getting the same issue both for the provided RPi 3 ethoscope image and a newly created image for RPi 4.
I am able to boot the ethoscope just fine (no rainbow screen), it is connecting to the network (visible to the router as Unknown), and I can ping between the node and the ethoscope, but the ethoscope does not show up in the UI.

I've also tried to add it with the IP address, but to no avail.

It seems that the issue might have to do with the avahi-daemon.
avahi-browse --all shows no sign of the ethoscope. If I run systemctl status avahi-daemon I can see that it is disabled, but even after enabling it, the ethoscope still doesn't show up.

[alarm@node ~]$ arp -a
? (192.168.0.3) at 14:7d:da:31:b1:20 [ether] on eth0
_gateway (192.168.0.1) at c8:be:19:5a:03:95 [ether] on eth0

And after activating it with avahi-daemon -D (or editing and undoing the edit), and getting a good readout, it still doesn't show up.

[alarm@node ~]$ systemctl status ethoscope_node
* ethoscope_node.service - Ethoscope node server
     Loaded: loaded (/usr/lib/systemd/system/ethoscope_node.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-10-03 18:13:47 UTC; 37s ago
   Main PID: 302 (python)
      Tasks: 19 (limit: 4915)
     CGroup: /system.slice/ethoscope_node.service
             `-302 /usr/bin/python /opt/ethoscope-node/node_src/scripts/server.py

Meanwhile, the ethoscope just continues to print audits.

I tried searching in the other issues, but I haven't found an obvious solution. Any ideas what I'm missing?
It might be worth mentioning that I haven't updated the system or accessed whatever is in Resources as I don't have internet connection here.

[ggilestro]

By the look of it, it seems the router is blocking traffic on the network and the devices cannot see each other. Have a look at the instructions here.
Briefly, you can try ping the ethoscope from the node. If the ping does not come back, then it's either a problem with the router or a problem with the routing table on the node. If you are running the default image for the ethoscope and the default installation for the node, then the problem is likely to be the router.

[roaldarbol]

Thanks for the quick reply!

On the ethoscope:

[alarm@ETHOSCOPE000 ~]$ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.7  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::e65f:1ff:fe5b:9bc4  prefixlen 64  scopeid 0x20<link>
        ether e4:5f:01:5b:9b:c4  txqueuelen 1000  (Ethernet)
        RX packets 262  bytes 32575 (31.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 96  bytes 11852 (11.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On the node ifconfig gives:

 bash
[alarm@node ~]$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::dea6:32ff:fec8:bcdf  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:c8:bc:df  txqueuelen 1000  (Ethernet)
        RX packets 7271  bytes 654648 (639.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7004  bytes 668468 (652.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 250  bytes 20324 (19.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 250  bytes 20324 (19.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Pinging works just fine:

[alarm@node ~]$ ping 192.168.0.7 -c 5
PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_seq=1 ttl=64 time=0.382 ms
64 bytes from 192.168.0.7: icmp_seq=2 ttl=64 time=0.383 ms
64 bytes from 192.168.0.7: icmp_seq=3 ttl=64 time=0.347 ms
64 bytes from 192.168.0.7: icmp_seq=4 ttl=64 time=0.338 ms
64 bytes from 192.168.0.7: icmp_seq=5 ttl=64 time=0.366 ms

--- 192.168.0.7 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4121ms
rtt min/avg/max/mdev = 0.338/0.363/0.383/0.018 ms

And the ethoscope doesn't seem to be available:

[alarm@node ~]$ curl http://192.168.0.7:9000/id
curl: (7) Failed to connect to 192.168.0.7 port 9000: Connection refused

I'll give it a go again tomorrow. :-)

[ggilestro]

Then either the router is blocking internal traffic on port 9000 or the ethoscope service is not running on the ethoscope.

[roaldarbol]

Is there any way to check if the ethoscope service is running on the ethoscope? Then I'll start out with that test, then check firewalls - and otherwise I think I'll just get a new router (this one's quite old).

[ggilestro]

yes of course

systemctl status ethoscope_device

should return something like the following:

[alarm@ETHOSCOPE193 ethoscope-device]$ systemctl status ethoscope_device
* ethoscope_device.service - Ethoscope device server
     Loaded: loaded (/usr/lib/systemd/system/ethoscope_device.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-11-25 17:24:44 UTC; 8s ago
   Main PID: 2541 (python3)
      Tasks: 1 (limit: 1625)
     CGroup: /system.slice/ethoscope_device.service
             `-2541 /usr/bin/python3 /opt/ethoscope-device/src/scripts/device_server.py -D

Nov 25 17:24:44 ETHOSCOPE193 systemd[1]: Started Ethoscope device server.

From here.

[roaldarbol]

Ah, (this is from the RPi4 image) it seems it might be an opencv issue:

[alarm@ETHOSCOPE000 ~]$ systemctl status ethoscope_device
* ethoscope_device.service - Ethoscope device server
     Loaded: loaded (/usr/lib/systemd/system/ethoscope_device.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-11-21 23:47:13 UTC; 486ms ago
   Main PID: 605 (python3)
      Tasks: 1 (limit: 394)
        CPU: 470ms
     CGroup: /system.slice/ethoscope_device.service
             `-605 /usr/bin/python3 /opt/ethoscope-device/src/scripts/device_server.py -D

Nov 21 23:47:14 ETHOSCOPE000 python3[605]:     from ethoscope.stimulators.stimulators import DefaultStimulator
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:   File "/opt/ethoscope-device/src/ethoscope/stimulators/__init__.py", line 2, in <module>
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:     from . import stimulators
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:   File "/opt/ethoscope-device/src/ethoscope/stimulators/stimulators.py", line 3, in <module>
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:     from ethoscope.utils.description import DescribedObject
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:   File "/opt/ethoscope-device/src/ethoscope/utils/__init__.py", line 4, in <module>
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:     from . import io
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:   File "/opt/ethoscope-device/src/ethoscope/utils/io.py", line 7, in <module>
Nov 21 23:47:14 ETHOSCOPE000 python3[605]:     import cv2
Nov 21 23:47:14 ETHOSCOPE000 python3[605]: ModuleNotFoundError: No module named 'cv2'

When creating the image I couldn't get pacman-mirrors --fasttrack to work, it returned bash: pacman-mirrors: command not found, maybe that's the underlying cause here?

I've run out of SD cards (had to use the one with the Pi3 image), but just ordered a new one so I can confirm whether this is also the case on the RPi 3.

[roaldarbol]

On the RPi 3 things are working! I'll close this issue and refer to the RPi specific challenges in #170.