6lowpan with external radio

6lowpan with external radio

[Henning Rogge]

Hi,

I am working with an external VHF radio attached over a serial
connection (USB serial at the moment) and looking for a way to use the
Linux 6lowpan stack with this radio.

Is there a way to get a TUN/TAP equivalent for 6lowpan, just getting
the raw frames back through a socket into userspace?

Henning Rogge

Re: 6lowpan with external radio

[Marcel Holtmann]

Hi Henning,

> I am working with an external VHF radio attached over a serial
> connection (USB serial at the moment) and looking for a way to use the
> Linux 6lowpan stack with this radio.
> 
> Is there a way to get a TUN/TAP equivalent for 6lowpan, just getting
> the raw frames back through a socket into userspace?

there is no interface for this. You will need to build an interface to create 6LoWPAN network devices from userspace and allow reading/writing from it.

Regards

Marcel

Re: 6lowpan with external radio

[Henning Rogge]

I had a look at the fakelb driver,

if I understand it right it just "connect" the raw-frame side of
multiple 6lowpan interfaces with each other, right? So it might be
part of the solution...

the other part should be similar to the tun.c driver... unfortunately
the tun driver got quite complex from what I can see.

Henning Rogge

On Thu, Nov 6, 2014 at 4:36 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Henning,
>
>> I am working with an external VHF radio attached over a serial
>> connection (USB serial at the moment) and looking for a way to use the
>> Linux 6lowpan stack with this radio.
>>
>> Is there a way to get a TUN/TAP equivalent for 6lowpan, just getting
>> the raw frames back through a socket into userspace?
>
> there is no interface for this. You will need to build an interface to create 6LoWPAN network devices from userspace and allow reading/writing from it.
>
> Regards
>
> Marcel
>

Re: 6lowpan with external radio

[Alexander Aring]

Hi,

On Thu, Nov 06, 2014 at 05:33:51PM +0100, Henning Rogge wrote:
> I had a look at the fakelb driver,
> 
> if I understand it right it just "connect" the raw-frame side of
> multiple 6lowpan interfaces with each other, right? So it might be
> part of the solution...
> 
> the other part should be similar to the tun.c driver... unfortunately
> the tun driver got quite complex from what I can see.
> 

do you use a 802.15.4 radio? Then maybe the serial driver is something
like that what you searching for.

btw. 6LoWPAN is specified for 802.15.4 and btle, maybe there exists also
some other drafts for different L2 layers.


The serial protocol:

There exist a "special" serial protocol v1 and v2.

The serial v2 is only theory concept. v1 is described at [0].

How does it work?

You have some little mcu with an 802.15.4 radio and a special firmware
on it which speaks this protocol via serial bus [0].

On linux side you have a special serial driver [1] which makes an wpan
interface. You can use this driver with any serial device which speaks
this protocol.



Now the big part, this cames never into mainline and I don't want to
accept the current state of driver implementation at [1]. There was also
some subsystem changes. The driver at [1] needs to port to the new
changes. Porting this driver should not be difficult... but there are
also some other parts at this driver why the driver isn't mainlineable.

The idea about a serial driver isn't forgotten but I don't have
currently time to care about that. Have enough to do to keep the
802.15.4 subsystem alive.

- Alex

[0] http://linux-zigbee.sourceforge.net/cgi-bin/trac.cgi/wiki/SerialV1
[1] https://github.com/linux-wpan/linux-wpan-next/commit/546618171de2be30236aab86f3ee323b425e2bf5

Re: 6lowpan with external radio

[Henning Rogge]

On Thu, Nov 6, 2014 at 5:54 PM, Alexander Aring <alex.aring@gmail.com> wrote:
> Hi,
>
> On Thu, Nov 06, 2014 at 05:33:51PM +0100, Henning Rogge wrote:
>> I had a look at the fakelb driver,
>>
>> if I understand it right it just "connect" the raw-frame side of
>> multiple 6lowpan interfaces with each other, right? So it might be
>> part of the solution...
>>
>> the other part should be similar to the tun.c driver... unfortunately
>> the tun driver got quite complex from what I can see.
>>
>
> do you use a 802.15.4 radio? Then maybe the serial driver is something
> like that what you searching for.

No, its not a 802.15.4 radio... its mostly layer 1 and some "listen
before talk/ALOHA" media access. I can send it raw frames (with a few
header fields) and get everything the radio receives via serial port.

A friend of mine suggested looking into 6lowpan instead of writing my
own fragmentation/IP-compression/... scheme. The radio is very slow,
so I need something efficient.

Henning Rogge

Re: 6lowpan with external radio

[Alexander Aring]

Hi,

On Thu, Nov 06, 2014 at 06:00:49PM +0100, Henning Rogge wrote:
> On Thu, Nov 6, 2014 at 5:54 PM, Alexander Aring <alex.aring@gmail.com> wrote:
> > Hi,
> >
> > On Thu, Nov 06, 2014 at 05:33:51PM +0100, Henning Rogge wrote:
> >> I had a look at the fakelb driver,
> >>
> >> if I understand it right it just "connect" the raw-frame side of
> >> multiple 6lowpan interfaces with each other, right? So it might be
> >> part of the solution...
> >>
> >> the other part should be similar to the tun.c driver... unfortunately
> >> the tun driver got quite complex from what I can see.
> >>
> >
> > do you use a 802.15.4 radio? Then maybe the serial driver is something
> > like that what you searching for.
> 
> No, its not a 802.15.4 radio... its mostly layer 1 and some "listen
> before talk/ALOHA" media access. I can send it raw frames (with a few
> header fields) and get everything the radio receives via serial port.
> 
> A friend of mine suggested looking into 6lowpan instead of writing my
> own fragmentation/IP-compression/... scheme. The radio is very slow,
> so I need something efficient.
> 

don't know how you can run 6LoWPAN on it. There exist 802.15.4 6LoWPAN
[0] and BTLE 6LoWPAN [1]. You need many L2 informations at 6LoWPAN level
for exmaple running IPv6 compression mechanism.

- Alex

[0] https://tools.ietf.org/html/rfc4944 - also see 6282 and 6775
[1] http://tools.ietf.org/html/draft-ietf-6lo-btle-03 (hope this is the newest one)

Re: 6lowpan with external radio

[Henning Rogge]

On Thu, Nov 6, 2014 at 6:55 PM, Carlo Vallati
<carlo.vallati@iet.unipi.it> wrote:
> Hi,
> you can also take a look at this work in progress of mine [0] in which I'm
> implementing a driver for the Xbee s1 cards.
> The implementation is still a work in progress, so it has only the basic TX
> and RX operations and it includes the latest subsystem changes (at least the
> version included in the 3.16 kernel).
> The driver communicates with the Xbee s1 card using a serial protocol to
> receive/send raw data, while most of the 802.15.4 are implemented in
> hardware (for this reason its structure follows the fakehard.c driver).

I will have a look at it... thank you.

> Even if your radio it's not 802.15.4, maybe you can emulate/simulate some of
> the operations and information needed by the upper layers.

If I understand the difference between the "soft" and the "hard" style
drivers right, the soft ones can work with a more stupid hardware,
correct?

Henning

Re: 6lowpan with external radio

[Carlo Vallati]

On 11/06/2014 07:01 PM, Henning Rogge wrote:
> On Thu, Nov 6, 2014 at 6:55 PM, Carlo Vallati
> <carlo.vallati@iet.unipi.it> wrote:
>> Hi,
>> you can also take a look at this work in progress of mine [0] in which I'm
>> implementing a driver for the Xbee s1 cards.
>> The implementation is still a work in progress, so it has only the basic TX
>> and RX operations and it includes the latest subsystem changes (at least the
>> version included in the 3.16 kernel).
>> The driver communicates with the Xbee s1 card using a serial protocol to
>> receive/send raw data, while most of the 802.15.4 are implemented in
>> hardware (for this reason its structure follows the fakehard.c driver).
> 
> I will have a look at it... thank you.
> 
>> Even if your radio it's not 802.15.4, maybe you can emulate/simulate some of
>> the operations and information needed by the upper layers.
> 
> If I understand the difference between the "soft" and the "hard" style
> drivers right, the soft ones can work with a more stupid hardware,
> correct?

Take a look here [0], in HardMAC devices the MAC layer is implemented in
the device itself, in SoftMAC the MAC layer is mainly implemented in
software, as the hardware is merely a radio transceiver.

[0] https://www.kernel.org/doc/Documentation/networking/ieee802154.txt

> 
> Henning
> 


-- 
-------------------------------------
Carlo Vallati, PhD
Post Doc Researcher
Computer Networking Group
Dipartimento di Ingegneria dell'Informazione
Università di Pisa
Via Diotisalvi 2, 56122 Pisa - Italy
Ph. : (+39) 050-2217.572 (direct) .599 (switch)
Fax : (+39) 050-2217.600
Skype: warner83
E-mail: carlo.vallati@iet.unipi.it
http://www.iet.unipi.it/c.vallati/

-----------------------------------------------

Re: 6lowpan with external radio

[Alexander Aring]

Hi,

On Thu, Nov 06, 2014 at 07:13:44PM +0100, Carlo Vallati wrote:
> On 11/06/2014 07:01 PM, Henning Rogge wrote:
> > On Thu, Nov 6, 2014 at 6:55 PM, Carlo Vallati
> > <carlo.vallati@iet.unipi.it> wrote:
> >> Hi,
> >> you can also take a look at this work in progress of mine [0] in which I'm
> >> implementing a driver for the Xbee s1 cards.
> >> The implementation is still a work in progress, so it has only the basic TX
> >> and RX operations and it includes the latest subsystem changes (at least the
> >> version included in the 3.16 kernel).
> >> The driver communicates with the Xbee s1 card using a serial protocol to
> >> receive/send raw data, while most of the 802.15.4 are implemented in
> >> hardware (for this reason its structure follows the fakehard.c driver).
> > 
> > I will have a look at it... thank you.
> > 
> >> Even if your radio it's not 802.15.4, maybe you can emulate/simulate some of
> >> the operations and information needed by the upper layers.
> > 
> > If I understand the difference between the "soft" and the "hard" style
> > drivers right, the soft ones can work with a more stupid hardware,
> > correct?
> 
> Take a look here [0], in HardMAC devices the MAC layer is implemented in
> the device itself, in SoftMAC the MAC layer is mainly implemented in
> software, as the hardware is merely a radio transceiver.
> 
> [0] https://www.kernel.org/doc/Documentation/networking/ieee802154.txt
> 

This Documentation is mostly outdated will be updated after finished the
rework.

HardMAC drivers have some special protocol. For example MLME operations
the driver only know's the interface. Doing the algorithmn is done by
transceiver. The transceiver offers these interface to start such MLME
operation.

- Alex

Re: 6lowpan with external radio

[Alexander Aring]

On Thu, Nov 06, 2014 at 06:55:11PM +0100, Carlo Vallati wrote:
> Hi,
> you can also take a look at this work in progress of mine [0] in which I'm
> implementing a driver for the Xbee s1 cards.
> The implementation is still a work in progress, so it has only the basic TX
> and RX operations and it includes the latest subsystem changes (at least
> the version included in the 3.16 kernel).
> The driver communicates with the Xbee s1 card using a serial protocol to
> receive/send raw data, while most of the 802.15.4 are implemented in
> hardware (for this reason its structure follows the fakehard.c driver).
> 

well, I removed now any HardMAC functionality because it never had any
functionality. For example [0].

This was used by the fakehard driver but there was no real netlink
interface which used these calls. HardMAC driver is another topic for
the future.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=9f3295b9ea8e54a6c65231d267f069edf420b64f

Re: 6lowpan with external radio

[Alexander Aring]

Hi Carlo,

On Thu, Nov 06, 2014 at 07:24:03PM +0100, Alexander Aring wrote:
> On Thu, Nov 06, 2014 at 06:55:11PM +0100, Carlo Vallati wrote:
> > Hi,
> > you can also take a look at this work in progress of mine [0] in which I'm
> > implementing a driver for the Xbee s1 cards.
> > The implementation is still a work in progress, so it has only the basic TX
> > and RX operations and it includes the latest subsystem changes (at least
> > the version included in the 3.16 kernel).
> > The driver communicates with the Xbee s1 card using a serial protocol to
> > receive/send raw data, while most of the 802.15.4 are implemented in
> > hardware (for this reason its structure follows the fakehard.c driver).
> > 
> 
> well, I removed now any HardMAC functionality because it never had any
> functionality. For example [0].
> 
> This was used by the fakehard driver but there was no real netlink
> interface which used these calls. HardMAC driver is another topic for
> the future.
> 

this will not mean that I don't accept HardMAC drivers. I do now a
rework of this branch which looks very similar like wireless/mac80211
afterwards.

The HardMAC functionality should be look like wireless. This
means a cfg802154 implementation inside driver layer. Also netdev
allocation/registration etc.. is inside driver layer. cfg802154 is just
a callback structure for the netlink 802.15.4 calls.

Really the current mainline HardMAC functionality was in some broken
state which never had any functionality.


I hope you are not too frustrated now. :-)

- Alex

Re: 6lowpan with external radio

[Carlo Vallati]

On 11/06/2014 08:34 PM, Alexander Aring wrote:
> Hi Carlo,
>
> On Thu, Nov 06, 2014 at 07:24:03PM +0100, Alexander Aring wrote:
>> On Thu, Nov 06, 2014 at 06:55:11PM +0100, Carlo Vallati wrote:
>>> Hi,
>>> you can also take a look at this work in progress of mine [0] in which I'm
>>> implementing a driver for the Xbee s1 cards.
>>> The implementation is still a work in progress, so it has only the basic TX
>>> and RX operations and it includes the latest subsystem changes (at least
>>> the version included in the 3.16 kernel).
>>> The driver communicates with the Xbee s1 card using a serial protocol to
>>> receive/send raw data, while most of the 802.15.4 are implemented in
>>> hardware (for this reason its structure follows the fakehard.c driver).
>>>
>>
>> well, I removed now any HardMAC functionality because it never had any
>> functionality. For example [0].
>>
>> This was used by the fakehard driver but there was no real netlink
>> interface which used these calls. HardMAC driver is another topic for
>> the future.
>>
>
> this will not mean that I don't accept HardMAC drivers. I do now a
> rework of this branch which looks very similar like wireless/mac80211
> afterwards.

I really do understand that. Although I had some experience with 
mac80211 driver, it took me a while to understand the structure of the 
802154 driver. A rework is more than welcome!

>
> The HardMAC functionality should be look like wireless. This
> means a cfg802154 implementation inside driver layer. Also netdev
> allocation/registration etc.. is inside driver layer. cfg802154 is just
> a callback structure for the netlink 802.15.4 calls.
>
> Really the current mainline HardMAC functionality was in some broken
> state which never had any functionality.


Yes I understand. As the support for HardMAC will be defined and 
included again I'll align my work and then you can evaluate it for 
inclusion (in case you think can be of interest).

>
>
> I hope you are not too frustrated now. :-)

No problem, I needed to write the driver anyway to run some experiments :-)

>
> - Alex
>


-- 
-------------------------------------
Carlo Vallati, PhD
Post Doc Researcher
Computer Networking Group
Dipartimento di Ingegneria dell'Informazione
Università di Pisa
Via Diotisalvi 2, 56122 Pisa - Italy
Ph. : (+39) 050-2217.572 (direct) .599 (switch)
Fax : (+39) 050-2217.600
Skype: warner83
E-mail: carlo.vallati@iet.unipi.it
http://www.iet.unipi.it/c.vallati/

-----------------------------------------------

Re: 6lowpan with external radio

[Carlo Vallati]

Hi,
you can also take a look at this work in progress of mine [0] in which
I'm implementing a driver for the Xbee s1 cards.
The implementation is still a work in progress, so it has only the basic
TX and RX operations and it includes the latest subsystem changes (at
least the version included in the 3.16 kernel).
The driver communicates with the Xbee s1 card using a serial protocol to
receive/send raw data, while most of the 802.15.4 are implemented in
hardware (for this reason its structure follows the fakehard.c driver).

Even if your radio it's not 802.15.4, maybe you can emulate/simulate
some of the operations and information needed by the upper layers.
Best,

Carlo

[0] https://github.com/warner83/linuxbee/

On 11/06/2014 06:08 PM, Alexander Aring wrote:
> Hi,
> 
> On Thu, Nov 06, 2014 at 06:00:49PM +0100, Henning Rogge wrote:
>> On Thu, Nov 6, 2014 at 5:54 PM, Alexander Aring <alex.aring@gmail.com> wrote:
>>> Hi,
>>>
>>> On Thu, Nov 06, 2014 at 05:33:51PM +0100, Henning Rogge wrote:
>>>> I had a look at the fakelb driver,
>>>>
>>>> if I understand it right it just "connect" the raw-frame side of
>>>> multiple 6lowpan interfaces with each other, right? So it might be
>>>> part of the solution...
>>>>
>>>> the other part should be similar to the tun.c driver... unfortunately
>>>> the tun driver got quite complex from what I can see.
>>>>
>>>
>>> do you use a 802.15.4 radio? Then maybe the serial driver is something
>>> like that what you searching for.
>>
>> No, its not a 802.15.4 radio... its mostly layer 1 and some "listen
>> before talk/ALOHA" media access. I can send it raw frames (with a few
>> header fields) and get everything the radio receives via serial port.
>>
>> A friend of mine suggested looking into 6lowpan instead of writing my
>> own fragmentation/IP-compression/... scheme. The radio is very slow,
>> so I need something efficient.
>>
> 
> don't know how you can run 6LoWPAN on it. There exist 802.15.4 6LoWPAN
> [0] and BTLE 6LoWPAN [1]. You need many L2 informations at 6LoWPAN level
> for exmaple running IPv6 compression mechanism.
> 
> - Alex
> 
> [0] https://tools.ietf.org/html/rfc4944 - also see 6282 and 6775
> [1] http://tools.ietf.org/html/draft-ietf-6lo-btle-03 (hope this is the newest one)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
-------------------------------------
Carlo Vallati, PhD
Post Doc Researcher
Computer Networking Group
Dipartimento di Ingegneria dell'Informazione
Università di Pisa
Via Diotisalvi 2, 56122 Pisa - Italy
Ph. : (+39) 050-2217.572 (direct) .599 (switch)
Fax : (+39) 050-2217.600
Skype: warner83
E-mail: carlo.vallati@iet.unipi.it
http://www.iet.unipi.it/c.vallati/

-----------------------------------------------