Return Code -11 Error upon Scapy Zigbee Transmission #1

[SullyM30]

Hi, I'm currently a researcher at Virginia Tech using this Scapy/GNU-RADIO setup on Ubuntu 22 VM (VMWARE 17)

I am using a USRP b205 mini over USB as my SDR and following the guide here: https://github.com/akestoridis/grc-ieee802154 to get my testbed operational.

I've successfully sniffed and piped packets into wireshark for over-the-air zigbee communication. Packets are viewable in wireshark and intact.

However, I'm running into an error that I can't seem to identify when trying to transmit. Working through the tests, I can send the test 'Hello World!' message and get the loop-back transmission in my pcap file. I can also send a generic 802.15.4 packet with no error over Scapy. However, when I attempt to send any Zigbee packet (the last step of testing), Scapy sends it over the UDP socket fine (the byte size is returned), however, immediately after socket.sendto. command, the transceiver flow graph terminates with 'return code -11'.

After some debugging, I think I've determined that this is because of the size of the packets being sent from scapy. The generic 802.15.4 packets are roughly 20 Bytes - significantly smaller than the Zigbee packets. For example, when I try sending 3-4 802.15.4 packets over Scapy for transmission successively, the flowgraph once again exits with the same return code. I've also seen that this code might mean a memory segmentation fault.

Have you seen a similar issue before? Any help would be greatly appreciated!

I've attached a screenshot below of my flowgraph connections when in Zigbee Transmission mode. I can provide any other screenshots as needed.

**Also if this is any help, when receiving packets, my terminal continuously outputs OOOOOoverflow errors from the USRP Source block, but still properly captures the packets. Internet says this is because my sampling rate is too high for my pc (Most likely because of CPU cores/RAM i've dedicated to the VM).

[bastibl]

Maybe that's a problem of your Scapy script. See here for some examples: https://archive.fosdem.org/2019/schedule/event/gr_scapy/attachments/slides/3366/export/events/attachments/gr_scapy/slides/3366/gnuradio_meets_scapy.pdf

[SullyM30]

Hi, thank you for the response. I tried that - but to no avail.

To clarify, the steps I take on scapy are.
a) do nc -u 127.0.0.1 52001 in a separate terminal
in scapy, then

import socket
from scapy.all import *
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
frame = Dot15d4FCS()/Dot15d4Data(dest_panid=0x4242, dest_addr=0x2323)/"Hello World!"
sock.sendto(bytes(frame), ("127.0.0.1", 52001))
(after this, scapy outputs the size of the package in bytes - for this '21')

However, I tried sending packets that are now of around 20 bytes and I'm getting this error in the terminal. Perhaps this may be the source of the issue?

"OOOusrp_sink :error: Tag gap (nitems_read = 0): no more items to send in current burst, but got 3336 more items; dropping them."

The flow graph won't terminate or anything, it'll just output this to the terminal and continue executing, but with not transmission.

Any insight here?

Again thank you!

[bastibl]

I just tried this and it works without problems for me. Error -11 is a segmentation fault. I assumed you send bogus data, causing it to crash. But the script is fine. You probably compiled the module (or gr-foo) against different (GNU Radio) libraries or have artifacts from older installation attempts on your system.

[SullyM30]

Ok. I'll try to do a fresh install then as well and then let you know how that shakes up.

One quick clarification. When you say compiled the module against different GNU Radio libraries, are you saying that the compiled modules don't match the GNU version that I'm using?

[bastibl]

You have to use, for example, the maint-3.10 branch of this module w/ GNU Radio 3.10.

But segfaults are often the result of having multiple versions of GNU Radio 3.10 installed on the same PC. Or some artifacts from previous installation attempts and an additional installation through the system package manager (e.g., apt on Ubuntu). In such cases the module might be compiled against a different version than it is linked during runtime or one module is compiled against the OS libraries but, for example, gr-foo is compiled against some version that was built from source.

[SullyM30]

Hi again! Sorry for the delayed response - I've been traveling and trying to make time to sink some hours into this.

I've made some measurable progress but am having a different issue now.

With your suggestion that the GNU libraries may be duplicated on my VM, I downloaded and am now using your instant-gnuradio. I receive everything correctly; however, when I try to transmit a message over UDP via Scapy, I can't pick up the message with a receiver, the Xbee I am trying to send it to, or with an oscilliscope.

I believe I have identified the issue and would very much appreciate if you could give any insight. To clarify, when I send the packet over scapy I get No Error anymore on the gnuradio end and everything seems normal.

However, upon further investigation, I believe that it is not transferring over the UDP socket. When I execute "nc -u 127.0.0.1 52001" or a tcpdump at that local host loopback connection, I cannot see any message being sent to the port.

Below are screenshot snippits of what gnuradio-flowgraph I am using, terminal output, and scapy commands.

***Note: I am following Dimitrios-Georgios Akestoridis' guide for using Scapy for transmission. I am also using a simplified version of the transmitter (in his respository: https://github.com/akestoridis/grc-ieee802154). That is pictured below.

Scapy code is as follows:

import socket
from scapy.all import *
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
frame = Dot15d4FCS(fcf_panidcompress=True, fcf_ackreq=True, fcf_srcaddrmode=2)/Dot15d4Data(dest_panid=0x4242, dest_addr=0x2323, src_addr=0x0101)/ZigbeeNWK(discover_route=1, flags='security', destination=0x2323, source=0x0101, radius=30)/ZigbeeSecurityHeader(data='Hello World!')
sock.sendto(bytes(frame), ("127.0.0.1", 52001))

(All commands run correctly, scapy returns the size of the packet in bytes after the last command)

Note: I tried this basic zigbee frame, just to see if it works, but in an actual testing environment, I capture a packet from the Xbee communication, read and select it using rdpcap, and then assign it to the frame variable instead.

Thank you so much for your help in advance, I'm excited to hear back!

[bastibl]

You can connect a "Message Debug Block" after the Socket PDU. This will show you, if the UDP part works and the flowgraph actually received the UDP frames.

To check, whether data is produced, you can pipe the IQ samples that go the SDR also in a file sink and check whether the file is empty.

The many 'O's on the terminal indicate that something is going wrong. Check USB drivers for the VM, i.e., install the VirtualBox extension pack. Otherwise it will not use the full rate.

Also, I tested it only with the simple scapy frame (as shown above) and flowgraphs from this repo. It was trivial to set up and worked without problems. I'm not sure what this other stuff is doing or why you are using it. Please try to get a basic setup working first.

Are you sure that the receiver firmware would show the frames and is set up correctly (i.e., listen on the correct channel etc.)