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/ -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
