cancel
Showing results for 
Search instead for 
Did you mean: 

Occasional Strange UDP Handling on GS-AX3000 - Any Ideas?

dpwhite
Level 9
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:

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.
317 Views
0 REPLIES 0