I’ve been trying to set up a local network server using the V3 stack, following the instructions at https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.0.4/doc/gettingstarted.md. So far, I’ve tested it with a Kerlink gateway with the Semtech UDP packet forwarder installed, and everything seems to work all right. Uplinks are received and published to the corresponding “up” MQTT topic.
The thing is that I would like to test the network server with many gateways and devices, which I’m not able to obtain physically, so I’ve tried writting a program to emulate the UDP packet forwarder locally on the computer. Looking at the contents of the UDP packets being sent by the Kerlink, along with the protocol description at https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT and a packet generator (https://www.npmjs.com/package/lora-packet), I’m able to create and send packets that look like the real ones.
When I run the emulator (with a single device as a first test), in the V3 stack log I get “INFO Connected” for the gateway, which is good. The problem is that when I start sending packets (with a test payload, periodically) I get the following log message “INFO Finished unary call duration=1.200644658s error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver:device_not_found (device not found) error_correlation_id=4c6d339ffee34624a8fc985a1ce885af error_name=device_not_found error_namespace=pkg/networkserver grpc_code=NotFound grpc_method=HandleUplink grpc_service=ttn.lorawan.v3.GsNs namespace=grpc request_id=01DGCHMT52HWDGQWTKSK9YH3Z3” for the first message, and “WARN Packet filtered” for the rest of the messages.
Do you have any idea of what the problem could be?
Maybe some field in the emulated packets is not correct, what criteria does the stack use to filter the Semtech UDP packets?
But how does the network server know whether the packet was sent from an emulator or from a real gateway if it only receives the UDP packets?
I didn’t mention it but the virtual gateway and device are registered on the server as if they were real physical ones, of course. And what could be the source of the first error?
Emulated devices transmitting through an emulated gateway would presumably not have those same transmissions duplicated on any physical gateway, so the servers should always choose the emulated gateway for any downlink reply, and things would be fine.
As for your issue, are you properly emulating a LoRaWan node configured to work with TTN? If you aren’t sending fake packets that match what a real one would send, (matching keys and all) then the network won’t accept the traffic. If your frame counter restarts and you haven’t disabled that check, then the server will reject the traffic, etc.
How are you emulating the nodes that feed data to your emulated gateway? Or where are you getting the pretend packets from? Replay data should be rejected, as it looks like a replay attack.
What the program does is create a thread for each emulated device, with its own frame counter and variables for the keys. Each thread will send the UDP packets adding the fake gateway’s EUI to the header, as described in the PROTOCOL.TXT file. The frame counter is incremented starting from 1 for each thread, and the frequency value in the “rxpk” JSON array is also changed with each packet sent (alternating between 868.3, 868.5, 868.1, etc).
Therefore, the only things in common for each packet are the same message inside the LoRa payload, and all the other parameters in the UDP packet’s JSON structure (“rssi”, “codr”, “datr”, etc). Could that be making the network server filter the packets?
The devices and gateways have been all configured using the cli interface, and for now I’m only actually testing the program emulating 1 device and 1 gateway, to make it simpler. I also don’t know what is causing the first “device_not_found” error, given that the device is configured in the network server.
I have also compared the emulated UDP packets with real ones from a Kerlink station, using tcpdump, and they look the same, but the Kerlink ones are correctly detected by the network server…
