Debugging OCPN Connections

[RobbieW]

OCPN 3.2.2 on Windows 7

I'm trying to figure out what is going on between OCPN and kplex, see my blog for some detail of this.

There seems to be a glitch when I enable output on a TCP connection that is receiving a multiplex of GPS and AIS messages from kplex. I've added DebugNMEA=1500 to opencpn.ini, here's the output:

21:45:54: 2013-08-25
21:45:54:  ------- Starting OpenCPN -------
21:45:54: Version 3.2.2 Build 2013-05-08
21:45:54: wxWidgets version: wxWidgets 2.8.12
21:45:54: MemoryStatus:  mem_total: 3002 mb,  mem_initial: 7 mb
21:45:54: SData_Locn is C:\Program Files\OpenCPN\
21:45:54: Using existing Config_File: C:\ProgramData\opencpn\opencpn.ini
21:45:54: Styles loading from C:\Program Files\OpenCPN\uidata\styles.xml
21:45:54: No styles found at: C:\ProgramData\opencpn\
21:45:54: No styles found at: C:\ProgramData\opencpn\.opencpn\
21:45:54: Setting Viewpoint Lat/Lon 38.2002, 13.337
21:45:54: Setting Ownship Lat/Lon 38.2005, 13.3338
21:45:54: System default Language:  en_GB
9:45:54 PM: Opencpn language set to:  en_US
9:45:54 PM: ChartSymbols loaded from C:\Program Files\OpenCPN\s57data\chartsymbols.xml
9:45:54 PM: Using s57data in C:\Program Files\OpenCPN\s57data
9:45:54 PM: Setting Viewpoint Lat/Lon 38.2002, 13.337
9:45:54 PM: Setting Ownship Lat/Lon 38.2005, 13.3338
9:45:54 PM: Opening NMEA Datastream TCP:192.168.20.10:10110
9:45:54 PM: PlugInManager searching for PlugIns in location C:\Program Files\OpenCPN\plugins
9:45:54 PM: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/dashboard_pi.dll
9:45:54 PM:   C:\Program Files\OpenCPN\plugins/dashboard_pi.dll Version detected: 106
9:45:54 PM: PlugInManager: Loading PlugIn: C:\Program Files\OpenCPN\plugins/grib_pi.dll
9:45:54 PM:   C:\Program Files\OpenCPN\plugins/grib_pi.dll Version detected: 107
9:45:55 PM: MEH.NMEA Sentence received...$GPRMC,194554,A,3812.0278,N,01320.0251,E,0.1,183.8,250813,3,E*6E 
9:45:55 PM: Changing NMEA Datasource for GPRMC to TCP:192.168.20.10:10110 (Priority: 0)
9:45:55 PM: PostProcess NMEA with valid position
9:45:55 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,331.9,-0.0,A*0F 
9:45:55 PM: Changing NMEA Datasource for GPRMB to TCP:192.168.20.10:10110 (Priority: 0)
9:45:55 PM: OpenGL-> Renderer String: Mobile Intel(R) 4 Series Express Chipset Family
9:45:55 PM: OpenGL-> Detected Intel renderer, disabling stencil buffer
9:45:55 PM: OpenGL-> Detected Intel renderer, disabling FBO
9:45:55 PM: OpenGL-> Framebuffer Objects unavailable
9:45:55 PM: OpenGL-> Using Depth buffer clipping
9:45:55 PM: OpenGL-> Estimated Max Resident Textures: 98
9:45:55 PM: ChartDB Cache policy:  Application target is 1024 MBytes
9:45:55 PM: Loading chart db version: V017
9:45:55 PM: Chartdb: Chart directory list follows
9:45:55 PM:   Chart directory #0: C:\CM93_2 All (updt 2010 05)
9:45:55 PM: GPS Watchdog Timeout is: 6 sec.
9:45:55 PM: Initializing Chart C:\CM93_2 All (updt 2010 05)\
9:45:55 PM: CM93Composite Chart Root is C:\CM93_2 All (updt 2010 05)\\
9:45:55 PM: Loaded CM93 Dictionary from C:\CM93_2 All (updt 2010 05)\\
9:45:55 PM: Loading CM93 cell C:\CM93_2 All (updt 2010 05)\\03300000/F/03840040.F
9:45:55 PM: Loading CM93 cell C:\CM93_2 All (updt 2010 05)\\03300000/E/03840039.E
9:45:55 PM: Loading CM93 cell C:\CM93_2 All (updt 2010 05)\\03300000/E/03840040.E
9:45:55 PM: MEH.NMEA Sentence received...$GPRMC,194555,A,3812.0278,N,01320.0250,E,0.1,181.2,250813,3,E*66 
9:45:55 PM: PostProcess NMEA with valid position
9:45:55 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.0,-0.1,A*04 
9:45:56 PM: MEH.NMEA Sentence received...$GPRMC,194556,A,3812.0278,N,01320.0251,E,0.0,187.4,250813,3,E*65 
9:45:56 PM: PostProcess NMEA with valid position
9:45:56 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.0,-0.1,A*04 
9:45:57 PM:    ***HDx Watchdog timeout...
9:45:57 PM:    ***HDT Watchdog timeout...
9:45:57 PM:    ***SAT Watchdog timeout...
9:45:57 PM: MEH.NMEA Sentence received...$GPRMC,194557,A,3812.0278,N,01320.0250,E,0.1,184.6,250813,3,E*65 
9:45:57 PM: PostProcess NMEA with valid position
9:45:57 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:45:58 PM: MEH.NMEA Sentence received...$GPRMC,194558,A,3812.0278,N,01320.0250,E,0.1,186.3,250813,3,E*6D 
9:45:58 PM: PostProcess NMEA with valid position
9:45:58 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:45:59 PM: MEH.NMEA Sentence received...$GPRMC,194559,A,3812.0278,N,01320.0250,E,0.1,179.9,250813,3,E*66 
9:45:59 PM: PostProcess NMEA with valid position
9:45:59 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.1,A*07 
9:46:00 PM: MEH.NMEA Sentence received...$GPRMC,194600,A,3812.0277,N,01320.0249,E,0.1,170.0,250813,3,E*6E 
9:46:00 PM: PostProcess NMEA with valid position
9:46:00 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.1,A*07 
9:46:01 PM: EnumerateSerialPorts() Found Garmin USB Driver.
9:46:01 PM: MEH.NMEA Sentence received...$GPRMC,194601,A,3812.0277,N,01320.0250,E,0.0,164.1,250813,3,E*62 
9:46:01 PM: PostProcess NMEA with valid position
9:46:01 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.4,-0.0,A*01 
9:46:02 PM: MEH.NMEA Sentence received...$GPRMC,194602,A,3812.0277,N,01320.0250,E,0.0,186.8,250813,3,E*64 
9:46:02 PM: PostProcess NMEA with valid position
9:46:02 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.4,-0.0,A*01 
9:46:03 PM: MEH.NMEA Sentence received...$GPRMC,194603,A,3812.0277,N,01320.0250,E,0.0,220.0,250813,3,E*62 
9:46:03 PM: PostProcess NMEA with valid position
9:46:03 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.2,-0.0,A*07 
9:46:04 PM: MEH.NMEA Sentence received...$GPRMC,194604,A,3812.0276,N,01320.0250,E,0.1,183.7,250813,3,E*68 
9:46:04 PM: PostProcess NMEA with valid position
9:46:04 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.2,-0.0,A*07 
9:46:05 PM: MEH.NMEA Sentence received...$GPRMC,194605,A,3812.0276,N,01320.0251,E,0.1,188.5,250813,3,E*61 
9:46:05 PM: PostProcess NMEA with valid position
9:46:05 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.1,A*07 
9:46:06 PM: MEH.NMEA Sentence received...$GPRMC,194606,A,3812.0276,N,01320.0250,E,0.1,203.2,250813,3,E*64 
9:46:06 PM: PostProcess NMEA with valid position
9:46:06 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.1,A*07 
9:46:07 PM: MEH.NMEA Sentence received...$GPRMC,194607,A,3812.0275,N,01320.0251,E,0.1,190.9,250813,3,E*65 
9:46:07 PM: PostProcess NMEA with valid position
9:46:07 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.0,A*06 
9:46:08 PM: MEH.NMEA Sentence received...$GPRMC,194608,A,3812.0275,N,01320.0252,E,0.1,171.8,250813,3,E*67 
9:46:08 PM: PostProcess NMEA with valid position
9:46:08 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.3,-0.0,A*06 
9:46:09 PM: MEH.NMEA Sentence received...$GPRMC,194609,A,3812.0274,N,01320.0252,E,0.1,157.1,250813,3,E*6A 
9:46:09 PM: PostProcess NMEA with valid position
9:46:09 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:46:10 PM: MEH.NMEA Sentence received...$GPRMC,194610,A,3812.0274,N,01320.0252,E,0.1,171.1,250813,3,E*66 
9:46:10 PM: PostProcess NMEA with valid position
9:46:10 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:46:11 PM: MEH.NMEA Sentence received...$GPRMC,194611,A,3812.0273,N,01320.0253,E,0.1,190.2,250813,3,E*6D 
9:46:11 PM: PostProcess NMEA with valid position
9:46:11 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:46:12 PM: MEH.NMEA Sentence received...$GPRMC,194612,A,3812.0273,N,01320.0254,E,0.1,176.1,250813,3,E*62 
9:46:12 PM: PostProcess NMEA with valid position
9:46:12 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.1,-0.1,A*05 
9:46:13 PM: MEH.NMEA Sentence received...$GPRMC,194613,A,3812.0273,N,01320.0254,E,0.1,191.9,250813,3,E*62 
9:46:13 PM: PostProcess NMEA with valid position
9:46:13 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,331.8,-0.1,A*0F 
9:46:14 PM: Closing NMEA Datastream TCP:192.168.20.10:10110
9:46:14 PM: Opening NMEA Datastream TCP:192.168.20.10:10110
9:46:21 PM:    ***GPS Watchdog timeout...
9:46:21 PM:    ***VAR Watchdog timeout...
9:46:23 PM: EnumerateSerialPorts() Found Garmin USB Driver.
9:46:35 PM: Closing NMEA Datastream TCP:192.168.20.10:10110
9:46:40 PM: Opening NMEA Datastream TCP:192.168.20.10:10110
9:46:40 PM: MEH.NMEA Sentence received...$GPRMC,194640,A,3812.0269,N,01320.0257,E,0.1,87.6,250813,3,E*55 
9:46:40 PM: PostProcess NMEA with valid position
9:46:40 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,332.0,-0.1,A*04 
9:46:41 PM: MEH.NMEA Sentence received...$GPRMC,194641,A,3812.0269,N,01320.0257,E,0.0,103.0,250813,3,E*6E 
9:46:41 PM: PostProcess NMEA with valid position
9:46:41 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,331.9,-0.0,A*0F 
9:46:42 PM: MEH.NMEA Sentence received...$GPRMC,194642,A,3812.0269,N,01320.0258,E,0.1,75.8,250813,3,E*5B 
9:46:42 PM: PostProcess NMEA with valid position
9:46:42 PM: MEH.NMEA Sentence received...$GPRMB,A,0.01,L,START ,MOB   ,3812.040,N,01320.017,E,0.0,331.9,-0.0,A*0F 
9:46:43 PM: PlugInManager: Deactivating PlugIn: C:\Program Files\OpenCPN\plugins/dashboard_pi.dll
9:46:43 PM: PlugInManager: Deactivating PlugIn: C:\Program Files\OpenCPN\plugins/grib_pi.dll
9:46:43 PM: opencpn::MyFrame exiting cleanly.
9:46:43 PM: Closing NMEA Datastream TCP:192.168.20.10:10110
9:46:43 PM: Chart cache purge
9:46:43 PM: PlugInManager: UnLoading PlugIn: C:\Program Files\OpenCPN\plugins/dashboard_pi.dll
9:46:43 PM: PlugInManager: UnLoading PlugIn: C:\Program Files\OpenCPN\plugins/grib_pi.dll
9:46:43 PM: Chart cache purge
9:46:43 PM: LOGBOOK:  2013-08-25 19:46:43 UTC OFF: Lat   38.20045 Lon   13.33376 COG   75.80000 SOG   0.10
9:46:43 PM: opencpn::MyApp exiting cleanly...

What that should show is a sequence of events starting with OCPN reading from a TCP connection, then I enable output on that connection. All data ceases to flow into OCPN, looking at the NMEA Debug window. Then I disable output on the connection and data starts to flow in again, kplex has not failed during this sequence.

So, what can I do to figure out whats going on ?

Thanks ...

[muttnik]

I've been taking a look with tcpdump between layers of epoxy this afternoon. Don't have the ocpn source with me and on a dodgy mobile phone connection so can't download but...

Opening the options menu and just clicking "OK" again we see ocpn send a fin, closing the connection, then a new syn to the server. Connection is re-established and everything is good.

If instead we set opencpn to output data then click ok, we see the fin sent to close the existing connection, but no new syn is sent.

In other words, opencpn severs the old connection but does not try to re-establish a new connection.

My hypothesis which perhaps someone with the source can confirm or deny, is that when you check the box to transmit data, rather than creating a client connection to a remote server, opencpn assumes you want to create a server.

My results might be a bit skewed by testing on a single machine and maybe opencpn is doing something clever like seeing that the data address I've specified for the connection is local, but I highly doubt it: I don't recall seeing a getifaddrs() in the datastream code. wxwidgets 2.8 net stuff, whilst giving the obvious cross-platform benefits, does limit the devs in the amount of clever network stuff they can do and still keep the code from being a hideous tangle of ifdefs.

[nohal]

muttnik...
Exactly right.

Pavel

[bdbcat]

RobbieW...

In OpenCPN, a single TCP connection can be either a server(i.e. output enabled) or a client (i.e. input enabled), but not both at the same time.

Not sure who one would want to connect to in such a full duplex manner, so to speak. I suppose we could arrange to so connect to another instance of OpenCPN, but that seems of limited usefulness.

Does kplex want to handle both client and server connections on one address?

Dave

[RobbieW]

Originally Posted by bdbcat

RobbieW...

In OpenCPN, a single TCP connection can be either a server(i.e. output enabled) or a client (i.e. input enabled), but not both at the same time.

Not sure who one would want to connect to in such a full duplex manner, so to speak. I suppose we could arrange to so connect to another instance of OpenCPN, but that seems of limited usefulness.

Does kplex want to handle both client and server connections on one address?

Dave

Thanks Dave,
The reality is more that kplex CAN handle input and output through the same address, which is why I was trying to do that.

I have a working set up using two OCPN connections however, one in and one out. These connect with two kplex instances running on my router.

Given that there is a solution, once the constraints are properly understood, might I suggest a fix to the documentation to make the constraint clearer? Something like...

from:
* OpenCPN can also work as a TCP server, with the current restriction, that it is only possible to use one client per server. A suitable setup is a connection with the address set to.0.0.0.0:10110, and output activated. A client simply connects to the IP address of the server using the same port as the server, 10110 in this case. It is not a good idea to set up a connection, to receive on the server address. TCP set up this way works, but UDP, described below, is the recommended way.

to:
* OpenCPN can also work as a TCP server when the output option of a connection is selected. A current restriction that it is only possible to use one client per server and that OCPN will not receive incoming data on the same connection, a separate one is required. A suitable setup is a connection with the address set to (device IP address) and dataport as 10110. Then select output activated, all input messages filtered out and only the required output messages enabled. A client then connects to the IP address and port of the server (device IP address:10110). If multiple clients are required, this can be done by setting up multiple 'output' connections each with a unique data port number assigned.

TCP set up this way works but UDP, described below, is the recommended way.
--end--

As an aside, I thought that UDP broadcast worked with the highest range address of the subnet ie xxx.xxx.xxx.255? But I'm no expert here

[muttnik]

As RobbieW says, you might want a duplex connection if opencpn was both producer and consumer of data. I do understand that in opencpn's "normal" case, a producer role is best associated with a server structure and consumer with client, but other set-ups are possible, especially (as in this case) if another device is acting as a data hub to which everything else connects.

A workaround is in place so a change other than to the docs ( unless I've overlooked the relevant part) isn't needed, but in case the datastream code is overhauled in future, I would point out that the semantics of the "output on this port" checkbox are a little ambiguous. With a udp connection, checking the box maintains an input, but adds an output. IIRC under the hood you close the existing socket and open 2 new ones, one input and one output, but functionally it looks like a superset of the old connection. With tcp the input/client connection is replaced by rather than supplemented with an output/server connection

Originally Posted by RobbieW

As an aside, I thought that UDP broadcast worked with the highest range address of the subnet ie xxx.xxx.xxx.255? But I'm no expert here

Not sure what this was apropos of but...
The current (pretty much universal) convention is to use the host part of the address set to all 1s as you say. In former times some OSes (including SunOS 4 iirc) defaulted to all 0s (we're talking at the IP level here, not link layer).. Opencpn determines whether an address is a broadcast address by checking if the last octet is 255. This will generally give users the right result, but even assuming that the "all 1s" convention is followed, not always. On a /16 network an address like 172.16.1.255 is not the broadcast address. However odds are against anyone wanting to connect to that address and if you specify the actual broadcast address (172.16.255.255) opencpn will see it as a broadcast address. At the other end, 192.168.123.127/25 would generally be a broadcast address but opencpn wouldn't recognize it as such.

Opencpn is going to do the right thing for 99% of users. wxWidgets 2.8 is the impediment to doing this properly. The net library methods are very limited and whilst getting the correct broadcast address for a system interface is easy for a UNIX/C coder, it isn't with the constraints the ocpn devs face. Waiting to fix this until a time when ocpn moves to a later version of wx might be a prudent use of resources.

[RobbieW]

Originally Posted by muttnik

...
Not sure what this was apropos of but...
...

It was apropos the next section and my failing to distinguish between UDP, a lightweight protocol for use on IP networks, and a UDP broadcast (it was a long night with 43kt gusts but we dont want to turn this into an anchor thread - its a Spade btw).

Partly what was in my mind is the IP address definition of 0.0.0.0 given as an example in the TCP section. Now that to my eye is invalid, so unless theres something I dont appreciate (quite likely) trying to find a way to easily describe inputting the actual IP address of your machine seems whats required. Bridging the knowledge gap between writer (or teacher) and audience is never easy when the audience could be anyone

[muttnik]

Originally Posted by RobbieW

Partly what was in my mind is the IP address definition of 0.0.0.0 given as an example in the TCP section. Now that to my eye is invalid, so unless theres something I dont appreciate (quite likely) trying to find a way to easily describe inputting the actual IP address of your machine seems whats required.

With apologies in advance for telling you what you may already know....

INADDR_ANY is a "magic" IPv4 address, generally implemented as "0" (or 0.0.0.0 in string format). It says to the socket "listen for connections on any address". It's actually the same concept if you give that address to tcp or udp servers: Both will listen on all addresses assigned to any interface. However, broadcast (both subnet, e.g. 192.168.1.255, or "zero network", ie 255.255.255.255) and multicast (if that group is joined...see fs#1063 :-) to that port are also valid for udp.

In almost all ocpn use cases, this will be fine for a listener and saves users having to work out which interface they're using and the documentation having to describe how to do that. It's also easier to code which given the (previously mentioned) restricted set of network methods offered by wx 2.8 is a good thing.

[RobbieW]

Originally Posted by muttnik

With apologies in advance for telling you what you may already know....

INADDR_ANY is a "magic" IPv4 address, generally implemented as "0" (or 0.0.0.0 in string format). It says to the socket "listen for connections on any address". It's actually the same concept if you give that address to tcp or udp servers: Both will listen on all addresses assigned to any interface. However, broadcast (both subnet, e.g. 192.168.1.255, or "zero network", ie 255.255.255.255) and multicast (if that group is joined...see fs#1063 :-) to that port are also valid for udp.

In almost all ocpn use cases, this will be fine for a listener and saves users having to work out which interface they're using and the documentation having to describe how to do that. It's also easier to code which given the (previously mentioned) restricted set of network methods offered by wx 2.8 is a good thing.

No apology needed, didnt know that. But what you go on to say about using 0 for a listener seems to contradict what the OCPN documentation currently says. That seems to imply that you set the server (or output connection) to 0 and the listener to the servers IP address and port. Personally I find it much easier to use specific IP addresses and ports because it maps into my simple mental image of a networks construction - probably a case of a little knowledge....

[muttnik]

Originally Posted by RobbieW

But what you go on to say about using 0 for a listener seems to contradict what the OCPN documentation currently says. That seems to imply that you set the server (or output connection) to 0 and the listener to the servers IP address and port.

I think we're entering a world of client/server/producer/consumer/talker/listener confusion. My use of "listener", I now see, was ambiguous and confusing. sorry :-)

As nohal clarified, for an output tcp connection, opencpn creates a server process which listens for another system to initiate a data transfer at which point the server sends that client data. It is a listener in the network sense (it listens for a connection from another system) but a "talker" in the nmea sense (ie after a connection is initiated, the data flow is from the server to the client).

You need to use a non-zero address if you are the one initiating the connection. If you're sitting there waiting for requests (no matter which way the direction of data flow thereafter) you can just say "listen on all of my interfaces".

UDP is connectionless so it's more intuitive. If you're sending data you need to send it to an address. If receiving, you can specify 0.0.0.0 to receive on any address the system has assigned.

I haven't got the source here to check, but it might be the case that under the hood ocpn listens on INADDR_ANY whatever you put in the address box and the 0.0.0.0 instruction could just be a handy and logical value to answer the "what address should I use for a server" question in the simplest way. Could be completely wrong about that though.

[bdbcat]

muttnik, et al...

Here is some simplified pseudo code regarding the socket setups of network datastreams.

            switch(m_net_protocol){
                case GPSD: {
                    wxSocketClient* tcp_socket = dynamic_cast<wxSocketClient*>(m_sock);
                    tcp_socket->Connect(m_addr, FALSE);
                    
                    break;
                }
                case TCP:
                        //  TCP Datastreams can be either input or output, but not both...
                    if((m_io_select == DS_TYPE_INPUT_OUTPUT) || (m_io_select == DS_TYPE_OUTPUT)) {
                        m_socket_server = new wxSocketServer(m_addr, wxSOCKET_REUSEADDR );
                        ...Wait for a connection....
                    }
                    else {
                        m_sock = new wxSocketClient();
                        m_socket_timer.Start(100, wxTIMER_ONE_SHOT);    // schedule a connection
                        ...initiate a connection in 100 msec, part of the re-connect logic....
                        
                    }
                    
                    break;
                case UDP:
                    //  We need a local (bindable) address to create the Datagram receive socket
                    // Set up the receive socket
                    wxIPV4address conn_addr;
                    conn_addr.Service(m_net_port);
                    conn_addr.AnyAddress();    
                    m_sock = new wxDatagramSocket(conn_addr, wxSOCKET_NOWAIT | wxSOCKET_REUSEADDR);
                    
                    // Set up another socket for transmit
                    if((m_io_select == DS_TYPE_INPUT_OUTPUT) || (m_io_select == DS_TYPE_OUTPUT)) {
                        wxIPV4address tconn_addr;
                        tconn_addr.Service(0);          // use ephemeral out port
                        tconn_addr.AnyAddress();    
                        m_tsock = new wxDatagramSocket(tconn_addr, wxSOCKET_NOWAIT | wxSOCKET_REUSEADDR);
                        wxString addr = m_addr.IPAddress();
                        if( addr.EndsWith(_T("255")) ) {
                            int broadcastEnable=1;
                         }
                    }
                    
    
                    break;
            }

So, you are just right. The UDP listen socket is opened with INADDR_ANY, no matter what the user specifies.
And, on UDP transmit, we assume /24 netmask, so that a UDP address like x.x.x.255 triggers the BROADCAST flag.

As an aside, for the Garmin radar PlugIn, I did resort to low level network code (#ifdef'd for Windows) to identify the existence of a 172.x.x.x/16 interface as required by the scanner. I mainly did this to provide useful diagnostics if the PlugIn did not immediately come up. Adding a virtual 172.x.x.x/16 address is not something a casual user will often do
Its ugly, because I am learning this low-level stuff as I go along. Take a look sometime when you get a chance. Improvements welcome.....

As you point out, this setup will work for most OCPN users. We could rework this to allow duplex TCP connections, but I'd rather not at this point in time, especially as there seems to be a functional workaround available.

One thing we need to do, however, is to not reinitialize the TCP and UDP connections every time the user enters the Connections tab and makes a change to another (e.g. serial) connection. This can cause a drop out of TCP connections, and potentially scramble the remote client/server. See recent bug report...

Thanks for all the clarification. I think we can update the documentation as suggested earlier in this thread, and let it ride.

Dave

[RobbieW]

OK, thanks. Now we're getting down to a more detailed level I start to get the picture. Didnt realise that in this sort of client/server relationship (or any?) the client initiates the connection to allow the server to serve its data - OK, now the 1:1 TCP client:server relationship makes sense and why the lighter UDP is a better solution.

I think, then, that the OCPN documentation needs to say that using address 0 is a special case that works for whatever it works for. With the level of knowledge I have, I distrusted something that didnt gel with my experience. I dont think I've come across another instance of address 0 used in that way.

Edit: oops, that was in answer to muttnik, Daves post came in whilst I was writing

[rgleason]

I'd like to thank you all for this intelligent discussion about networking and UDP as it relates to Ocpn, it presses the edge of my networking comprehension, but manages to clarify things at the same time, and possibly improve Opencpn Connection and Documentation. Is there anything I can do to help with the documentation on line? Or will someone else more knowledgeable make the changes, I hope?

Thanks bdcat, RobbieW and muttinik! Very helpful..

[rgleason]

Hope you don't mind, added FS #1110 Task to
Project: Opencpn 3.3.x Beta

Also look under Tracker / Flyspray.
Project: 0- Opencpn - Feature Requests
Sort by "Summary"
Pick page 4 and 5 and look under NET and NMEA
-you will find other other similar tasks/requests.
If any should be under Opencpn 3.3.x beta, please change or consolidate.

[olmen]

I have tried to understand the complete discussion in this thread before I post my question. So far I have not found the answer to my problem.

I am using OCPN 3.2.2. on a Win/XP system (SP3 installed) and try to find the AIS data from a Furuno FA-50 AIS transponder. The IP address of the transponder is 172.31.24.3. I can access its management functions with a browser so the connection itself seems to be OK. On the same LAN a Furuno NAVNEt VX2 plotter is connected and that receives AIS data and displays it.

I cannot find that data however if i try to listen in with OCPN on any of the following ports:

172.31.24.3.:10000 UDP (The default port, and as far as I know FA-50 sends out AIS data with UDP. The portnr can not be changed on the FA-50)

0.0.0.0:10000 UDP or TCP
0.0.0.0:10110 UDP or TCP

when i display netstats -a -p UDP in windows, i can see that windows is listening in on the right portnr.

Can anybody help me how to connect OCPN with the AIS data from the FA-50?

kind regards.