Panic with WEP, fragmented frames and ap_bridge_packets=1

[Martin Whitlock]

It seems as an old ghost has occured again. In April I reported a bug 
where a kernel panic occured when using WEP and transmitting fragmented 
data frames. That bug was solved (see below) but it seems as the same 
problem still exists when fragmented, encrypted data frames are sent 
between two ascociated clients with ap_bridge_packets=1. The problem is 
reproducable:

* 0.1.2 release
* Two clients
* ap_bridge_packets=1
* WEP enabled
* Ping between clients with packetsize>frag threshold (of any client)

/Martin


Jouni Malinen wrote:

>On Fri, Apr 25, 2003 at 02:43:53PM -0400, Martin Whitlock wrote:
>
>  
>
>>I have experienced the same problem, but in an ARM environment with 
>>0.0.1 release and 2.4.[18|19] kernel. I have made some debugging and it 
>>turns out that there is a problem with hostbased wep decryption together 
>>with fragmented frames. When I use a Lucent Orinoco client in windows it 
>>seems as the defualt fragmentation size is 500 bytes, which means that a 
>>lot of packets will be fragmented. I beleive that it is when the last 
>>fragmented frame is decrypted, the resulting buffer size is false.
>>    
>>
>
>Thanks! That made it easy to debug.
>
>The crash was indeed caused by skb->dev being NULL as Justin pointed
>out. This happened when defragmentation code finished assembling the
>frame (i.e., when processing the last fragment). However, this was not
>the only issue in host-based decryption with defragmentation.. I don't
>remember when I might have broken them, but I do remember having seen
>them working before ;-).
>
>Last eight encrypted octets of the first frame were included in the
>defragmented frame which of course meant that the payload was incorrect.
>I cleaned up the defragmentation code a bit and fixed this.
>
>Both host_decrypt+defrag fixes are now in CVS.
>  
>