* Re: [linux-wpan] mac802154 development
2015-03-02 8:44 [linux-wpan] mac802154 development Ludwig, Mike
@ 2015-03-02 9:38 ` Alexander Aring
0 siblings, 0 replies; 2+ messages in thread
From: Alexander Aring @ 2015-03-02 9:38 UTC (permalink / raw)
To: Ludwig, Mike; +Cc: linux-wpan@vger.kernel.org
On Mon, Mar 02, 2015 at 08:44:12AM +0000, Ludwig, Mike wrote:
> Hi,
>
> after a few days checking through the mainline and bluetooth-next kernel regarding ieee/mac802154 and 6LoWPAN I'm rather puzzled about the current status and future developments.
>
See also with what we started:
https://archive.fosdem.org/2014/schedule/event/deviot04/
What we now try to do:
https://fosdem.org/2015/schedule/event/deviot09/
(slides currently available only)
> As the mac802154 is under rework I tried to follow the lines of a hardMAC (e.g. as fakehard.ko is doing it) thereby bypassing the mac802154 business completely. I started creating a serial driver that allows the attachment of a radio over a serial line on the MAC layer interface. The netlink routines did look quite promising.
>
Please forget the fakehard driver, I removed the whole driver because
there was one "virtual(fake)" driver for HardMAC and the rework
contain a completely new netlink framework based on nl80211.
Maybe you don't want a HardMAC driver. What exactly is the serial
protocol can you access raw frames or some interface according 802.15.4
standard to start MLME ops?
If you can access it raw than a HardMAC driver would be wrong otherwise
there already exist a serial protocol driver. Then you need some
firmware which speaks this protocol. The driver is in a very awful state
and it's not acceptable for mainline. See [0-2].
The idea of bypassing mac802154 completely still exist. But we will now
handle it 1:1 like wireless. This means over netlink ops will call
cfg802154_ops and cfg802154_ops callbacks need to define in driver
layer. Also other things netdev registration etc...
Send patches I will review them. But maybe you need some things from
net/mac802154 to net/ieee802154. Few weeks I saw some things which
should be moved because it should affects Soft and HardMAC drivers.
I need to send patches for this, if not anybody else do it. We have
currently no HardMAC support and if you like to implement such thing I
would help you there.
> Unfortunately I'm now already stuck at the scan request - or to be more precise at the scan response. In my understanding it is always the first step for any device (FFD or RFD) to scan for existing networks. In mainline at lease the results of a ED scan can be passed back via netlink. In bluetooth-next even the scan confirmation is gone. Is this for a reason?
We have at most SoftMAC drivers mainline and the old interface only
implemented these callbacks for the HardMAC drivers.
I am not sure that you realized that there are two netlink frameworks,
one based on nl802154 (the new fantastic interface which makes no
headache) and the poor old one which nobody figured out exactly how it
works (will be removed later).
We want now to do all the same like wireless (nl80211/cfg80211) they
have similar paradigms with 802.15.4 but different technology. For
example your MLME-SCAN (okay, we have different scan types) we should
look how wireless implemented the scan for access-points. Then we can do
the same like 802.15.4 just for pans. What I will say, we have a good
code-base then.
But doing ed scan will occur that drivers can note about ed values. The
at86rf230 can't (but the transceiver can do it), we need just implement
it but at first we need to get out from "something else" in "something
which works" that's what the rework try to do.
> Moreover, to do some real work by joining an existing WPAN a pan_desciptor_list would have to be passed back to netlink.
> I did not go further in checking on the start/associate/disassociate netlink parts as it would always be a crutch to create/join WPANs without working scans.
>
Yea, doing this step will do lot of work. Also for good code base look
how wireless deals with associate/disassociate with access points, then
we can do the same with coordinators. Just a little bit different
because we are 802.15.4. Again this is just to have a good code base.
> So this is more about seeking advice than implementation details. I'm quite happy to do add missing pieces to the netlink part but would like to do this in line with the rework of the MAC if this would have implications on that. It would be great if you could give me some hints on proceeding and may on the plans for the rework. I guess you already have some ideas on required changes an might point me to the right locations. Thanks a lot for your help.
>
You want to implement a HardMAC driver. When this is true, you don't
really need to care about net/mac802154 and that's the most part in the
actual reworks since I mostly successful implemented the nl802154 framework.
You can happily add new netlink commands and new interfaces to cfg802154
and yes I would be very happy and accept patches if these are fine.
Also if you do that, don't forget to add support into the official
userspace tool. [3]
For mac802154, some parts of them will affect also the upper layers
which need then a different handling mac802154 and all HardMAC drivers.
Example (very netdev specific):
We doing at the moment all parsed mac information into the control_block
of skb and send it through the layer after calling netif_receive_skb.
This is very bad and we do it also for parsing arguments through the
dev_header_create command. I also saw situations (for sniffing) which
breaks this interface. This works for some cases but it's awful and I
will remove it.
I segmented the rework in three different parts (currently I do 2.):
1. nl802154 <--- have some TODOs but mostly working
2. crypto-layer over nl802154 <--- I am here!
3. frame parsing/creation
So doing step 3 (which I do mostly in dev branch [4]) will require at
first a working state of 2, because I can't test it right now if I break
the crypto layer. Sounds crazy, but yea we have a kernel side crypto
layer and the official userspace tool can't access it. But this is the
current state and I currently try to change it.
Again to 3. and the link at [4]. What you see is a frame parsing
mechanism like mac802154 it does. It also introduce various static
inline function which can you use for HardMAC drivers (It's simple the
same way like wireless). But I can't send it mainline currently, I will
do this after step 2.
Also the new frame parsing/creation doesn't add mac information into the
skb control_block. We need to reparse the mac header (not the FULL mac
header only what's necessary) in the upper-layers like af802154 and 6lowpan.
Also the frame parsing is only optimized for dataframes, see [4] how the
new frameparsing works. Again, it's from mac80211 and they have more
frametypes than 4. Later I want also this type for frameparsing in
6LoWPAN for evaluating dispatch values.
I am sure now that you are a little bit frustrated because there is much
work to do before we can implement some 802.15.4 MAC functionality...
but if you want to use a HardMAC driver then it's not much work. In few
months I will only break the interface between L2 and L3 but then I
would try to keep your driver still working.
btw: I will update the website for that 2. need to be done before we can
starting 3.
- Alex
[0] http://linux-zigbee.sourceforge.net/cgi-bin/trac.cgi/wiki/SerialV1
[1] https://github.com/linux-wpan/ieee802154-serial-protocol-version2 (draft only)
[2] https://github.com/linux-wpan/linux-wpan-next/commit/546618171de2be30236aab86f3ee323b425e2bf5
[3] https://github.com/linux-wpan/wpan-tools
[4] https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/rx.c
^ permalink raw reply [flat|nested] 2+ messages in thread