* Interfacing mac802154 stack with userspace applications
@ 2019-10-25 22:20 Victhor Foster
2019-11-06 14:02 ` Alexander Aring
0 siblings, 1 reply; 6+ messages in thread
From: Victhor Foster @ 2019-10-25 22:20 UTC (permalink / raw)
To: linux-wpan
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.
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.
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).
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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Interfacing mac802154 stack with userspace applications 2019-10-25 22:20 Interfacing mac802154 stack with userspace applications Victhor Foster @ 2019-11-06 14:02 ` Alexander Aring 2019-11-12 9:03 ` Victhor Foster 0 siblings, 1 reply; 6+ messages in thread From: Alexander Aring @ 2019-11-06 14:02 UTC (permalink / raw) To: Victhor Foster; +Cc: linux-wpan - ML 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? > 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? > 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? > 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? > > 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? - Alex ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Interfacing mac802154 stack with userspace applications 2019-11-06 14:02 ` Alexander Aring @ 2019-11-12 9:03 ` Victhor Foster 2020-03-10 0:25 ` Victhor Foster 0 siblings, 1 reply; 6+ messages in thread From: Victhor Foster @ 2019-11-12 9:03 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Interfacing mac802154 stack with userspace applications 2019-11-12 9:03 ` Victhor Foster @ 2020-03-10 0:25 ` Victhor Foster 2020-03-13 13:54 ` Alexander Aring 0 siblings, 1 reply; 6+ messages in thread From: Victhor Foster @ 2020-03-10 0:25 UTC (permalink / raw) To: linux-wpan I have resumed work on this project, and I decided to implement a few changes. I abandoned the socat approach and came up with a different implementation, modifying the linux-wpan example programs. I made two programs, one that receives packets from a wpan interface and outputs them to a UDP port, while the other program receives packets from a UDP port and sends them to a wpan interface. It seems to work well enough, but there's a problem with my approach. I need to get outgoing packets from the wpan interface. Is there a way to filter packets coming through a raw socket, such that only outgoing packets come out of the socket? Right now, I'm not filtering for outgoing packets, so when packets are received through my program and sent to the wpan interface, the same packets come out of the interface, as there's no filtering being done, causing a loop. I tried using the sll_pkttype field in the raw socket structure, but all packets received by the socket have the same value, so it's not useful, unfortunately. > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Interfacing mac802154 stack with userspace applications 2020-03-10 0:25 ` Victhor Foster @ 2020-03-13 13:54 ` Alexander Aring 2020-03-13 22:21 ` Victhor Foster 0 siblings, 1 reply; 6+ messages in thread From: Alexander Aring @ 2020-03-13 13:54 UTC (permalink / raw) To: Victhor Foster; +Cc: linux-wpan Hi, On Mon, Mar 09, 2020 at 09:25:08PM -0300, Victhor Foster wrote: > I have resumed work on this project, and I decided to implement a few > changes. I abandoned the socat approach and came up with a different > implementation, modifying the linux-wpan example programs. > aha, which one? > I made two programs, one that receives packets from a wpan interface > and outputs them to a UDP port, while the other program receives > packets from a UDP port and sends them to a wpan interface. It seems > to work well enough, but there's a problem with my approach. > You telling me something about UDP to a wpan interface. This makes no sense except you also building some IP layer in user space. > I need to get outgoing packets from the wpan interface. Is there a way > to filter packets coming through a raw socket, such that only outgoing > packets come out of the socket? > Now you saying something about RAW sockets, what kind of raw sockets? > Right now, I'm not filtering for outgoing packets, so when packets are > received through my program and sent to the wpan interface, the same > packets come out of the interface, as there's no filtering being done, > causing a loop. > > I tried using the sll_pkttype field in the raw socket structure, but > all packets received by the socket have the same value, so it's not > useful, unfortunately. > No, it smells for me you want to do something with traffic control and egress path. - Alex ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Interfacing mac802154 stack with userspace applications 2020-03-13 13:54 ` Alexander Aring @ 2020-03-13 22:21 ` Victhor Foster 0 siblings, 0 replies; 6+ messages in thread From: Victhor Foster @ 2020-03-13 22:21 UTC (permalink / raw) To: linux-wpan > Hi, > > On Mon, Mar 09, 2020 at 09:25:08PM -0300, Victhor Foster wrote: >> I have resumed work on this project, and I decided to implement a few >> changes. I abandoned the socat approach and came up with a different >> implementation, modifying the linux-wpan example programs. >> > > aha, which one? > I based my programs off the af_packet_rx and af_packet_tx examples. >> I made two programs, one that receives packets from a wpan interface >> and outputs them to a UDP port, while the other program receives >> packets from a UDP port and sends them to a wpan interface. It seems >> to work well enough, but there's a problem with my approach. >> > > You telling me something about UDP to a wpan interface. This makes no > sense except you also building some IP layer in user space. > Sorry for the misunderstanding, I'll try to explain it better. This is the data flow currently: [GNU Radio]--UDP socket-->[program 1]--raw wpan socket-->[wpan0] [GNU Radio]<--UDP socket--[program 2]<--raw wpan socket--[wpan0] (wpan0 is a hwsim interface) So the UDP socket is used only to transfer L2 packets to and from GNU Radio, which is where the PHY is implemented. This is like a SoftMAC-type radio, except the PHY is a userspace application, and not a piece of hardware. I'm trying to move L2 packets between my application and the wpan interface. >> I need to get outgoing packets from the wpan interface. Is there a way >> to filter packets coming through a raw socket, such that only outgoing >> packets come out of the socket? >> > > Now you saying something about RAW sockets, what kind of raw sockets? > Raw wpan sockets. Although I'm using ETH_P_ALL as the protocol, as the ETH_P_IEEE802154 protocol type does not output outgoing packets. >> Right now, I'm not filtering for outgoing packets, so when packets are >> received through my program and sent to the wpan interface, the same >> packets come out of the interface, as there's no filtering being done, >> causing a loop. >> >> I tried using the sll_pkttype field in the raw socket structure, but >> all packets received by the socket have the same value, so it's not >> useful, unfortunately. >> > > No, it smells for me you want to do something with traffic control and > egress path. True. In the meantime, I have been working on a possible solution for my problem, having the program that sends packets from the wpan interface to my GNU Radio application do the following checks: - Source MAC or short address is equal to the wpan interface's - Destination MAC or short address is not equal to that of the wpan interface - Destination MAC or short address is equal to the broadcast address I think this should avoid causing a loop. I haven't finished implementing these features yet, so I don't know if they will be effective. It's not the same as having proper flow control, though. I would need to implement a flow control mechanism to avoid this problem, I think. > - Alex ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-13 22:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-25 22:20 Interfacing mac802154 stack with userspace applications Victhor Foster 2019-11-06 14:02 ` Alexander Aring 2019-11-12 9:03 ` Victhor Foster 2020-03-10 0:25 ` Victhor Foster 2020-03-13 13:54 ` Alexander Aring 2020-03-13 22:21 ` Victhor Foster
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).