Actually the bug, from what i understand is only in the arduino code. It needs broadcast whereas AOG is not needed, it send directly to the module port number.
Or am i misunderstanding that? Seems to work fine port specific from AOG while being broadcast (no choice) from arduino.
Yes misunderstanding, aog/Windows is not sending the messages to the right interface without this option when a broadcast IP is configured (and that’s needed in many usecases).
Data goes to loopback instead of WiFi. I can capture and attach some .pcap files if you want.
The problem is on the layer 3 (ip), not on layer 4 (udp/port numbers).
One of the last Windows 10 started to enforce this behavior
It only happens if there is no default route on that interface (in my test-Setup, but valid for local only communication)
After testing again: Windows decides on a unknown base if broadcasts are forwarded or not. Just tried to screenshot it, this time it seems to work. (Should have made a screenshot two days ago when I spent one afternoon chasing the problem why I did not received any PGN over wifi).
But in either case: I think implementing the API behavior can not be a negative thing, especially if it’s as easy as in this case, so we won’t rely on some undocumented behavior.
Hello, I have a UDP Problem, the Check SUM is green, but i dont recieve any data from Arduin, no steering angle no remote switch etc…
What could be the Problem?