UDP not sending

[Stuart]

I'm trying to log activity on a server using UDP. I have done this before successfully. But I can't see any traffic from the Annex device to the server. Has anything changed in the way it works? I'm using

udp.begin 5001

udp.write "server ip", 5001, "string"

I can see network traffic with wireshark and can see the traffic between annex and my computer, but nothing to the server. I'm using the bleeding edge 1.51.5 on new hardware

[cicciocb]

Just tried and it works on esp32 and esp32-s3.

Are you sure that you are using the right IP address?
Often the PC have several IP addresses, so be sure to use the one that is in the same network of the module.

[lyizb]

I'm successfully using Annex UDP on about a half dozen devices--ESP8266, ESP32 D1Mini, and ESP32 S2Mini, with the listener being an r-piZW.

I have been baffled by devices connected to different APs on the same network not seeing each other--and I continue to not understand why and exactly when this is the case. For the most part, I've solved this by always connecting to the same AP. I'd like to know why 192.168.2.13 can't see 192.168.2.51 when both can see the internet with the same gateway router and both can ping that router. I don't see anything in the configuration of the different APs which would cause connections to one not to be seen by devices connected to another.

[BeanieBots]

When you say "server", is that outside your network? In which case you will need to setup port forwarding.
If not, then maybe post you exact code on both devices so that others can check for issues.
Try a general broadcast to 255.255.255.255. Every device on your network should receive it irrespective of its IP address.

[Stuart]

I made a test program on another M5stack with the same version of Annex and it works fine. So I ran the test program on the troublesome machine. It doesn't work. This is a big house with several access points and a couple of switches, ultimately on one router. The server is wired into the main switch. The m5stack that did work is on an AP that wires into the same switch. The troublesome machine is on an AP booster in the garage and I don't know (yet) where it is getting its signal from, but it may be from another switch downstream of the main one.

So I suspect that the problem is the switch. I found this on superuser.com:

"It's possible the switch has client isolation enabled. This is especially common with wireless access points and switches. The clients can talk to the switch and anything upstream from it, but are prevented from talking to each other as a security measure."

So now to find the switch documentation.

[BeanieBots]

It probably is related to not being a direct link and via a switch/repeater.
I had a similar issue appear after a few months of all working well.
An IP scan would list the ESP device but there was no web page and a ping did not give the usual timeout but reported "host unreachable".
All was resolved by re-booting the wifi repeater. (despite all other devices on that repeater working fine).
Might be worthwhile as a first try to re-boot all devices in the path between the two devices that won't talk to each other.

[Stuart]

The saga continues, as my analysis of the paths is inconclusive. It may be of interest to others with mysterious network problems in future.
There are four relevant machines, as below:

ip address
29 a file server hard-wired via a switch to another switch to the router
127 a laptop wifi-connected to an AP connected to the main switch
92 an annex ESP32 (M5core) wifi-connected to the same AP as the laptop
95 an annex ESP32 (M5tough) wifi-connected to a wifi extender (linked to one of several APs)
both annexes are running 1.51.5

this is where it gets odd:

95 cannot send udp to 29, this is the core issue
BUT 29 can see 95's web pages (http). http uses TCP which is a two-way protocol so both ways can work
95 can send udp to 127, so 95 is working properly
92 can send udp to 29, so the other annex machine is also working properly

Next step is to a) trace where the extender is getting its signal, and b) reboot everything.

Meanwhile, I am logging to the (linux) laptop. If anyone has the skill to amend this bash script to force daily files I would be grateful. The bash scripting language is not very easy to follow. I did have a version that I thought would do that but it didn't work. I did write an explanation of logging on this forum which is still there if needed.

#!/bin/sh
echo "udp listening"
while true; do
today=$(date +"%d-%b-%y")
#echo $today
_file="/home/stuart/ch_scada.log"
echo $_file
#echo "nc called here usually"
nc -luC 5001 >> "$_file"
sleep 1s
done

[later edit: I gave up on this bash code using nc and wrote a python program to receive the logging which I posted here [Local Link Removed for Guests]]

[BeanieBots]

Are you using mac addresses for anything such as determining who sent what?
If so, any ESP connecting via a wifi repeater will have a different mac id than if it were connected directly to the same wifi device as the receiver.
For some strange reason, wifi extenders change the first two bytes of the mac address

[Stuart]

Just to round this off, I think the problem was that the Annex device was known to the router as a static (reserved) address based on mac. The extender did indeed change the (supposedly immutable - isn't that the point?) mac address (first three bytes). This somehow seems to have muddled things up. Not clear exactly how. Ditching the extender and adjusting AP arrangements has solved the problem.

[BeanieBots]

Yep, I've seen that too. Using an extender gives it a 'virtual' mac ID which the router uses to maintained persistant IP addresses.
Because the mac ID has changed, so does the IP (SOMETIMES). When the IP lease expires, it all changes again.