I am trying to resolve a problem with a wifi IoT device that communicates through my GS-AX3000 via UDP to a server on the WAN to report temperature. I have several of these and, at times, all of them appear to go offline. By this, I mean they seem to no longer be delivering UDP packets to the server on the WAN - at least the server reports that it is not getting them. Even while this is happening, the GS-AX3000 shows the device in the list of connected clients and the device can be pinged on the LAN. When this happened this morning, I managed to run tcpdump on my router for viewing in Wireshark and I see a pattern of UDP from the IP of the device.
The pattern shows 1 or more UDP messages that look like this:
Followed immediately by an equal number of almost identical UDP messages that look like this:
The difference between the two seems to be mainly: (a) the packet type and (b) the source MAC address. The first shows the MAC of the device while the second shows the router's wifi BSSID as the source. At first, I thought this was just an artifact of the router's handling of the message - maybe the firewall?
But the same capture file shows the UDP messages from several other different but identical devices - where I can confirm the messages are delivered to the same WAN server - with the same kind of messages. They look like the first shown above and there are none like the second shown above for any of these devices. And I cannot help but wonder if the presence of these "extra" messages are somehow to blame for the failure of the one device.
Thanks in advance for any light you can shed on this.
The pattern shows 1 or more UDP messages that look like this:
Frame 1250: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: LSDScien_e4:8b:00 (00:95:69:e4:8b:00)
Unused: 0000
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.23, Dst: 47.52.241.127
User Datagram Protocol, Src Port: 49154, Dst Port: 17000
Source Port: 49154
Destination Port: 17000
Length: 22
Checksum: 0x8b5a [unverified]
[Checksum Status: Unverified]
[Stream index: 4]
[Timestamps]
Data (14 bytes)
Data: 3c540169e48b0001010100006c3e
[Length: 14]Followed immediately by an equal number of almost identical UDP messages that look like this:
Frame 1252: 58 bytes on wire (464 bits), 58 bytes captured (464 bits) Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 1
Link-layer address length: 6
Source: 04:42:1a:47:f7:e8 (04:42:1a:47:f7:e8)
Unused: 0000
Protocol: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.23, Dst: 47.52.241.127 User Datagram Protocol, Src Port: 49154, Dst Port: 17000
Source Port: 49154
Destination Port: 17000
Length: 22
Checksum: 0x8b5a [unverified]
[Checksum Status: Unverified]
[Stream index: 4]
[Timestamps] Data (14 bytes)
Data: 3c540169e48b0001010100006c3e
[Length: 14]The difference between the two seems to be mainly: (a) the packet type and (b) the source MAC address. The first shows the MAC of the device while the second shows the router's wifi BSSID as the source. At first, I thought this was just an artifact of the router's handling of the message - maybe the firewall?
But the same capture file shows the UDP messages from several other different but identical devices - where I can confirm the messages are delivered to the same WAN server - with the same kind of messages. They look like the first shown above and there are none like the second shown above for any of these devices. And I cannot help but wonder if the presence of these "extra" messages are somehow to blame for the failure of the one device.
Thanks in advance for any light you can shed on this.
