Mystery guest MAC in RXPK packets

Gateways
1

To track the status of a set of 3 gateways (all mikrotik) I forward the packets of all three to both TTN NMS and a passive UDP listener on a VPS.

From the the UDP packets I strip the protocol version and token, decode the MAC and parse the STAT json. ( see packet_forwarder/PROTOCOL.TXT at master · Lora-net/packet_forwarder · GitHub )
Used code for that is at <?php$socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP);if (!$socket) { - Pastebin.com

Now I have the weird situation that in this forwarded traffic, RXPK packets pop up in my logs that have a MAC that is unknown to me…

These packets are valid LORA, but I do not understand how traffic of this unknown MAC ends up in my stream. I happens consistently multiple times, and they tend to start with e2…

Example of MACs that are not known to me : e2003133303762… and e20032353132…

Of course I can filter those out, but what am I missing here?

2

Perhaps the fact that GW’s are transparent and make no decisions as to which traffic they forward…they will send ALL valid LoRaWAN packets received from whatever source to the NS…which then decides if they are from that network and action or send to any peering arrangement or just drop…

I need to go check who would issue e2’s…

3

Thnx Jeff, but all other RXPK packets have the MAC of the forwarding gateway. The actual packet data is in the RXPK section.

I am talking about byte 4-11 Gateway unique identifier (MAC address). This is added to the packet by the gateway, correct?

4

Ok just for the sake, this is the unique list of mac adresses that I get after a few hours collecting :

e000313330376200
e000323531321500
e000323531322f00
e100313330376200
e100323531321500
e100323531322f00
e200313330376200
e200323531321500
e200323531322f00
e300313330376200
e300323531321500
e300323531322f00
e400313330376200
e400323531322f00
e500313330376200
e500323531321500
e500323531322f00
e600323531321500
e600323531322f00
e700313330376200
e700323531321500
e800313330376200
e800323531321500
e800323531322f00
e900313330376200
e900323531321500
e900323531322f00
ea00313330376200
ea00323531321500
ea00323531322f00
eb00313330376200
eb00323531321500
eb00323531322f00
ec00313330376200
ec00323531322f00
ed00313330376200
ed00323531321500
ed00323531322f00
ee00313330376200
ee00323531321500
ee00323531322f00
ef00313330376200
ef00323531322f00
f000313330376200
f000323531321500
f000323531322f00
f100313330376200
f100323531321500
f100323531322f00
f200313330376200
f200323531321500
f200323531322f00
f300313330376200
f300323531322f00
f400313330376200
f400323531321500
f400323531322f00
5

The hordes of script-kiddies probing everything and anything they can on the internet looking for things to hack in to?

1 Like
6

You’re probably mis-parsing something else that isn’t in the format of expected signal reports or stats messages.

Look at the entirety of the unexpected messages inntheir raw form.

1 Like