OpenCPN 5.6.2/5.8.0 and UDP receiving on MacBook

[pnw2022]

Hi All,

I recently upgraded my WiFi from a Peplink MAX BR1 HW2 to a Peplink MAX BR1 5G. The newer unit has guest isolation enforced on the WiFi without any ability to turn it off. Basically WiFi clients can not ping/reach each other.

The WiFi guest isolation is a separate issue obviously, but it did encourage me to get around to a delayed project of separating out the NMEA to a separate VLAN. Before, with everything on the same vlan/subnet, OpenCPN was able to receive UDP on my MacBook M1.

With the new subnetting, and inter-vlan routing enabled, I can get the NMEA data in OpenCPN receiving on TCP, but I can not with UDP. I prefer to use UDP. Also TCP seems to have an issue where it loses connectivity after the laptop sleeps. Disabling/re-enabling the TCP connection in OpenCPN restores things, but not ideal.

Equipment:
WiFi: Peplink MAX BR1 5G
NMEA sender: Yacht Devices YDWG-02 nmea2000<=>wireless
OpenCPN: 2022 MacBook M1 Max


Network:
default vlan: 192.168.50.0/24 - MacBook
nmea vlan: 192.168.99.0/24 - YDWG-02


When I tcpdump on the MacBook (192.168.50.12) I can see the UDP packets:
05:58:42.603476 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 397
05:58:42.910392 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190
05:58:44.139174 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190
05:58:44.446794 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 432
05:58:45.061140 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190
05:58:45.675489 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 397
05:58:45.982514 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190
05:58:46.599470 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 432
05:58:46.904095 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190
05:58:47.519027 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 432
05:58:48.132675 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 190



To try things out, I tried setting OpenCPN to listen on some broadcast addresses as well, including:
192.168.99.23:10110 => the original single-subnet configuration.
192.168.99.255:10110
192.168.50.255;10110
255.255.255.255:10110
0.0.0.0:10110


In summary:
UDP works if both the YDGW-02 and the MacBook are on the same subnet.
UDP does NOT work if on separate subnets.
TCP works everywhere.

I first noticed after upgrading to OpenCPN 5.8.0 and this morning re-installed 5.6.2 and see the same behavior.

Is this expected behavior or something else?

I currently do not have a linux or windows machine to test this with.


Thanks,
- Mike

[pnw2022]

Quick update: I did find the buried switch to disable WiFi guest isolation on the Peplink. However I still would like to have the NMEA network segmented into its own VLAN, and use UDP.

[Be Free]

I'm going to take you at your word that there is actually a VLAN involved somewhere in this configuration. What you have showed so far are two different IPV4 networks.

Broadcast traffic is not routed between different networks so devices on the 192.168.50.0 network are not going to see broadcast packets from the 192.168.99.0 network.

Before we spend a lot of time on finding out why its not working, why do you want to segregate the traffic between your YDWG and your laptop? What is the problem you are trying to solve?

[wholybee]

My reply was going to be similar, that he needed to create a route on the Peplink for the UDP traffic. But he also shows a TCP dump from the mac, showing the UDP traffic is getting there.
We do see some UDP broadcast traffic, but we don't know if it is nmea data.

How is the YDWG set to UDP broadcast? iirc it only supports unicast, but i might be wrong.
I assume the YDWG logs into the peplink as a client? DHCP or static, and what is the gateway?

Can you view the routing table on the peplink?

[pnw2022]

Originally Posted by Be Free

I'm going to take you at your word that there is actually a VLAN involved somewhere in this configuration. What you have showed so far are two different IPV4 networks.

Broadcast traffic is not routed between different networks so devices on the 192.168.50.0 network are not going to see broadcast packets from the 192.168.99.0 network.

The Peplink has some features for forwarding broadcast, and even multicast, at layer3. The tcpdump I have in the original post is from vlan50/192.168.50.0 and shows the peplink UDP from vlan99/192.168.99.0 on the (wifi) wire.

tcpdump from vlan50: 192.168.50.0/24
05:58:42.603476 IP 192.168.99.23.10110 > 255.255.255.255.10110: UDP, length 397

Originally Posted by Be Free

Before we spend a lot of time on finding out why its not working, why do you want to segregate the traffic between your YDWG and your laptop? What is the problem you are trying to solve?

The peplink supports my full work-from-home office setup. So there are other devices, subnets, etc. in play, including ipsec tunnels, different public NAT outbound static IP addresses. For ease of use, and to keep things separated, I have separate WiFi station SSIDs (with separate vlans and subnets) for this.

At some point, I will probably put a RaspberryPi in for the boat as well and just want to keep all the NMEA/boat stuff better segmented.

My use case is when at anchor and having OpenCPN tracking enabled. So I can quickly check location or anchor drag/circles right from my primary laptop/workstation while also on one of those work networks. Basically forwarding the NMEA0183 GPS data, and only that, onto the other subnets.

From there, I also just started gettin curious as to why tcpdump can see the UDP packets, but OpenCPN can not.

I also played around with putting a 192.168.99.X/24 ip alias on my MacBook WiFi ethernet and some other things then figured it might be better to just ask here before delving further.

[pnw2022]

Originally Posted by wholybee

My reply was going to be similar, that he needed to create a route on the Peplink for the UDP traffic. But he also shows a TCP dump from the mac, showing the UDP traffic is getting there.
We do see some UDP broadcast traffic, but we don't know if it is nmea data.

How is the YDWG set to UDP broadcast? iirc it only supports unicast, but i might be wrong.
I assume the YDWG logs into the peplink as a client? DHCP or static, and what is the gateway?

Can you view the routing table on the peplink?

The Peplink is setup to hand out a static IP address over DHCP.

I fired up Wireshark and did a packet capture when on the same subnet and then the different subnets. Note the YDWG prefixes the sentences with 'YD'. I can see the 'YDGLL' in both packets.


From 192.168.99.23 to 192.168.50.X - 2 packets of 192-byte and 430-byte
Sample of the 192-byte:


Frame 2: 238 bytes on wire (1904 bits), 238 bytes captured (1904 bits) on interface en0, id 0
Ethernet II, Src: Espressi_d8:03:67 (60:01:94:d8:03:67), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 99
Internet Protocol Version 4, Src: 192.168.99.23, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 10110, Dst Port: 10110
Data (192 bytes)
Data: 245944474c4c2c343734322e333336312c4e2c31323232332e 343332302c572c31383033…
[Length: 192]


0000 ff ff ff ff ff ff 60 01 94 d8 03 67 81 00 00 63 ......`....g...c
0010 08 00 45 00 00 dc 6f 06 00 00 ff 11 28 4b c0 a8 ..E...o.....(K..
0020 63 17 ff ff ff ff 27 7e 27 7e 00 c8 07 fa 24 59 c.....'~'~....$Y
0030 44 47 4c 4c 2c 34 37 34 32 2e 33 33 36 31 2c 4e DGLL,4742.3361,N
0040 2c 31 32 32 32 33 2e 34 33 32 30 2c 57 2c 31 38 ,12223.4320,W,18
0050 30 33 35 37 2e 37 36 2c 41 2c 44 2a 37 41 0d 0a 0357.76,A,D*7A..
0060 24 59 44 52 4d 43 2c 31 38 30 33 35 37 2e 30 30 $YDRMC,180357.00
0070 2c 41 2c 34 37 34 32 2e 33 33 36 31 2c 4e 2c 31 ,A,4742.3361,N,1
0080 32 32 32 33 2e 34 33 32 30 2c 57 2c 30 2e 33 2c 2223.4320,W,0.3,
0090 32 37 36 2e 30 2c 31 31 30 39 30 33 2c 2c 45 2c 276.0,110903,,E,
00a0 44 2c 43 2a 36 43 0d 0a 24 59 44 5a 44 41 2c 31 D,C*6C..$YDZDA,1
00b0 38 30 33 35 37 2e 38 33 2c 31 31 2c 30 39 2c 32 80357.83,11,09,2
00c0 30 30 33 2c 2c 2a 36 37 0d 0a 24 59 44 56 54 47 003,,*67..$YDVTG
00d0 2c 32 37 36 2e 30 2c 54 2c 2c 4d 2c 30 2e 33 2c ,276.0,T,,M,0.3,
00e0 4e 2c 30 2e 36 2c 4b 2c 41 2a 30 31 0d 0a N,0.6,K,A*01..






From 192.168.50.23 (same subnet) - 2 packets of 192-byte and 430-byte
Sample of the 192-byte:


Frame 369: 234 bytes on wire (1872 bits), 234 bytes captured (1872 bits) on interface en0, id 0
Ethernet II, Src: Espressi_d8:03:67 (60:01:94:d8:03:67), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.50.23, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 10110, Dst Port: 10110
Data (192 bytes)
Data: 245944474c4c2c343734322e333335392c4e2c31323232332e 343239332c572c31383030…
[Length: 192]


0000 ff ff ff ff ff ff 60 01 94 d8 03 67 08 00 45 00 ......`....g..E.
0010 00 dc 6c d8 00 00 ff 11 5b 79 c0 a8 32 17 ff ff ..l.....[y..2...
0020 ff ff 27 7e 27 7e 00 c8 4f eb 24 59 44 47 4c 4c ..'~'~..O.$YDGLL
0030 2c 34 37 34 32 2e 33 33 35 39 2c 4e 2c 31 32 32 ,4742.3359,N,122
0040 32 33 2e 34 32 39 33 2c 57 2c 31 38 30 30 33 32 23.4293,W,180032
0050 2e 37 35 2c 41 2c 44 2a 37 42 0d 0a 24 59 44 52 .75,A,D*7B..$YDR
0060 4d 43 2c 31 38 30 30 33 32 2e 30 30 2c 41 2c 34 MC,180032.00,A,4
0070 37 34 32 2e 33 33 35 39 2c 4e 2c 31 32 32 32 33 742.3359,N,12223
0080 2e 34 32 39 33 2c 57 2c 30 2e 31 2c 31 34 32 2e .4293,W,0.1,142.
0090 39 2c 31 31 30 39 30 33 2c 2c 45 2c 44 2c 43 2a 9,110903,,E,D,C*
00a0 36 31 0d 0a 24 59 44 5a 44 41 2c 31 38 30 30 33 61..$YDZDA,18003
00b0 32 2e 38 35 2c 31 31 2c 30 39 2c 32 30 30 33 2c 2.85,11,09,2003,
00c0 2c 2a 36 31 0d 0a 24 59 44 56 54 47 2c 31 34 32 ,*61..$YDVTG,142
00d0 2e 39 2c 54 2c 2c 4d 2c 30 2e 31 2c 4e 2c 30 2e .9,T,,M,0.1,N,0.
00e0 33 2c 4b 2c 41 2a 30 42 0d 0a 3,K,A*0B..

[pnw2022]

Note: Looking closer, I see there is a 4-byte difference in overall packet size. I looked at the peplink and I have 192.168.50.0/24 on the default vlan, not vlan50. So this might be the vlan tagging and it's treating 192.168.50.0/24 as a trunk?

[pnw2022]

Okay, this was my fault - configuration/user error.

I was definitely seeing the UDP traffic as a vlan tagged packet on the trunk interface, hence why it could not be properly received by OpenCPN.

- Mike

[Be Free]

I'm glad you found it. VLANs are great when they work and a real pain to troubleshoot when they don't.