[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-wpan
Subject:    Re: Interfacing mac802154 stack with userspace applications
From:       Victhor Foster <victhor.foster () ufpe ! br>
Date:       2019-11-12 9:03:27
Message-ID: 2006988758.2143768.1573549407203.JavaMail.zimbra () ufpe ! br
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]