<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net/mac802154, branch v4.4.78</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>mac802154: llsec: use kzfree</title>
<updated>2015-10-20T22:49:24+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-10-13T11:42:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=71cd2aa53dbf9eb8cb954fc9e65de8dab774b7f6'/>
<id>71cd2aa53dbf9eb8cb954fc9e65de8dab774b7f6</id>
<content type='text'>
This patch will use kzfree instead kfree for security related
information which can be offered by acccident.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch will use kzfree instead kfree for security related
information which can be offered by acccident.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ieee802154: change mtu size behaviour</title>
<updated>2015-09-30T11:21:32+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-28T10:36:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b40988c438c2405a177ae54ff4baa08c720c296f'/>
<id>b40988c438c2405a177ae54ff4baa08c720c296f</id>
<content type='text'>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac802154: add comments for llsec issues</title>
<updated>2015-09-30T11:16:44+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-28T07:00:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d58a2fa903c18f97aac30cd3c4c8a378a2c647c4'/>
<id>d58a2fa903c18f97aac30cd3c4c8a378a2c647c4</id>
<content type='text'>
While doing a little test with the llsec implementation I saw these
issues. We should move decryption and encruption somewhere else,
otherwise while capturing with wireshark the mac header shows secuirty
fields but the payload is plaintext.

A complete other issue is what doing with HardMAC drivers where the
payload is always plaintext. I think we need a special handling then in
userspace. We currently doesn't support any HardMAC transceivers, so we
should fix the first issue for SoftMAC transceivers.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While doing a little test with the llsec implementation I saw these
issues. We should move decryption and encruption somewhere else,
otherwise while capturing with wireshark the mac header shows secuirty
fields but the payload is plaintext.

A complete other issue is what doing with HardMAC drivers where the
payload is always plaintext. I think we need a special handling then in
userspace. We currently doesn't support any HardMAC transceivers, so we
should fix the first issue for SoftMAC transceivers.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nl802154: add support for security layer</title>
<updated>2015-09-30T11:16:44+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-28T07:00:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a26c5fd7622d4951425131d54a8c99f076fe2068'/>
<id>a26c5fd7622d4951425131d54a8c99f076fe2068</id>
<content type='text'>
This patch adds support for accessing mac802154 llsec implementation
over nl802154. I added for a new Kconfig entry to provide this
functionality CONFIG_IEEE802154_NL802154_EXPERIMENTAL. This interface is
still in development. It provides to change security parameters and
add/del/dump entries of security tables. Later we can add also a get to
get an entry by unique identifier.

Cc: Phoebe Buckheister &lt;phoebe.buckheister@itwm.fraunhofer.de&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for accessing mac802154 llsec implementation
over nl802154. I added for a new Kconfig entry to provide this
functionality CONFIG_IEEE802154_NL802154_EXPERIMENTAL. This interface is
still in development. It provides to change security parameters and
add/del/dump entries of security tables. Later we can add also a get to
get an entry by unique identifier.

Cc: Phoebe Buckheister &lt;phoebe.buckheister@itwm.fraunhofer.de&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac802154: iface: assume big endian for af_packet</title>
<updated>2015-09-24T18:42:37+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-24T07:37:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c2d5ecfaeafdedfb997a466c654c7029c511f43d'/>
<id>c2d5ecfaeafdedfb997a466c654c7029c511f43d</id>
<content type='text'>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac802154: tx: add warning if MTU exceeds</title>
<updated>2015-09-22T09:51:20+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-18T09:30:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=02c7b6922899621aa8e8babe27fca7b6b2e497b0'/>
<id>02c7b6922899621aa8e8babe27fca7b6b2e497b0</id>
<content type='text'>
Sending over AF_PACKET RAW sockets we can sending frames which exceeds
MTU size. To handling it correct we need to change things in AF_PACKET
which knows on RAW sockets an additional FCS is set by hardware or
mac802154 transmit functionality.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sending over AF_PACKET RAW sockets we can sending frames which exceeds
MTU size. To handling it correct we need to change things in AF_PACKET
which knows on RAW sockets an additional FCS is set by hardware or
mac802154 transmit functionality.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ieee802154: change needed headroom/tailroom</title>
<updated>2015-09-22T09:51:20+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-18T09:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=87a93e4eceb495f93e3f37b100334d2641765b6c'/>
<id>87a93e4eceb495f93e3f37b100334d2641765b6c</id>
<content type='text'>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ieee802154: introduce wpan_dev_header_ops</title>
<updated>2015-09-22T09:51:20+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-18T09:30:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=838b83d63d2909f9136f3030dc4fffa8230c31da'/>
<id>838b83d63d2909f9136f3030dc4fffa8230c31da</id>
<content type='text'>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac802154: llsec: fix device deletion from list</title>
<updated>2015-09-22T09:51:19+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-09-18T09:30:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cdd38b219eec2e1b83c0a02d89d372f9656648eb'/>
<id>cdd38b219eec2e1b83c0a02d89d372f9656648eb</id>
<content type='text'>
This patch adds a missing list_del when a device description will be
deleted.

Cc: Phoebe Buckheister &lt;phoebe.buckheister@itwm.fraunhofer.de&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds a missing list_del when a device description will be
deleted.

Cc: Phoebe Buckheister &lt;phoebe.buckheister@itwm.fraunhofer.de&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ieee802154: add ack request default handling</title>
<updated>2015-08-10T18:43:06+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2015-08-10T19:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c91208d819c814e7f418c7a083059cf533ad0396'/>
<id>c91208d819c814e7f418c7a083059cf533ad0396</id>
<content type='text'>
This patch introduce a new mib entry which isn't part of 802.15.4 but
useful as default behaviour to set the ack request bit or not if we
don't know if the ack request bit should set. This is currently used for
stacks like IEEE 802.15.4 6LoWPAN.

Reviewed-by: Stefan Schmidt &lt;stefan@osg.samsung.com&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch introduce a new mib entry which isn't part of 802.15.4 but
useful as default behaviour to set the ack request bit or not if we
don't know if the ack request bit should set. This is currently used for
stacks like IEEE 802.15.4 6LoWPAN.

Reviewed-by: Stefan Schmidt &lt;stefan@osg.samsung.com&gt;
Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
