Protect the user from common connnection configuration mistakes #3700
Comments
|
UDP output connection should in turn always use a broadcast or mutlicast address |
|
A UDP output connection might be good to have the "suggested" IP address be a broadcast/multicast address. But I think it's ok to let the user change it to any IP address. There are valid use cases for sending UDP to a specific device and not all devices (e.g autopilot, data recorder, etc.). |
|
Yes, even |
|
Ugh... |
|
We should probably not forbid "anything", but show some warning when it is "suspicious". |
Ahaa.. That's why it was sometimes accepted! Didn't noticed first at the blurry screenshot. Agree on discussion above. An output (UDP)address not in the form xxx.yyy.zzz.255 would create an advisory message? |
|
For UDP output, if I was to decide, any address not being a unicast ( |
|
If all users know what he/she is doing all time we don't need any advisory messages or default values? :) |
|
Is there a way to have a "hostname" advisory if OpenCPN is going to use it that way? |
Please verify that this is the case. or is it just ignored? Maybe it should be the default 0.0.0.0 greyed? and then the user has to enter they Data Port: the receive input(only), both and output (only) on this port default settings appear to be |
|
Of course it is. |
Since when did .x become a valid top level domain name ? And does whatever code that parses the IP address perform a gethostbyname call ?
Huh, What if I just want to send a UDP output to a single device on the network ?
What happens if the user has multiple network adapters, connected to different subnets ? Perhaps they just want to receive UDP traffic from a single adapter connected to one network. |
Since always, it is not an official TLD, but technically valid in a private network? Of course yes.
Then what you want to do is a different thing than the usual use case of our users who want to broadcast to their phones and laptops and fill in a single IP address only because they have no idea what they are doing and that there is a difference between UDP broadcast and TCP server. Do you have to be able to do it? Of course. |
|
If the user has configured something.x as a hostname, even though .x is not a valid TLD, if they have not added something.x to their hosts file or dns server, it won't resolve, which you can detect by using gethostbyname (superceded on Linux by getaddrinfo), For output, why not something similar to the SignalK UI ? And you can programmatically determine and pre-populate the subnet broadcast address For fuck's sake. Just tested this, As McEnroe would say, You cannot be serious. 
|
|
Yes, these are exactly the types of things I had on mind when I created this issue. |
|
I've been doing some testing on the UDP connections settings. Whatever address you put in the Address field for the output connection is used as the destination address. If you put a host address in then it will send it to the host. If you put a broadcast address it will send it to the broadcast address. One "odd" behavior I noticed was that while the debug window would gladly claim to send the UDP packet regardless of the destination that did not always translate to a packet actually getting on the wire. If I used a destination address of a device that was active on the network then it faithfully put the packet on the wire. If I used a destination address of a device that was turned off the debug window would say it was sent but nothing was actually transmitted. I'm testing on a Windows machine and all of the addresses were on the local subnet. I suspect that something in the network stack decided that if it could not determine the MAC address for the target it was not going to bother putting it on the network. I only mention it because the debug window implied that the message had been sent. I did not think to test it but it would make sense that if I had used an address on a different network (good or bad) then it would have forwarded it to the gateway router without any issue. I tried to duplicate the odd behavior I saw with Franzisca where her phones would see the UDP packets even though the entry in the data field was not a valid IP address and was (at best) a very odd host address. Thanks nohal, It did not occur to me that it could be seen that way. When I entered the same odd address I did not see any data on the network. The debug window faithfully showed that it was sending a packet to the odd address but I did not get the same results she did. Something on her system seems to have resolved the address to the local network broadcast address. I suppose a "helpful" consumer-grade DNS might decide that anything it does not know how to resolve should be thrown out to the broadcast address of the local network in the hopes that something on the local network was supposed to use it. The input address field works in a similar way. If you put 0.0.0.0 in then it will use data from any device as long as the port number matches. If you put a host address in then it will only process data from the indicated device and port number combination. I did not identify any anomalies in the debug window when testing input connections. |
|
We have no problem with valid addresses, it works for all the cases - unicast, broadcast and multicast. UDP is a connectionless protocol, so the application basically is throwing packets down the drain and by design there is no feedback - as long as we were able to hand over the packet to the OS, it is a success for us, but there never is any warranty or feedback on delivery. At the time of configuration, we can check that a unicast or broadcast address is directly routeable using the current routing table (which very likely is what the user is trying to do), but there are exceptions like forwarding AIS feed to AISHub, which is a unicast to a public IP somewhere on the internet, which may or may not be available at all and is routed via default gateway. For multicast, there is nothing to check, that simply is a hole to throw packets to and forget about them. An interesting subject is total garbage of an input. Two options there, either reject or at least warn if not resolvable and routeable and at the end probably just generate "192.168.1.4.x.x was in the french manual and does not work" as a result. Or let it end up a broadcast like now. |
|
Warren [wholybee] has some suggestions here, for clearer operation: Drawing from my experience with UDP unicast, multicast, and broadcast with other products, maybe there could be an UI change on the connections dialog that will prevent common errors. The following is commonly used with professional video equipment I have used. What I have seen before: If the receive button is checked: IP address is populated with a sensible default, such as 224.0.0.78 (78 is just a number I made up, we can choose anything for the 4th octet as our default) A note is displayed to explain that the multicast address is NOT the IP address of the other machine, and it can be left as default unless the user is advanced and knows why it is being changed. (conflicts with some other multicast device-highly unlikely on a boat. If the broadcast button is displayed: If the transmit button is selected: If broadcast is selected: Selecting both transmit and receive on UDP should be prohibited, and TCP should be advised. While I believe it is technically possible, it introduces complications, what happens when multiple devices are transmitting on the same broadcast or multicast? Maybe it could be allowed with UDP/Unicast, but mostly I think that for bidirectional communication TCP should be preferred. Maybe an "I know what I am doing" checkbox to allow it. Also, FWIW, previously I have been unable to get Multicast to work at all with OCPN. It might have been an error in my setup at the time, since I easily got broadcast to work I didn't pursue it further. But, someone should confirm that it actually works if it is going to be documented. -Warren Perhaps Bill [Be Free} has some thoughts about this? |
|
If the receive button is checked: Unicast from a receive standpoint should have the address of the transmitting device. "I only want data from this address on the specified port. That is actually the way the dialog works now. An address of 0.0.0.0 on a receive connection means "I want data from any device on the specified port". That is covered by your third option. I would even go a little further and give them the choice of "accept data from a specific device, accept data from a group of devices, or accept data from any device on my network" radio buttons (or something similar). Unicast, Multicast, and Broadcast are not terms the average user likely cares about. That should cover all of the easy choices. If you don't lock out the default multicast and broadcast addresses a professional would know that these fields could be changed. Of course, the appropriate manual would use the appropriate terms and specify that any desired multicast or broadcast address may be entered. Other than mentioning that this may require additional configuration on their router, I would not go any further. That is beyond the scope of an OpenCPN manual. The topic at hand is protecting a normal user from common configuration mistakes. I am not a normal user and recognize that fact. I have multiple networks on my boat and some of my instruments communicate with devices outside my boat. I designed it, configured it, and it works. As long as my tools, OpenCPN included, allow me to configure them to fit my self-imposed complexities I am content. |
|
Warren, Honestly, even allowing for my penchant for designing complex networks just to see if they will work, I can't think of a reason I'd set up a multicast connection. The UI really does not need to change. Any address we guess will be just that (a guess). It's only a few more keystrokes for the user to enter the entire multicast address either because they are following instructions from someone who set up the other end of the connection or because they designed it and know what address to use. |
|
Pavel, How hard would it be to add a ping to any unicast address entered? That would cover routeable and resolvable in one test. If it fails tell the user something like "The host can't be reached at this time." Even if it resolved to the broadcast address, that would be an error in this case since the user said they wanted unicast. It's been a long time since I've seen a ping to a broadcast address return a positive result (by default) and I've never seen a consumer-grade router that could be configured to allow it. |
|
Bill, If the default should not be 0.0.0.0 but something else that is fine. The point is that if Unicast is selected, the user should not be able to enter anything in there. The correct value would populate. My understanding is that on a receiver, the IP address is the address listened to, not transmitted from. So, either the local interface's address(or even 127.0.0.1) , the networks broadcast address, or a chosen multicast address. In a typical Unicast setup, only a port number is needed. In other unicast applications I have never needed to enter anything other than a port number to listen to. Entering the address of the transmitting device should not work, because the transmitting device is not transmitting to that destination. The reason for Multicast, is that in general, and certainly on any network more complex than a boat, broadcast should not be used. Broadcast floods the network with packets that go to every device on the network. Those devices can choose to do something with them or not. Multicast packets are based on a subscription. Only devices that subscribe get the packets, so much less traffic is generated. Multicast packets are also routable, so in a network with multiple subnets, or crossing a gateway to another location, multicast packets can be routed to it. Probably no boat does this, but it is possible with Multicast. |
|
I'm with you 100% on the receiver as far as the address that should be entered for the receiver is the address that will be listened to. That is usually going to be the address of another device on the network although there is nothing stopping you from listening to your own address if you really want to. I may be misunderstanding you but it sounds like what you are describing is putting the address of the interface being listened to rather than the address of the host being listened to. "Broadcast receiver" is really an oxymoron. What we are calling a "broadcast receiver" would be more properly described as an "indiscriminate receiver." A broadcast receiver is a little odd in that you enter 0.0.0.0 which is more accurately described as "any host" rather than the 255.255.255.255 or X.X.X.255 (among many others) which could be better described as "every host" and would be used on a broadcast sender. |
|
Now, assuming that I'm not totally mistaken with a unicast receiver the user is the only one who knows what should be entered. The only thing I know for sure is that 0.0.0.0 is not the right answer since it means "receive from any host" which is the exact opposite of unicast. My tests yesterday indicated that 0.0.0.0 would accept data from any sender on the specified port but when I put a specific host in the address field that was the only host that the receiver would accept data from. |
|
The transmitting device does not need to know (but may know) the address of the receiving device. The sending device could be sending directly to the receiving device (unicast send), or to any broadcast address that the receiving device may be listening to (broadcast send). (I'm not commenting on multicast since I've never used it and could not make it work in my tests.) The unicast receiver does not need to know ahead of time if the sender is using unicast or broadcast. Either one will come up the stack to the application and will be accepted if it came from the indicated host. |
|
One of us may be backwards about the receive side. I am working from my experience with professional equipment a using UDP unicast and multicast and as I said broadcast shouldn't really be used, so other than OpenCPN I have not used broadcast. My understanding is that actually all 3 work exactly the same, only that for unicast and broadcast the interface by default will listen to it's own IP address and it's own broadcast address, so only a port is needed. Excuse my poor attempt at making a table of my understanding. The transmit side is always the IP address you are transmitting to. The receive side is the IP address of the interface the receive device is listening on. Usually there is only one interface installed in a machine. In the video applications I have installed there are often 4 or 6. So it does matter that it is correct. 127.0.0.1 would listen on all 4 or 6 of them. In a very advanced configuration you might specify that ETH1 should listen on 224.0.0.1, so that the multicast stream isn't received on multiple interfaces. That actually IS an option on some of the equipment I have worked with. Specifying multicast addresses is done per interface. Unicast or broadcast doesn't need an IP address at all, only a port number and an interface to listen on. Sometime tomorrow I can setup some tests and test all of those scenarios. But that is my understanding from setting up a fair number of multicast networks. |
|
Ok, I think I see where the differences are coming from. Let me know if this sounds right. What you are describing is absolutely correct if you are talking is what is happening at layer 5 of the OSI model. Multicast actually happens at layer 2 and is in some cases indistinguishable from broadcast. Any packet addressed to the receiver's address or to any broadcast address that the receiver is part of will be passed up the stack to the application layer where OpenCPN resides. What happens at this point is what we are discussing.
I think at this point when you say "listening" that you are describing the behavior of OpenCPN, not the network card. Please forgive me if I'm wrong about that. If I'm right, this is the way I'd expand it. I don't think the loopback address adds anything to the example so I'm going to drop it. Transmit to 192.168.1.2 Is by default always listening on 192.168.1.2. Passes up the stack to OpenCPN. Transmit to 192.168.1.2 Even if incorrect IP address is entered, will still work. I agree at level 5. The network driver
We are almost in agreement. The address on the transmit connection in OpenCPN is always the IP address you are transmitting to. However, the address on the receive connection is either the address of the sender (unicast receiver) or 0.0.0.0 for what I'm calling the "indiscriminate" listener. I look forward to the results of your test. |
|
Thank you for bringing up the OSI model as that adds clarity. After reading your response twice, i am in 100% agreement.
I have been assuming default values in OpenCPN of 0.0.0.0 because that makes configuration easier for the user by hiding the field, and knowing the IP of the sender is only needed if there is a misconfiguration elsewhere(2 senders both sending to the same receiver) But I'm indifferent on that matter, either 0.0.0.0 or the senders address works for me.
Here is my realization for making it easier for a user. Probably all users are using broadcast. If a user really needs unicast, they can use tcp. And i have my doubts that multicast even works. So, is there a compelling reason to support anything other than broadcast? OCPN should be able to auto configure broadcast in most cases, making configuration simple and nearly foolproof.
Maybe having it default auto configurated broadcast, and a user can change a radio button to unicast and enter something else.
I also think we shouldn't need to teach a user networking. Even if all the radio buttons do is provide a different hint to the user what needs to go in the IP address field, it would greatly simplify configuration.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: B3Free ***@***.***>
Sent: Sunday, March 31, 2024 6:50:47 PM
To: OpenCPN/OpenCPN ***@***.***>
Cc: Warren Holybee ***@***.***>; Comment ***@***.***>
Subject: Re: [OpenCPN/OpenCPN] Protect the user from common connnection configuration mistakes (Issue #3700)
Ok, I think I see where the differences are coming from. Let me know if this sounds right.
What you are describing is absolutely correct if you are talking is what is happening at layer 5 of the OSI model. Multicast actually happens at layer 2 and is in some cases indistinguishable from broadcast.
Any packet addressed to the receiver's address or to any broadcast address that the receiver is part of will be passed up the stack to the application layer where OpenCPN resides. What happens at this point is what we are discussing.
Transmitter: IP 192.168.1.1 Receiver: IP 192.168.1.2 (by default the network
interface will listen to 192.168.1.2 and 192.168.1.255
regardless of what the application does)
Transmit to 192.168.1.2 Is by default always listening on 192.168.1.2 so works
Transmit to 192.168.1.2 will also work if listening to 127.0.0.1
Transmit to 192.168.1.255 Is by default always listening on 192.168.1.255 so works
I think at this point when you say "listening" that you are describing the behavior of OpenCPN, not the network card. Please forgive me if I'm wrong about that. If I'm right, this is the way I'd expand it. I don't think the loopback address adds anything to the example so I'm going to drop it.
Transmit to 192.168.1.2 Is by default always listening on 192.168.1.2. Passes up the stack to OpenCPN.
Unicast listener configured for 192.168.1.1 works. All other addresses ignored.
Broadcast (indiscriminate) listener configured for 0.0.0.0 works regardless of source or
destination.
Transmit to 192.168.1.255 Is by default always listening on 192.168.1.255. Passes up the stack to OpenCPN.
Unicast listener configured for 192.168.1.1 works. All other addresses ignored.
Broadcast (indiscriminate) listener configured for 0.0.0.0 works regardless of source or
destination.
Transmit to 192.168.1.123 Neither the network card nor OpenCPN will ever see this packet under normal
circumstances. I can think of several situations why it would not and at least two
where it could but even if the network card receives it the packet will not be sent up
to the application layer (absent a promiscuous mode driver).
Transmit to 192.168.1.2 Even if incorrect IP address is entered, will still work. I agree at level 5. The network driver
running at level 5 does not know what OpenCPN thinks at layer 7. However, when it
passes the packet up to OpenCPN it will not be from the "incorrect IP address" so it will
be ignored.
Transmit to 192.168.1.255 Again, any incorrect address can be entered, because the interface is always listening to its
own broadcast. Again, I agree at level 5 and suggest that OpenCPN will respond the same
as the previous example.
The transmit side is always the IP address you are transmitting to. The receive side is the IP address of the interface the receive device is listening on.
We are almost in agreement. The address on the transmit connection in OpenCPN is always the IP address you are transmitting to. However, the address on the receive connection is either the address of the sender (unicast receiver) or 0.0.0.0 for what I'm calling the "indiscriminate" listener.
I look forward to the results of your test.
—
Reply to this email directly, view it on GitHub<#3700 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIOGONJRKH5E23SRBCEMGNLY3C4PPAVCNFSM6AAAAABEASQLZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRZGAZDAOJZGE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Sigh...
Most consumer equipment only supports UDP broadcast or TCP/IP. That would not be a bad idea here, except for possibly breaking configurations when people upgrade. There is little reason to support anything else. Any equipment that i have used that does support multicast uses radio buttons similar to what i describe. It really is needed to validate the input.
Since you allow unicast and multicast, you have to deal with it. It simply is not possible to validate a configuration without knowing what is being configured.
For broadcast, by far what almost everyone should use, the required IP address is known. The IP field should not even be available, isn't available on other software (ex. Navionics), and there could not be a more full proof configuration. Yacht Devices, Actisense, and Navionics all only support broadcast, and none ask for an IP address. Navionics even scans common ports, there is no setup at all, if UDP broadcast is available on standard ports it just works.
For unicast, the rx device similarly needs no IP address configuration, just a port number. Only the tx needs to know the destination IP. The only real application for this is from one OCPN install to another, because almost all other navigation software only supports broadcast.
Multicast is the only choice that requires an ip address on the receive side at all. For multicast, both IPs needs to be the same, and needs to be a valid multicast address. It's easy to suggest one, and validate that they are indeed Multicast addresses. You can't validate a multicast setup without knowing multicast is the intent.
No validation of any of the above that can happen without the radio buttons. It's impossible to do good validation without them. Thats why I'm being so hard headed here. If you don't do that, you will still have users making the same errors. No other suggestion thus far would do anything to help the user that led to this issue.
If you don't want to add the radio buttons, don't do anything. The current interface is clean and easy to understand as is, I really like it alot. But none of your suggestions will help users that don't know what they are doing.
You could also opt to not support multicast at all, and then not show an IP address field unless tx is checked, since tx is the only time its needed, and even then only for unicast. So there would still be an issue that a user needs to know how to construct a correct broadcast address, which they don't, so they will screw it up. But at least the rx side would always be right. And again UDP is unidirectional, it should not be possible to have both tx and rx checked. Actisense even states this in their manual and recommends TCP because of it. TCP for bidirectional data, and UDP broadcast for many devices to be able to receive the data.
Regarding TCP/IP server. It states in the manual that an IP address of 0.0.0.0 creates a server. But most would probably miss that. Something in the UI to select would be better.
|
|
Whew... Lets consider this possible UI, for UDP only.
Everything after (1) is Advanced fu. We may (safely) assume that a user needing this functionality will a) know what they are doing, or b) know how to ask for help, or c) RTFM. Did I miss anything? |
|
I like that. Only thing I might add would be that when TX is checked, the IP field would initially populate with the correct broadcast IP. Then the user could change that to whatever if they wish.
|
|
Some mockups for UDP Receive. The only time a user enters an address is if they want to listen to a multicast, in which case the "experienced" user should know what they are doing. Nonetheless, we should validate the address as a valid IPv4 address in the correct IP address range. Haven't got around to thinking about transmit, nor about the elephant in the room, IPv6. 
|
|
The current network behavior there would serve no purpose to select which interface. It doesn't matter. If the port is correct OpenCPN will receive data on any interface regardless of IP. So that's not just a UI change, the underlying network code would need changed as well. Which I suppose is fine if that's the behavior desired.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: TwoCanPlugIn ***@***.***>
Sent: Wednesday, April 3, 2024 10:33:48 PM
To: OpenCPN/OpenCPN ***@***.***>
Cc: Warren Holybee ***@***.***>; Comment ***@***.***>
Subject: Re: [OpenCPN/OpenCPN] Protect the user from common connnection configuration mistakes (Issue #3700)
Some mockups for UDP Receive.
The only time a user enters an address is if they want to listen to a multicast, in which case the "experienced" user should know what they are doing. Nonetheless, we should validate the address as a valid IPv4 address in the correct IP address range.
Haven't got around to thinking about transmit, nor about the elephant in the room, IPv6.
net0.png (view on web)<https://github.com/OpenCPN/OpenCPN/assets/41049749/a69989fb-3b5d-4e1e-a276-4cdbb4ff5a4a> net1.png (view on web)<https://github.com/OpenCPN/OpenCPN/assets/41049749/8fc8c381-437f-4394-9d07-93b40b8d5719> net2.png (view on web)<https://github.com/OpenCPN/OpenCPN/assets/41049749/dcec75a0-551b-4be0-9376-137d6ebfab8f> net3.png (view on web)<https://github.com/OpenCPN/OpenCPN/assets/41049749/af0d5a48-9ce7-4110-a654-c96be581a873> net4.png (view on web)<https://github.com/OpenCPN/OpenCPN/assets/41049749/4b2ae870-29f8-4960-b38c-e9604ecee4fd>
—
Reply to this email directly, view it on GitHub<#3700 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIOGONIO6ENOCFW7PY7SF3TY3TQ3RAVCNFSM6AAAAABEASQLZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZWGIZDIMJQGU>.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Surprised no one has complained that I had omitted the Loopback interface! For receive, other than probably correctly implementing the multicast receiver, I don't think it affects the underlying network code.
For transmit, it shouldn't be much different, other than deciding whether Broadcast and Multicast are sent over all interfaces, or whether to specify a single interface. I think for broadcast it would mean iterating over all interfaces and sending to each broadcast address. and for multicast, IIRC, it would require the socket option IP_MULTICAST_IF. In either case I doubt it would be the intent of the user to send broadcast or multicast traffic over all of their networks. Alternatively, assume a simple approach for the majority of use cases, and just use the Broadcast Address for the selected interface. There could be an "Advanced Mode" that allows the selection and input of either a single or multicast address. Importantly, and this was the crux of the matter from the OP, whatever IP address is entered, it needs to be validated. |
|
The matter for the OP was not a problem with address, it was that the interface was being turned off by Windows. The nonsense address resulted in a broadcast. You can't receive multicast on INADDR_ANY, that is the whole point of it. The mockup is fine unless I want to connect to something over the internet or need to configure something that is not currently connected, which both is something I use daily both in the lab and on boats. There is no magic in the network configuration, the user needs to be offered local interface addresses, corresponding broadcast addresses for local interfaces, IPs of the gateways for the local interfaces (Which likely is a multiplexer, RPi with openplotter or a MFD and may provide TCP data), and 0.0.0.0, filtered per scenario (=TCP/UDP/in/out):
Multicast is not something that needs any support other than allowing manual entry of the address as it is only used by people who know what they are doing |
|
Pretty much agree with everything Pavel just said.
I think an interface selection might be confusing though. It's something rarely seen in any software. I think it would be better to make a reasonable guess at the interface and just use that, allowing the user to change IP addresses if they want .
Most PCs on boats will only have one interface that is up, and for those that don't, likely the user knows something about their network configuration.
|
|
How would the validation look/work from a UI standpoint?
The user clicks <ok> and an alert dialog displays if validation fails? With <go back> and <continue anyway> buttons?
|
|
Can someone please summarize the general concensus for this topic? |
Yes you are correct. I shouldn't put pen to paper when sitting jetlagged in an airport lounge. In my reply above, point 1. should have omitted Multicast and just said Broadcast and Unicast, and Point 3 was mislabelled and, should have been labelled Multicast. Anyway, I don't know why we're having this discussion, seems to me that everything works without any input validation. My script is just sending traffic to the network broadcast address (192.168.1.255), so apparently a misconfigured input or output port defaults to the broadcast address, which is probably what the end user is trying to achieve. The good news is that on O5.9, illegal characters cause a crash. 
|
|
@TwoCanPlugIn So your conclusion is change nothing for v5.9? It seems to me that the initial interface could present a very simple form that is good for 75% of the users, showing default settings that do not change in grey, and then allow increasingly atypical configurations with use of dropdown menus which open up and change additional settings. Similar to what was being discussed. |
|
Sorry Rick, seems like you missed the gist of my comment. I think a bit more thought needs to go into this. Pretty soon every boat will have a network of some description, not just NMEA 0183/2000 gateways, but also connections to tablets at the helm, Internet connections using Cellular Mobile or Starlink etc. and O needs to get this right. Off the top of my head.
On output you can't select which interface it uses. For example, take the scenario of users with a radar connected to an Ethernet cable and a WiFi connection to their Actisense or Yacht Devices gateway. IIRC the Ethernet will have a lower route metric therefore by default, multicast traffic will be sent on the Ethernet network, which is probably not their intent. There's probably heaps more and I haven't even thought about TCP, but my brain is fogged after a long flight so these few comments will suffice. I trust that Dave will bring some sanity to the discussion. |
|
With all this brain power (when not fogged) I could really use some help getting specific areas of the manual sorted: I got brain fog going in circles there, need fresh eyes: Quick Start GNSS Setup and OS pages I know you all have contributed to these pages, but we really need to get this as a simple step by step. I've taken annotated screenshots that will probably have to be redone eventually, but perhaps getting the manual whipped into shape will help with the thought process here? |
|
I have been working on this the past few days, as an exercise to familiarize myself with the OCPN code, not expecting any changes to be accepted. But, I will share what I have done. Maybe some of these changes should be considered.
You really have to play with it to see how well it provides reasonable defaults without getting in the way of entering whatever you want if needed. And the column realignment and advanced checkbox make it much more inviting and less overwhelming to a new user, while providing what most users will need in a simplified way.
|
|
Would someone care to answer the following: 
|
|
|
Wjollybee.. |
|
Actual code. Everything I listed is working.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: bdbcat ***@***.***>
Sent: Saturday, April 6, 2024 6:00:31 PM
To: OpenCPN/OpenCPN ***@***.***>
Cc: Warren Holybee ***@***.***>; Comment ***@***.***>
Subject: Re: [OpenCPN/OpenCPN] Protect the user from common connnection configuration mistakes (Issue #3700)
Wjollybee..
Are your changes mockups, or actual wxWidgets code?
—
Reply to this email directly, view it on GitHub<#3700 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIOGONI7EVGWU7PZKQZ7T7DY4CLC7AVCNFSM6AAAAABEASQLZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGI2TOOBWGE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
It doesn't seem to work as one would expect. I can set all of the connections to the same list position number (including zero). Why not just have up/down arrows to change the order, similar to the attached dialog. In any case, other than the display order, does it do anything, such as affect the priority of sentences ? 
|
|
" I can set all of the connections to the same list position number (including zero).' Other than the "list position", this field has no other effect on this, or any other connection. |
|
Wholybee... |
|
I agree on the baud rate. I am on my boat now for a couple days. When I get back home I'll do a pull request. |
|
Wholybee
Thanks, looking forward to your comments. |
|
Thank you. I can work on that next week. I'll remove the adapterInfo parts, change the IP addresses to 0.0.0.0, and change "advanced" to more/less. Can you show me an example of the more/less for me to follow? I assume instead of a checkbox, it would be a button whose label changes? |
|
That will be fine. |
|
Ok, I have removed the adapterInfo networking stuff, changed the advanced checkbox to more/less, and a couple other minor fixes. For example, the control checksum and garmin options were displayed on some protocols where they shouldn't have been. It should have some more testing, particularly on canbus, bluetooth, and android devices, since I can't test those. Also, this is my first pull request on github. Let me know if I do something wrong. I am learning that maybe I should have branched before committing changes and making the request. |
|
OK, I'll review tomorrow, and probably merge. |
It should be pretty easy to protect the users from common nonsense in the configuration, for example TCP and Signal K endpoints must not have broadcast or multicast addresses like 0.0.0.0
Also the default ports can be adjusted based on the protocol (eg. 10110 for NMEA0183, 3000 for Signal K etc.)
The text was updated successfully, but these errors were encountered: