Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring <alex.aring@gmail.com>]

On Tue, May 12, 2015 at 11:48:36AM +0200, Matteo Petracca wrote:
> You were right, I did not remove the Assertion.
> 
> Now the patch is all there and the modules are
> updated.
> 
> What happens now is a strange behaviour, booting
> the system I just turn on the wpan interface putting
> as panid 0xaaaa:
> 
> ifconfig wpan0 up
> 
> the device starts to read from the network, and this is
> what I have in output with dmesg is:
> 
> [  131.445285] ieee802154: bad frame received (type = 3)
> [  133.777933] ieee802154: bad frame received (type = 3)
> [  136.110635] ieee802154: bad frame received (type = 3)
> [  148.318471] ieee802154: bad frame received (type = 3)
> [  150.651288] ieee802154: bad frame received (type = 3)
> [  152.984910] ieee802154: bad frame received (type = 3)
> [  165.195277] ieee802154: bad frame received (type = 3)
> [  167.527936] ieee802154: bad frame received (type = 3)
> [  169.860422] ieee802154: bad frame received (type = 3)
> [  182.071635] ieee802154: bad frame received (type = 3)
> [  184.406857] ieee802154: bad frame received (type = 3)
> [  186.739487] ieee802154: bad frame received (type = 3)
> [  198.947054] ieee802154: bad frame received (type = 3)
> [  201.279710] ieee802154: bad frame received (type = 3)
> [  203.612262] ieee802154: bad frame received (type = 3)
> [  215.819843] ieee802154: bad frame received (type = 3)
> [  218.155852] ieee802154: bad frame received (type = 3)
> [  220.488465] ieee802154: bad frame received (type = 3)
> 
> Moreover SIOCGIFADDR still does not work.
> 

This is a behaviour because we have lack of support to parse mac_cmd
frames [0]. And I see now I already told you that! [1]

The current parsing mechanism is very dataframes specfic there is an 
draft for reworking this frame parsing style and do it like mac80211
(which have a lot of more frametypes than 802.15.4). See [2]:
"new frame parsing style in mac802154 and ieee802154 based on mac80211
frame parsing design. Draft is mac802154 rx and 6LoWPAN. Crypto need to
be done at first, otherwise I can’t test it."

Nevertheless it needs time to supporting it, you could simple add a case
that the frame is delivered to userspace, but then this frame could not
valid 802.15.4 frametype and you need to check that again in userspace.

I also noticed that the raw socket don't put the mac header into payload
(which should it do), see [3] (that's something which already told you).

and yes, the 802.15.4 sockets needs a complete rework/cleanup. This is
an opentask section at [4], we should orient us at bluetooth socket
code.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/rx.c#n104
[1] http://www.spinics.net/lists/linux-wpan/msg01623.html
[2] http://wpan.cakelab.org/
[3] http://www.spinics.net/lists/linux-wpan/msg01623.html
[4] http://wpan.cakelab.org/