Radioless host sending NXP 802.15.4 data to a host at Google

asked 2026-08-30 21:12:36 +0000

updated 2026-09-04 22:33:33 +0000

In order to learn more about what goes on on my home network, I dump packets from time to time. One thing I like to check is the protocol hierarchy. Twice within the past week I have noticed that my homebuilt Linux box sends several NXP 802.15.4 sniffer packets over IPv6 to a host at Google. My homebuilt machine lacks a wifi radio, however; it is connected to the network via ethernet. At least I am certain there is no wireless dongle, and lspci shows nothing that looks like a radio or antenna. I gather from an AI answer that wireshark does look for data in the headers specific to that protocol, so it's not just flagging UDP from port 49999. Any idea what might cause this phenomenon? Have I been p0wned? Thanks in advance!

UPDATE

Using the test for channel length I saw in the code for the dissector, I created a wireshark filter that selects the packets in the sample file but does not select any of the packets from my network that had an endpoint with 49999/udp. There are 2 other tests to falsify a frame as NXP 802.15.4 Sniffer, but I think this filter will do me until I upgrade to 24.04 LTS:

nxp_802154_sniffer.channel >= 11 and nxp_802154_sniffer.channel <= 26

Again, thanks for the pointers!

Comments

There is a sample capture attached to 14301: Add dissector for NXP's 802.15.4 sniffer server messages

epan/dissectors/packet-nxp_802154_sniffer.c:

#define NXP_802154_SNIFFER_UDP_PORT             49999 /* Not IANA registered */
...
  dissector_add_uint_with_preference("udp.port", NXP_802154_SNIFFER_UDP_PORT, nxp_802154_sniffer_handle);

There are a couple checks in the dissector so would be interesting to see why your packets pass.

dissect_nxp_802154_sniffer(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void *data _U_)
{
...

    /* Check that the packet is long enough for it to belong to us. */
    if (tvb_reported_length(tvb) < 9)
        return 0;

    if (!test_nxp_802154_sniffer(tvb, offset)) {
        return 0;
    }

Chuckc ( 2026-08-31 12:34:13 +0000 )edit

Thank you ChuckC! See my comment on the answer, it is relevant to your comment as well. I took your clue, and I think I was able to follow the C code at gitlab well enough to form one possible explanation.

HansInAllenGassen ( 2026-09-03 04:52:29 +0000 )edit

add a comment

answered 2026-08-31 07:42:44 +0000

SYN-bit

18630 ●9 ●383 ●255 https://SYN-b.it

Wireshark does it's best to recognize protocols in two ways:

Static mappings, like ethertype 0x0800 is used for IPv4 or TCP port 80 is used for HTTP.
Heuristics, where the first part of the data is analyzed to see if it matches the characteristics of a known protocol. Like if there is an HTTP request on port 3523, Wireshark recognizes the HTTP formatted data and decides to dissect it as HTTP

Sometimes Wireshark seems to recognize protocol A, while in fact it was protocol B. You will need to do some manual checking of those cases whether Wireshark was actually right and you have something unexpected on your network or whether Wireshark was actually wrong and mixed things up.

If you need help with that, please save the packets you worry about to a new file using File -> export specifed packets... after you used a filter to just show these packets. You can then put it on any public fileshare and post the link here for us to have a look at it for you too.

edit flag offensive delete link

Comments

Thank you ChuckC and syn-bit for your responses and apologies for taking so long to respond. I should have noted that I am using Version 3.6.2 under Ubuntu 22.04 LTS. Another thing I am embarrassed to say I should have mentioned is that the UDP port on my machine is 49999 and the port on the remote host is 443.

I am not expert at reading C, but when I follow the link to the packet-nxp_802154_sniffer.c file, I do see in the function test_nxp_802154_sniffer() one of the tests checks channel, which I take to be the Channel element of the NXP 802.15.4 packet: if the value of channel is < 11 or > 26, the return value valid is set to false. For each of the packets in my pcap that give a value for Channel in the dissector, they fall outside of those ...(more)

HansInAllenGassen ( 2026-09-03 04:43:10 +0000 )edit

See: https://gitlab.com/wireshark/wireshar... The heuristics were added after version 4.0.1

SYN-bit ( 2026-09-03 06:23:03 +0000 )edit

#18695 was created as a confidential issue/work item so not visible when clicked on.
There is a pending request to make it public.

Chuckc ( 2026-09-03 12:48:46 +0000 )edit

Ah... I did not check, thanks for the additional info. But in short, yes, before the change, there were no heuristics in the NXP 802.15.4 dissector, meaning all UDP packets on port 49999 would be dissected as NXP 802.15.4, as you experienced. This won't be fixed in version 3.6.x

SYN-bit ( 2026-09-03 20:51:20 +0000 )edit

Thank you! You have both taught me some new things. I am still behind the LTSs by one, I'll check to see if 24.04 LTS has version 4.0.1.

HansInAllenGassen ( 2026-09-03 23:22:43 +0000 )edit

see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Radioless host sending NXP 802.15.4 data to a host at Google

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Radioless host sending NXP 802.15.4 data to a host at Google edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Radioless host sending NXP 802.15.4 data to a host at Google