On Mon, 2007-11-26 at 16:14 +0200, Ron Rindjunsky wrote:
> This patch adds the ability to receive and handle A-MSDU frames.
>
> Signed-off-by: Ron Rindjunsky <ron.rindjunsky@xxxxxxxxx>
Acked-by: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
Thanks for your patience on this. I have another question that is
identical in the other code and that we should, if necessary, fix in a
separate patch to fix both instances of this:
> + payload = frame->data;
> + ethertype = (payload[6] << 8) | payload[7];
> +
> + if (likely((compare_ether_addr(payload, rfc1042_header) == 0 &&
[...]
> + } else {
> + memcpy(skb_push(frame, sizeof(__be16)), &len,
> + sizeof(__be16));
> + memcpy(skb_push(frame, ETH_ALEN), src, ETH_ALEN);
> + memcpy(skb_push(frame, ETH_ALEN), dst, ETH_ALEN);
Here, as well as in the regular data frame handler, we push the length
of the frame into the ethernet header. Later then, eth_type_trans() will
load up the skb->protocol field. The thing I'm not entirely sure about
is this: We can have frames longer than 1536 bytes, but only if the
length is smaller than 1536 does eth_type_trans() assume that it's a
length, if we have a frame longer won't it go wrong? I haven't quite
managed to wrap my head around the rules for wrapping data into an
802.11 frame nor in an 802.3 setting so this may be totally incorrect.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
