Shutdown with discovery errors for new e2 v5.0 ec-200 discovery packet "N/A" integer syntax

[gerrylusk]

It seems that since the v5 update for e2, tally is no longer working. I've narrowed it down to having an ec-200 on the system. Apparently, the discovery process (that query's the network with a '?') gets a response from the ec-200 that it does not like. The error is:

Tally.Run: discovery: expected integer

The responses from the frames: hostname=EC-200:N/A:System1:0:N/A:N/A:5.0.35479.ip-address=192.168.0.180.mac-address=00:0b:ab:98:ba:cf.type=EC-200. hostname=E2:9876:System1:0:1:00$13$95$15$e5$4f:5.0.1472.ip-address=192.168.0.175.mac-address=00:13:95:15:e5:4f.type=E2-32L.

If the ec-200 is removed from the network, Tally runs fine. As soon as the ec-200 is connected, tally fails. I have dumps in hex if you want more detail.

[SpComb]

Thanks!

A hex dump would indeed be better, the formatting of that binary data is hard to read (\0 -> .), but it looks like it's the N/A text in the integer fields like XMLPort, UnitID and VPCount that causes the problem.

Needs two fixes:

• Fix discovery:Packet.unpackHostname to ignore the N/A valued-fields to leave them zero-valued
• Fix discovery:Discovery.receiver to just ignore/log packets that fail to unpack, instead of erroring out the entire discovery process on any invalid packets

[gerrylusk]

Here you go:

[ddr@SquidPi ~]$ sudo /opt/qmsk-e2/bin/tally --discovery-interface=eth0 1969/12/31 16:06:00 Discovery: using interface eth0 broadcast address: 192.168.0.255 1969/12/31 16:06:00 tally: Update: sources=0 inputs=0 outputs=0 tallys=0 1969/12/31 16:06:00 Discovery.receiver: expected integer 1969/12/31 16:06:00 Discovery.run: stopped 1969/12/31 16:06:00 Tally.Run: discovery: expected integer [ddr@SquidPi ~]$

[ddr@SquidPi ~]$ sudo tcpdump -X port 40961 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes -7:-54:00.436268 IP SquidPi.37009 > 192.168.0.255.40961: UDP, length 2 0x0000: 4500 001e ffbb 4000 4011 b8ae c0a8 0015 E.....@.@....... 0x0010: c0a8 00ff 9091 a001 000a 8280 3f00 ............?. -7:-54:00.436772 IP 192.168.0.180.40961 > SquidPi.37009: UDP, length 115 0x0000: 4500 008f ac1c 4000 4011 0c28 c0a8 00b4 E.....@.@..(.... 0x0010: c0a8 0015 a001 9091 007b 51a7 686f 7374 .........{Q.host 0x0020: 6e61 6d65 3d45 432d 3230 303a 4e2f 413a name=EC-200:N/A: 0x0030: 5379 7374 656d 313a 303a 4e2f 413a 4e2f System1:0:N/A:N/ 0x0040: 413a 352e 302e 3335 3437 3900 6970 2d61 A:5.0.35479.ip-a 0x0050: 6464 7265 7373 3d31 3932 2e31 3638 2e30 ddress=192.168.0 0x0060: 2e31 3830 006d 6163 2d61 6464 7265 7373 .180.mac-address 0x0070: 3d30 303a 3062 3a61 623a 3938 3a62 613a =00:0b:ab:98:ba: 0x0080: 6366 0074 7970 653d 4543 2d32 3030 00 cf.type=EC-200. -7:-54:00.437021 IP 192.168.0.175.40961 > SquidPi.37009: UDP, length 133 0x0000: 4500 00a1 864d 4000 4011 31ea c0a8 00af E....M@.@.1..... 0x0010: c0a8 0015 a001 9091 008d d521 686f 7374 ...........!host 0x0020: 6e61 6d65 3d53 7175 6964 2045 323a 3938 name=Squid.E2:98 0x0030: 3736 3a54 7769 7463 6843 6f6e 3137 3a30 76:TwitchCon17:0 0x0040: 3a32 3a30 3024 3133 2439 3524 3135 2465 :2:00$13$95$15$e 0x0050: 3524 3466 3a35 2e30 2e31 3437 3200 6970 5$4f:5.0.1472.ip 0x0060: 2d61 6464 7265 7373 3d31 3932 2e31 3638 -address=192.168 0x0070: 2e30 2e31 3735 006d 6163 2d61 6464 7265 .0.175.mac-addre 0x0080: 7373 3d30 303a 3133 3a39 353a 3135 3a65 ss=00:13:95:15:e 0x0090: 353a 3466 0074 7970 653d 4532 2d33 324c 5:4f.type=E2-32L 0x00a0: 00 .

[gerrylusk]

Before you go digging in to the code, I've just received a fix from Barco that appears to make this not crash (ec-200 sends 0 not N/A). So on the next ec-200 firmware release, this should be fixed.

[SpComb]

Heh, that sounds like a good workaround too :)

However, I think I'll still keep this open, I'll just edit the title to make it slightly more general. It doesn't make sense for the entire tally thing to shutdown if it gets one invalid discovery packet.

[SpComb]

This should now be fixed in the development version (git master):

• 24 will just have the tally/server log any invalid packets, instead of shutting down ("crashing")

• 25 will parse the N/A fields as XMLPort=0, and ignore those hosts (per #26 to have the tally log an error before trying to connect to them)

I'll do an rc release next, but I'll need someone else to test it, as I don't actually have access to a real EC-200... There's also some other minor fixes/features waiting in git master for the next release.

[SpComb]

There's a new pre-release build with the discovery fixes here included: https://github.com/qmsk/e2/releases/tag/v0.5.0-alpha.1

I would appreciate if someone were able to test this with the unpatched 5.0 version on the EC-200 to verify that it's now able to handle the discovery responses.

[gerrylusk]

I've just tested 'tally' by downgrading my ec-200 to the release version 5.0.35479 and seeing the 'tally' fail. Then updated to your alpha version and it appears to work fine. I see GPIO and the web page changing. After installing Barco's 5.0 fix for the ec-200, 'tally' seems to still work as before. I launched 'server' as well, but I've not used it before. It appears to work. (Actually it looks kinda awesome and I'll look at it further on my next job.)