Dumb question about AgIO and UDP, subnets and addresses

I’m never quite sure what categories to post to on Discourse.

I’ve been reviewing the AgIO code to understand UDP and the protocol AOG uses better, along with the Teensy sketch. After spending some time in the code, I have a dumb question, two actually. If AgIO is using broadcasts to 255.255.255.255 to find the teensy, and if the teensy is broadcasting its Hello replies also to 255.255.255.255, why does the subnet matter at all? Why does the IP address matter? Currently autosteer is fixed to x.x.x.126 for example. IMU 121, GPS 120, Machine control appears to be 123. Yet AgIO is blasting the messages from AOG out to everyone all the time.

Obviously when you have a layer 3 switch in the mix, broadcasts are not going to cross subnet boundaries, but with ordinary layer 2s it seems to. I mean after all in the video demonstration AgIO can properly detect that devices are present even if they are on the wrong subnet and get them to set themselves to the right subnet.

Also by the way AgIO isn’t working under Wine on Linux at the moment. ScanNetwork() is failing because of the reuse of the already-bound 9999 port. SocketOptionName.ReuseAddress doesn’t seem to let it work on Linux. When I get my Windows VM running again, I’ll submit a patch.

Anyway, back on the address thing, what am I missing, Brian?

I believe AgIO only uses the super broadcast to find the modules, and broadcasts all the other messages to the active subnet only. But I’m not sure why it can’t always use the super broadcast. Maybe the modules’ replies can’t get back unless they’re on the correct subnet.

Yes that’s correct. The module messages intended to be passed to AOG are sent to the subnet-specific broadcast. Since the discovery process uses the 255.255.255.255 broadcasts in both directions, I am unclear as to why regular module messages couldn’t also be sent that way. It is still important to be able to change the module subnet, though, in case there’s a conflict with another interface on the tablet. If there wasn’t a conflict it would just work even if the tablet was using a different subnet than the default module one.

Anyway I’m just getting my head wrapped around how it presently works and maybe the reasons it is the way it is.

Might be related: When testing an “external simulator” ( External simulator using a game engine (Godot) ) I noticed that you can actually get it working on the same computer as the AgIO/AOG is running. When using the default subnet 192.168.5 on the AgIO and IP 192.168.5.10 on the computer the simulator can actually communicate with the AgIO and everything seems to be working. Actually found this accidentally while testing if the simulator runs on the tablet AOG was running on. :slight_smile: I expected this not to work as the IP was not .126, but use of broadcast messages as written in this thread kinda explains this.

It is slightly confusing that the IP shown for the steer unit is 192.168.5.126, though, as it is also running on 192.168.5.10:

At least in this laptop you need to connect a cable to ethernet port to get this working. I have it connected to a router with subnet 192.168.1.x so likely it doesn’t really matter where you connect the other end to.

Message log from the external simulator:
AgOpenGPSSimLog_SameIP.txt (36.7 KB)
Based on this it looks like “hello” is sent only to the defined subnet and “whoami” to all subnets available(?)

Thanks for the correction. yes you are right. Interesting about the need for an ethernet connection to make it work. I’d have thought the WiFi interface would have provided a sufficient address space to work with. I did discover when using wireshark that IP packets destined for my own IP address (real address) sent from my address don’t show up in wireshark because they don’t actually go out on the network at all. A loop-back optimization. However broadcast messages obviously do go out on the wire, even if your simulator is running on the same host.

IP address itself doesn’t matter as you say. Messages are sent to and from the modules via the subnet broadcast. The messages themselves encode the PGN which is what the module is looking for. If you use the all-in-one board, the Teensy ino does GPS, IMU, and Steering all in one. It may answer a whoami message with a particular IP address (126 I think), but it responds to all the other messages and sends all the specific messages for those 3 modules, as well as dealing with NTRIP and passing NMEA to AgIO and AOG. Busy little ino.