kernel.git/net/mac802154/iface.c, branch linux-4.7.y

ieee802154: change mtu size behaviour

2015-09-30T11:21:32Z

This patch changes the mtu size of 802.15.4 interfaces. The current setting is the meaning of the maximum transport unit with mac header, which is 127 bytes according 802.15.4. The linux meaning of the mtu size field is the maximum payload of a mac frame. Like in ethernet, which is 1500 bytes. We have dynamic length of mac frames in 802.15.4, this is why we assume the minimum header length which is hard_header_len. This contains fc and sequence fields. These can evaluated by driver layer without additional checks. We currently don't support to set the FCS from userspace, so we need to subtract this from mtu size as well. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: iface: assume big endian for af_packet

2015-09-24T18:42:37Z

The callback "create" and "parse" from header_ops are called from netdev core upper-layer functionality, like af_packet. These callbacks assumes big endian for addresses and we should not introduce a special byteordering handling for ieee802154 over af_packet in userspace. We have an identical issue with setting the mac address which also assumes big endian byteordering. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

ieee802154: change needed headroom/tailroom

2015-09-22T09:51:20Z

This patch cleanups needed_headroom, needed_tailroom and hard_header_len fields for wpan and lowpan interfaces. For wpan interfaces the worst case mac header len should be part of needed_headroom, currently this is set as hard_header_len, but hard_header_len should be set to the minimum header length which xmit call assumes and this is the minimum frame length of 802.15.4. The hard_header_len value will check inside send callbacl of AF_PACKET raw sockets. For lowpan interfaces, if fragmentation isn't needed the skb will call dev_hard_header for 802154 layer and queue it afterwards. This happens without new skb allocation, so we need the same headroom and tailroom lengths like 802154 inside 802154 6lowpan layer. At least we assume as minimum header length an ipv6 header size. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

ieee802154: introduce wpan_dev_header_ops

2015-09-22T09:51:20Z

The current header_ops callback structure of net device are used mostly from 802.15.4 upper-layers. Because this callback structure is a very generic one, which is also used by e.g. DGRAM AF_PACKET sockets, we can't make this callback structure 802.15.4 specific which is currently is. I saw the smallest "constraint" for calling this callback with dev_hard_header/dev_parse_header by AF_PACKET which assign a 8 byte array for address void pointers. Currently 802.15.4 specific protocols like af802154 and 6LoWPAN will assign the "struct ieee802154_addr" as these parameters which is greater than 8 bytes. The current callback implementation for header_ops.create assumes always a complete "struct ieee802154_addr" which AF_PACKET can't never handled and is greater than 8 bytes. For that reason we introduce now a "generic" create/parse header_ops callback which allows handling with intra-pan extended addresses only. This allows a small use-case with AF_PACKET to send "somehow" a valid dataframe over DGRAM. To keeping the current dev_hard_header behaviour we introduce a similar callback structure "wpan_dev_header_ops" which contains 802.15.4 specific upper-layer header creation functionality, which can be called by wpan_dev_hard_header. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: change frame_retries behaviour

2015-08-10T18:43:06Z

This patch changes the default minimum value of frame_retries to 0 and changes the frame_retries default value to 3 which is also 802.15.4 default. We don't use the frame_retries "-1" value as indicator for no-aret mode anymore, instead we checking on the ack request bit inside the 802.15.4 frame control field. This allows a acknowledge handling per frame. This checking is done by transceiver or inside xmit callback of driver layer. If a transceiver doesn't support ARET handling the transmit functionality ignores ack frames then, which isn't well but should not effect anything of current functionality. Reviewed-by: Stefan Schmidt Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: fix wpan mac setting while lowpan is there

2015-08-10T18:43:06Z

If we currently change the mac address inside the wpan interface while we have a lowpan interface on top of the wpan interface, the mac address setting doesn't reach the lowpan interface. The effect would be that the IPv6 lowpan interface has the old SLAAC address and isn't working anymore because the lowpan interface use in internal mechanism sometimes dev->addr which is the old mac address of the wpan interface. This patch checks if a wpan interface belongs to lowpan interface, if yes then we need to check if the lowpan interface is down and change the mac address also at the lowpan interface. When the lowpan interface will be set up afterwards, it will use the correct SLAAC address which based on the updated mac address setting. Reviewed-by: Stefan Schmidt Tested-by: Stefan Schmidt Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: util: add stop_device utility function

2015-07-23T15:10:49Z

This patch adds ieee802154_stop_device for preparing a utility function to stop the ieee802154 device. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: add llsec address update workaround

2015-07-23T15:10:48Z

This patch adds a workaround for using the new nl802154 netlink interface with the old ieee802154 netlink interface togehter. The nl802154 currently supports no access for llsec layer, currently there are users outside which are using both interfaces at the same time. This patch adds a necessary call when addresses are updated. Reported-by: Simon Vincent Suggested-by: Phoebe Buckheister Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: iface: cleanup stack variable

2015-06-17T14:00:40Z

There is no need to init res with zero, res can be unused but then we returning zero and not res. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann

mac802154: iface: fix order while interface up

2015-06-17T14:00:40Z

This patch moves the hardware setting before calling the driver start callback which activates the receive handling. The hardware setup contains settings like address filtering which should be setup before activate the receive handling on the transceiver. These setting are protected by ieee802154_check_concurrent_iface check. This means we need to set these registers once before calling drv_start and can't be overwritten by other interfaces. Signed-off-by: Alexander Aring Signed-off-by: Marcel Holtmann