Re: Interfacing mac802154 stack with userspace applications

[Victhor Foster <victhor.foster@ufpe.br>]

Hi Alexander,

> Hi Victhor,
>
> On Fri, Oct 25, 2019 at 6:39 PM Victhor Foster <victhor.foster@ufpe.br> wrote:
>>
>> Hello,
>>
>> I'm working on a project to implement a 6LoWPAN network using software defined
>> radios. I'm trying to interface the kernel's 802.15.4/6LoWPAN stacks to my
>> physical layer implemented in GNU Radio, instead of using a userspace stack,
>> but this isn't working very well.
>>
>> The reason why I'm doing this is, while the GNU Radio plugin I'm using
>> (gr-ieee802-15-4 from Bastian Bloessl) implements its own 802.15.4 MAC layer,
>> I'd like to get around its limitations (such as not being able to change
>> destination addresses at runtime) using the Linux kernel stack.
>>
>
> It's possible to change the destination address. Do you use af802154?
>
I was referring to the MAC built into the GNU Radio plug-in. It doesn't use af802154, and there seems to be no way to change addresses at runtime on this plugin, from what I can tell.

>> The way this is being done is I have socat piping between a mac802154_hwsim
>> interface and GNU Radio, using the following arguments: INTERFACE:wpan0
>> UDP4-DATAGRAM:127.0.0.1:<port>
>> GNU Radio is running a UDP server at <port> that transmits and receives PDUs
>> to/from the software defined PHY, which then goes out to a software defined
>> radio device (a USRP N210, in this case). So the PDUs are sent via the socat
>> pipe to the hwsim network interface and vice-versa. The 802.15.4 MAC block is
>> removed.
>>
>> While 802.15.4 packets are sent and received by both hosts, it seems these
>> packets aren't getting through to the 6LoWPAN stack.
>>
> Mhh, do you can provide more information about the setup so I can test
> it on my own? Do you took care about channel/page and panid settings?
>
I have a GNU Radio flowgraph that is based on one of the gr-ieee802-15-4 examples. The PHY block's data input/output are connected to a "socket PDU" block that listens on a UDP port, and is able to send and receive data on this UDP port. The PHY block has signal input/output that is connected to the transmitter and receiver blocks for the SDR.
To set up the hwsim interfaces, I made a script that runs the following commands on the host:

wpan-hwsim del 1
ip link set down dev wpan0
ip link set mtu 127 dev wpan0
ip link add link wpan0 name lowpan0 type lowpan
iwpan dev wpan0 set pan_id 0xabcd
ip link set up dev wpan0
ip link set up dev lowpan0

(ieee802154_socket and mac802154_hwsim modules are already loaded)

Then I launch GNU Radio and connect that to the hwsim interface using: socat UDP:127.0.0.1:<port on "socket PDU" block> INTERFACE:wpan0
I have 2 hosts for testing, and these procedures are repeated on the other host (so they both have the same pan_id).
lowpan* interfaces on both hosts are assigned a link-local address by the OS, which I don't change.
Both hosts are running Ubuntu 18.04 with kernel package 5.0.0-29-generic from the repository.
I have them set to the same channel/page and pan_id, but the channel/page doesn't matter as GNU Radio doesn't use these settings, it has its own frequency selection and both devices are operating on the same channel.

Hopefully this is a clear explanation of my setup.

>> During testing, I had packet capture set up on both the 802.15.4 ("wpan0") and
>> the 6LoWPAN ("lowpan0") interfaces. The wpan0 interface was receiving packets
>> from the other host (and also from itself, as the radio is full duplex), as
>> expected. However, I could not get wpan-ping to work (timeout) and ping6,
>> netcat, etc. wouldn't get a response from the other host.
>> On the lowpan0 interface, I could see the packets originating from applications
>> would appear on the packet capture log, but those that should be coming from
>> the wpan0 interface wouldn't, even those originating from the host itself (due
>> to the full duplex nature of the radio).
>>
>
> No idea, this is now your gnuradio device?

Yes. GNU Radio is connected to the wpan0 device via the socat bridge.

>> I also noticed the following message on the kernel log: ieee802154 phy0 wpan0:
>> encryption failed: -22
>> I haven't touched the link encryption settings, so the traffic is unencrypted.
>
> This looks that you receive encrypted frames, it might be only the
> frame control field is misleading and security is enabled, can you
> check?
>
CONFIG_IEEE802154_NL802154_EXPERIMENTAL is not enabled on this kernel, so link layer security is not available, I presume?
>>
>> What could be done to get the 6LoWPAN stack to accept packets injected into the
>> 802.15.4 interface by socat? I realize this is a very unusual situation, but
>> I'm not familiar with the Linux 802.15.4 stack.
>
> No idea, sorry for my late reply. Can you provide more information?
>
Sorry about my late reply as well, I needed access to the lab machine I was working on and I could only get it last Thursday, I tried to send this email with the GNU Radio file I used attached, and that got rejected, so I'm sending it again with this attachment removed.
What I meant to say is, I want the stack to accept the packets from GNU Radio, so layer 3 and above will work i.e. the packets that are correctly decoded by the PHY are sent to the MAC, where they can be processed and sent to the layers above, so I can run applications over this link, thus allowing this system to be used to link multiple nodes together.

I had done another test a few days ago, but this time I eliminated the radios, instead I configured a loopback between the PHY input and output. I also set up another hwsim interface and had the edges set up so they could both communicate with each other.
When I pinged one interface from the other, I could see a duplicated response, which came about a second or so later. This means GNU Radio adds significant latency, which was already known, but I wasn't accounting for this when I tested originally, I left the timeouts as default. I didn't expect the latency to be so significant. I might have to test this later using higher timeout settings.
This setup was used to communicate with a Contiki node running their old Rime stack, as this is one of the examples included in the gr-ieee802-15-4 project, which is why I didn't expect latency to be such a problem.


Victhor