Problems with a UDP connection

[wbickle]

I am running OpenCPN on a Raspberry Pi through a router to a PC (wireless) also running OpenCPN.

The router IP is 192.168.0.1
The Raspberry Pi server is 192.168.0.150 (a static address)
I have a GPS hockey puck connected to a USB port on the Raspberry Pi.
The PC client is 192.168.0.197

I can successfully establish a TCP connection between the two, using the following settings:

Server address: 0.0.0.0
Server DataPort: 10110
Output Box: Checked

Client address: 192.168.0.150
Client DataPort: 10110
Receive Input Box: Checked

That works, although I can't understand why I must use that address on the server.

Here's the issue: I can't find a combination of settings to establish a UDP connection.


When I click on the UDP protocol option on the server and apply, the debug window shows the messages continuing to stream blue/green, as they should.

When I click on the UDP protocol option on the client and apply, the debug window shows no traffic.

FWIW, I can successfully ping the server from the client side.

Any help would be appreciated.

Bill

[petter5]

All your ipadresses is on the same net range so they ate not routed.
Use your PI's ip address as server - Server address: 192.168.0.150
does it work now ?

Are you using openplotter distrubution on the PI ?

Originally Posted by wbickle

I am running OpenCPN on a Raspberry Pi through a router to a PC (wireless) also running OpenCPN.

The router IP is 192.168.0.1
The Raspberry Pi server is 192.168.0.150 (a static address)
I have a GPS hockey puck connected to a USB port on the Raspberry Pi.
The PC client is 192.168.0.197

I can successfully establish a TCP connection between the two, using the following settings:

Server address: 0.0.0.0
Server DataPort: 10110
Output Box: Checked

Client address: 192.168.0.150
Client DataPort: 10110
Receive Input Box: Checked

That works, although I can't understand why I must use that address on the server.

Here's the issue: I can't find a combination of settings to establish a UDP connection.


When I click on the UDP protocol option on the server and apply, the debug window shows the messages continuing to stream blue/green, as they should.

When I click on the UDP protocol option on the client and apply, the debug window shows no traffic.

FWIW, I can successfully ping the server from the client side.

Any help would be appreciated.

Bill

[wbickle]

Thanks for your response!

I tried changing the server address to 192.168.0.150, but that did not help.

One clarification:

When I set the server's protocol to UDP, the debug window continues to show data streaming out. It is the client's debug window which is blank. The server appears to be talking. The client is not hearing.

I am using OpenCPN, not openplotter.

Bill

[petter5]

Opencpn works great on a rapberry pi. When that is said, The openplotter distribution already have opencpn installed and ready to use with additional configuration and components already installed and configured so most things is just "plug and play" and you will get a lot of useful extra features already installed and configured with your system.

[muttnik]

You're falling into the "client" vs "server" confusion.

For UDP transmit ports, "Address" is where you want to send the data TO
For UDP receive ports, "Address" is semantically the address you are receiving it on but in practice OpenCPN doesn't care about the value in this field for "receive" udp connections (except for multicast which we'll ignore)

You have some options.
1. Broadcast the data from the pi. This sends to data to all machines on the network
2. Unicast the data. This sends just to your client
(3. multicast the data, but we'll ignore that for the moment).

(1) is how most commercial devices you would buy would do this and what many apps expecting "nmea data over udp" expect. To do this:
First find your network broadcast address, either from the ifconfig command on your pi (it will be preceded by "Bcast:" in the section for your wireless interface), from the configuration interface of your router, or by examining the properties of your network connection on the windows PC. For the latter I'm no expert at windows but if it only tells you a net mask ("IPv4 Subnet Mask"), if this is "255.255.255.0" then your broadcast address is 192.168.0.255. If for some perverse reason it's "255.255.0.0" your broadcast address is 192.168.255.255.

On the server (pi) set:
Protocol: UDP
Address: <the broadcast address you just worked out, e.g. 192.168.0.255>
Port: 10110
Click Transmit on this port.

On the client (pc) set:
Protocol: UDP
Address: 0.0.0.0 (actually it doesn't matter what you put here)
Port: 10110
Click Receive Input

Apply it and you should be done.

There's actually a section in the manual on this:
https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpnpencpn_user_manual:advanced_f eatures:network_repeater

However I'm not at all sure about that "x.x" syntax they're using: I took a quick scan through my (old) copy of the code and couldn't find any reference to that shortcut. Can anyone confirm or deny if that actually works?

Option (2): Send just to your PC.
On the pi:
Protocol: UDP
Address: 192.168.0.197 (remember, this is where you're sending *to*)
Port: 10110
Click "transmit on this port"

On the PC:
Protocol: UDP
Address: 0.0.0.0
Port: 10110
Click "receive data"

Now why would you do (2) when (1) is a far more common? There's a couple of reasons you might but the most important over a wifi connection is that unicast (i.e. sending to one receiver) allows the underlying wifi to make the connection "reliable" by retransmitting lost data. OTOH if your PC has an address assigned by dhcp which might change when you next boot it up, you might want to avoid the hassle of checking your server configuration each time and just go with broadcast.

And then there's multicast but let's not complicate things: try the above first. Maybe the broadcast option because it's simpler and more common

[muttnik]

Originally Posted by muttnik

https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpnpencpn_user_manual:advanced_f eatures:network_repeater

However I'm not at all sure about that "x.x" syntax they're using: I took a quick scan through my (old) copy of the code and couldn't find any reference to that shortcut. Can anyone confirm or deny if that actually works?

On the rather old 4.0.0 I have installed on the machine I have with me, the "x.x" syntax does worse than "not working": The nmea window shows it sending to <address>.x.x but tcpdump shows the traffic going off to some address which is obviously what you get if you don't validate input and somehow include the xs in the translation from string to address in network byte order. Does anyone know whether that syntax works in a recent version, or does the wiki need updating?

[wbickle]

Thanks so much for the wonderful response!

I tried option #1 and was able to communicate with the W10 PC, but not with the Chromebook machine. Interestingly, the ifconfig report for this Chromebook client says there were a lot of dropped RX packets. Switching to option #2 and attempting to communicate directly with the Chromebook didn't work either. I can ping the router from this Chromebook machine, but not the server!

Bill