Ethernet AIS and radar into OpenCPN

[Daurin]

My Furuno FA50 AIS outputs directly to a Navnet vx2 display with radar (1724) as well as to an ethernet hub. NMEA output from the 1724 to OpenCPN (4.4.0) via serial connection and a Nolan port expander works fine for the core sentences (position, COG, SOG, heading), but there does not appear to be any way to get the 1724 to output AIS sentences (i.e. AIVDM, AIVDO) over the network. AIS data appear perfectly in the 1724, but not in OpenCPN.

As an alternative way to display AIS (and radar) data in OpenCPN, I have been trying to use the ethernet hub. I set my laptop IP to 172.31.24.4, and connected to the FA50 using a browser (172.31.24.3) to confirm it's address and port number (10000). So far, so good. Next, on the 1724, I queried the radar and found it on 172.31.3.3 (hostname: NAVNET3). Using UDP port utility Hercules, I sniffed each of these UDP IP addresses with port set to 10000 and local port 10021. I was able to see what I believe I should see (e.g. on 172.031.024.003 I get the following:

®!AIVDM,1,1,,B,4h6B>v1v8Q@bC15G?ChhTrQ02<08,0*74
!AIVDO,1,1,,,B5NLFi001HAF:IL<6F00mP:5WP06,0*01
$PFEC,idfnc,R,4*3C
$AIALR,094411.00,006,V,V,AIS: general failure*1D
n$GPGGA,164222,2638.4260,S,01509.4472,E,1,9,1.0,7, M,,M,,*66
$GPVTG,,T,192.3,M,0.1,N,0.2,K*6A
$GPZDA,164222,02,02,2018,-02,00*6D
$GPHDT,199.0,T*34
¯!AIVDO,1,1,,,B5NLFi000pAF:IL<6F40EQbUWP06,0*2D
o$GPGGA,164223,2638.4260,S,01509.4472,E,1,8,1.0,7, M,,M,,*66
$GPVTG,,T,183.0,M,0.2,N,0.4,K*6C
$GPZDA,164223,02,02,2018,-02,00*6C

..etc.)

However, when I add UDP connections with these specs in OpenCPN (172.31.003.003:10021 and 172.31.024.003:10021), I get nothing; no AIS targets, no radar functionality (in TX mode) in plugins AIS Radar View 1.0 and BR24Radar, respectively. I have also tried using the port suffix :10000 instead, but nothing.

I've uploaded the log (delete the pdf extension, it's a text file).

I have scoured this forum and Furuno's, and need a breakthrough! Thanks.

[nohal]

Daurin...
This is not how UDP works - Unlike TCP, where you to connect to a "server", it is a stateless broadcast protocol, where the "servers" send the data to the whole network all the time and the clients simply catch them if they want to, or ignore them.
Unless some of the data is a multicast (In which case you would need to know the multicast address to which your Furuno equipment transmits - should probably be seen in that Hercules utility, whatever that is, but sure in Wireshark), simply fill in 0.0.0.0 (or the IP of your laptop, 172.31.24.4) as the address and the correct port (I got a bit lost in whether you have seen the data on 10000, 10021 or both. If both, you of course need to set two connections).

Pavel

[Daurin]

Pavel, Thanks for your input. Let me see if I understand you. The UDP protocol is simply broadcasting the NMEA data over the ethernet network, independent of recipients or TCP connections; I get that part. But the laptop and OpenCPN surely need to be pointed at the correct IP address and port. When I look for AIS data on the network in Hercules (or whatever), I have to specify the address where I expect to find it, naturally.

How could 0.0.0.0, or the laptop's IP, be a valid address for OpenCPN to look for AIS and radar data on the LAN? You've lost me, I'm afraid.

Dirk

[muttnik]

Originally Posted by Daurin

when I add UDP connections with these specs in OpenCPN (172.31.003.003:10021 and 172.31.024.003:10021), I get nothing

Originally Posted by nohal

Unless some of the data is a multicast (In which case you would need to know the multicast address to which your Furuno equipment transmits - should probably be seen in that Hercules utility, whatever that is, but sure in Wireshark), simply fill in 0.0.0.0 (or the IP of your laptop, 172.31.24.4) as the address and the correct port

It *used* to be the case that opencpn actually just ignored whatever you put in the address field of a udp input and just used INADDR_ANY and the port. Has that changed? Obviously what nohal says is correct but changing to 0.0.0.0 might not make any difference because it's already defaulting to that.

Also as Nohal says, knowing the address data are being sent to would help (we need to treat multicast a bit differently to broadcast).

Make sure that netmask on everything is set to 255.255.0.0 and not 255.255.255.0 otherwise your computer and the furuno equipment won't be on the same subnet.

Lastly there are a number of old threads on furuno stuff, some of which may be relevant, some not. I *think* you can ignore stuff you might find about furuno data being dropped because of the headers which precede the data: I think it was Nohal who's rework of the nmea parsing should have sorted that out.

e.g.:
http://www.cruisersforum.com/forums/...-182634-4.html

[bcn]

I don't know if this issue is already addressed:
(furuno UDP use ascii null char before NMEA sentences #728)
https://github.com/OpenCPN/OpenCPN/pull/728

[nohal]

Originally Posted by Daurin

Pavel, Thanks for your input. Let me see if I understand you. The UDP protocol is simply broadcasting the NMEA data over the ethernet network, independent of recipients or TCP connections; I get that part. But the laptop and OpenCPN surely need to be pointed at the correct IP address and port. When I look for AIS data on the network in Hercules (or whatever), I have to specify the address where I expect to find it, naturally.

How could 0.0.0.0, or the laptop's IP, be a valid address for OpenCPN to look for AIS and radar data on the LAN? You've lost me, I'm afraid.

Dirk

Dirk...
No, what you write would be the case with TCP, where you would need to connect to the server. But UDP is broadcast, there is no server, nowhere to connect to. The packets are sent by the producer (Your Furuno, what you think is a "server") over the network, reaching "everybody". They are sent even if nobody actually needs them or listens to them.

The interested clients (In our case OpenCPN) simply have to wait for them, listening on the port on which they are coming, not actively connecting to some server or "looking for something".

Address 0.0.0.0 means "Listen on all my interfaces"
Own IP address means "Listen on my interface where this IP is assigned"
In effect this is of course the same as the packets are coming through the interface through which you are connected to the ethernet network.
As @muttnik writes, OpenCPN might be listening on "0.0.0.0" even by default, I really don't remember. But that is still not a reason not to set it up correctly.

There is an exception to the above. If the packets are multicast (RFC 5771), not broadcast, which means something like "targeting only subscribed clients" you must "subscribe" to it by explicitly specifying the same multicast address on the client as the producer of the data sends the packets to. These are special IPs from the 224.0.0.0 - 239.255.255.255 range, always. And you would probably see it in the Hercules tool, again, whatever that is.

There is a good and more detailed explanation of what we are talking about at http://stripydog.blogspot.com.ar/201...cal-route.html if you are interested.
Pavel

[muttnik]

Originally Posted by Daurin

But the laptop and OpenCPN surely need to be pointed at the correct IP address and port. When I look for AIS data on the network in Hercules (or whatever), I have to specify the address where I expect to find it, naturally.

How could 0.0.0.0, or the laptop's IP, be a valid address for OpenCPN to look for AIS and radar data on the LAN?

I'm not familiar with Hercules (except the Kevin Sorbo version, natch) and I think I got confused with some of what you were explaining so I'll just address the last part of the question.

0.0.0.0 *isn't* really a valid address. In the most common programming interfaces it's a shorthand for saying "any address that's relevant to this computer". Sometimes a computer might have lots of addresses and you're interested in receiving packets sent to any one of them: that's the normal use case for this. A process listening for packets to "any address" will also receive "broadcasts" sent to the subnet's "broadcast address". This is a special address meaning "all systems connected to this sub-network" and is often (but not always) the way that NMEA data are transmitted over UDP. The broadcast address is the "network part" of the address with (these days) all "1"s in the "host" part. How do you know which is the "network part" as opposed to the "host part"? You logically "and" ("&") an address with its subnet mask, which is why having your subnet mask set correctly counts.

Bits that are binary "1" in the subnet mask are part of the subnet, bits that are "0" are the host part. In an IPv4 address each "octet" is eight binary bits and 255 in decimal is 11111111 in binary. So if your address is 172.31.3.3 and your subnet is 255.255.0.0, the network part is "172.31" (where the subnet mask's "1"s are) and host part (ie the address of an individual system within the subnet) is 3.3. The broadcast address (which means "all machines on my network" is 172.31.255.255 (ie the network part with the appended host part all binary 1s). But to correctly identify the broadcast address, machines need their subnet mask set correctly.

and multicast is something else entirely :-)

[muttnik]

Nohal beat me to it....

[Daurin]

Okay. Thank you both for the background. This is beginning to make a little more sense to me now, though I still have much to learn. (COM ports are so much easier...)

Anyway, I have tried to reconfig OpenCPN to look at ports 10000 and 10021 (the latter was a port number I picked up on another forum on this topic; seemed to work for Hercules where 10000 did not, despite the fact that the FA50 shows 10000 as the "NAVNET Port Number" (see screen grab of FA50 config below). In OpenCPN, I set the UDP IP to 0.0.0.0 and then the laptop's IP 172.31.24.4 with these ports, and still no luck. There does not appear to be any provision in OpenCPN for specifying the subnet mask (see screen grab), but the FA50 is clearly set to subnet mask 255.255.0.0, as in my laptop.

OpenCPN results and configs are shown in another screen grab, and I have included a Wireshark capture (again, strip off the .pdf extension). Based on what I saw in Wireshark for the MAC that matches the FA50, I also tried setting OpenCPn to look at port 10033. Interesting that the other Furuno MAC shown in Wireshark (presumably the 1724 chartplotter/radar) is shown as ARP, not UDP...

[nohal]

Dirk...
1) Use either 0.0.0.0 or 172.31.24.4, not both, in your OpenCPN settings. Delete one of the connections you configured for each of the ports.
2) Looking at your capture, your Furunos are broadcasting the data over UDP - 172.31.24.3 is broadcasting the AIS-only data on ports 10021 and 10033, 172.31.3.3 is broadcasting GPGGA (Only position, no SOG/COG) sentences on port 10021. So adjust your settings for that - Port 10000 is completely wrong. As a note, having only GPGGA available is insufficient for "normal" operation as it is missing the speed and course info.
3) There is nothing that looks like some data from a broadband radar, only NMEA0183 on the two above ports. You can stop using the radar plugin as there is no chance it will do something in your current configuration.
4) The "AIS radar plugin" is a useless indicator of things working or not, use the NMEA Debug window (Checkbox in the upper part of the Connections tab) to check whether you get some data or not.
5) Make sure the netmask on your notebook is set to "255.255.0.0"
6) On the screenshot above, you clearly can't see anything - Port 10000 is wrong and you have disabled listening on port 10021 where there is a chance you could receive something.

One more correction - I have looked again at the packets from 172.31.3.3 and there is some more data than GGA in some of them so you should probably have all the needed info.

Pavel

[Daurin]

Pavel,
Thanks for bearing with me.
My laptop IPv4 subnet mask has been set to 255.255.0.0 all along. I have again tried both 0.0.0.0 and 172.31.24.4 in OpenCPN after deleting all other UDP connections. I tried them first using port 10021, then using 10033. In the NMEA debug window, I see only data coming in from COM1 (or nothing if I unplug the serial connection).
Dirk

[DotDun]

Originally Posted by nohal

Dirk...
No, what you write would be the case with TCP, where you would need to connect to the server. But UDP is broadcast, there is no server, nowhere to connect to. The packets are sent by the producer (Your Furuno, what you think is a "server") over the network, reaching "everybody". They are sent even if nobody actually needs them or listens to them.

The interested clients (In our case OpenCPN) simply have to wait for them, listening on the port on which they are coming, not actively connecting to some server or "looking for something".

Address 0.0.0.0 means "Listen on all my interfaces"
Own IP address means "Listen on my interface where this IP is assigned"
In effect this is of course the same as the packets are coming through the interface through which you are connected to the ethernet network.
As @muttnik writes, OpenCPN might be listening on "0.0.0.0" even by default, I really don't remember. But that is still not a reason not to set it up correctly.

There is an exception to the above. If the packets are multicast (RFC 5771), not broadcast, which means something like "targeting only subscribed clients" you must "subscribe" to it by explicitly specifying the same multicast address on the client as the producer of the data sends the packets to. These are special IPs from the 224.0.0.0 - 239.255.255.255 range, always. And you would probably see it in the Hercules tool, again, whatever that is.

There is a good and more detailed explanation of what we are talking about at Water and Electrickery: Cape Multicast: The Logical Route if you are interested.
Pavel

UDP is a layer 4 protocol and can be sent on unicast packets or broadcast packets. UDP in and of itself doesn't determine that, the application does.

I assume you mean the sender (Furuno) is transmitting UDP packets on a broadcast address?

[nohal]

Originally Posted by Daurin

Pavel,
Thanks for bearing with me.
My laptop IPv4 subnet mask has been set to 255.255.0.0 all along. I have again tried both 0.0.0.0 and 172.31.24.4 in OpenCPN after deleting all other UDP connections. I tried them first using port 10021, then using 10033. In the NMEA debug window, I see only data coming in from COM1 (or nothing if I unplug the serial connection).
Dirk

Dirk...
Looking closer at your packet capture, what Furuno produces is a bit weird as there is a binary header in the UDP payload of every packet before the first NMEA0183 sentence starts. As this binary data is mostly zeros, which by accident also means "end of string", it is pretty likely you will, except the configuration which now should be correct, also need a patched version of OpenCPN (With the patch already mentioned by bcn earlier in this thread)
I will test it tomorrow and let you know.

Pavel

[nohal]

Originally Posted by DotDun

UDP is a layer 4 protocol and can be sent on unicast packets or broadcast packets. UDP in and of itself doesn't determine that, the application does.

I assume you mean the sender (Furuno) is transmitting UDP packets on a broadcast address?

Yes, as you can see from the attached capture, both the units are broadcasting to 172.31.255.255. Unicast would make very little sense in this scenario as it would need manual configuration of every inter device connection on the network. Something pretty unimaginable in the marine environment in general and would bring the same problems TCP has while effectively also removing the benefits of UDP...
Mutlicast sure would make much more sense, but besides OpenCPN, it is supported by only a few other navigation products.

So they better implemented broadcast with broken payload

[DotDun]

Originally Posted by nohal

Yes, as you can see from the attached capture, both the units are broadcasting to 172.31.255.255. Unicast would make very little sense in this scenario as it would need manual configuration of every inter device connection on the network. Something pretty unimaginable in the marine environment in general and would bring the same problems TCP has while effectively also removing the benefits of UDP...
Mutlicast sure would make much more sense, but besides OpenCPN, it is supported by only a few other navigation products.

So they better implemented broadcast with broken payload

Broken by what standard?

I'm not aware of any standard for NMEA0183 over IP, hence Furuno is doing their own thing.