Skip to content

Fix Thread Crash on Malformed Packets in UdpTransport

This MR fixes #1 (closed)

What's Changed: Added a try-except block in _incoming_pdu_handler to keep the UDP listener thread running even when it encounters malformed packets.

Why: This fix prevents the SPP server from going silent without being able to receive more packets, which can be crucial in maintaining communication in noisy environments or against potential denial-of-service attacks.

Testing: Tested with normal and malformed packets; the server now handles errors smoothly without stopping the packet reception:

(base) xxx@xxx:~/python-spp$ python examples/udp_transport/sink.py 
Running. Press <Enter> to stop...
Received Space Packet: <spp.space_packet.SpacePacket object at 0x7f3b459e7dc0>
   packet_type: 1, packet_sec_hdr_flag: 0, apid: 333, sequence_flags: 3, packet_sequence_count: 1, packet_version: 0, packet_data_field: b'This is a test packet!'
Exception in CustomUdpTransport._incoming_pdu_handler: Packet data length mismatch from ('127.0.0.1', 45077)
Traceback (most recent call last):
  File "/home/xxx/anaconda3/lib/python3.9/site-packages/spp/transport/udp.py", line 55, in _incoming_pdu_handler
    self.indication(pdu)
  File "/home/xxx/anaconda3/lib/python3.9/site-packages/spp/core.py", line 19, in _pdu_received
    space_packet = SpacePacket.decode(pdu)
  File "/home/xxx/anaconda3/lib/python3.9/site-packages/spp/space_packet.py", line 60, in decode
    raise ValueError("Packet data length mismatch")
ValueError: Packet data length mismatch

Received Space Packet: <spp.space_packet.SpacePacket object at 0x7f3b459e7dc0>
   packet_type: 1, packet_sec_hdr_flag: 0, apid: 333, sequence_flags: 3, packet_sequence_count: 1, packet_version: 0, packet_data_field: b'This is a test packet!'

Next Steps: Please take a look and let me know if there are any tweaks or further tests you would suggest!

Merge request reports