Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1694 (new defect)

Opened 14 years ago

Last modified 14 years ago

Kernel panic when trying to use madwifi with the IFB

Reported by: Tomasz Rostanski <rozteck@interia.pl> Assigned to:
Priority: minor Milestone:
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc:
Patch is attached: 1 Pending:

Description

There is a problem when trying to use madwifi with ifb interface. After creating some tc class and filters, like:

ifconfig ifb0 up
tc qdisc add dev ath0 ingress
tc filter add dev ath0 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1:0 htb default 2
tc class add dev ifb0 parent 1:0 classid 1:1 htb rate 1500kbps
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 100kbps ceil 1000kbps prio 0
tc class add dev ifb0 parent 1:1 classid 1:20 htb rate 100kbps ceil 1000kbps prio 0
tc filter add dev ifb0 parent 1:0 protocol ip preference 1 handle 1 fw classid 1:10

the kernel crashes just after the madwifi receive the incoming packet. The crash occurs because the kernel function tcf_mirred (from net/sched/act_mirred.c) calls the:

skb_push(skb2, skb2->dev->hard_header_len);

which does:

skb->data -= skb2->dev->hard_header_len;
skb->len += skb2->dev->hard_header_len;
if (inlikely(skb->data < skb->head))
    skb_under_panic(skb, len, current_text_addr());

The problem here is that the madwifi sets the skb2->dev->hard_header_len to the maximum header it can use in ath_attach function. The solution is to set the dev->hard_header_len to the proper size each time the packet is being received (or do it in some better way). The attached patch does this and solves the problem (at least for me). If there is a better solution please correct me.

Attachments

madwifi_ifb_fix.diff (0.5 kB) - added by rozteck@interia.pl on 12/11/07 14:00:11.
The patch solving the kernel panic when using ifb with madwifi. Signed-off-by: Tomasz Rostanski <rozteck@interia.pl>

Change History

12/11/07 14:00:11 changed by rozteck@interia.pl

  • attachment madwifi_ifb_fix.diff added.

The patch solving the kernel panic when using ifb with madwifi. Signed-off-by: Tomasz Rostanski <rozteck@interia.pl>

12/18/07 23:24:12 changed by maly(at)warpie.net

After patching mad-wifi there are no kernel panics but tcpdump shows garbage on ifb device. I think that this is the reason why my tc filters didn't work. So, patch don't resolve the problem.

12/21/07 14:20:21 changed by rozteck

hmm, we've been checking the transmission on the station side (the ifb was on ap side) and the tcpdump is displaying the correct packets. also the transmitted files are equal. could you just simply transfer some text file when using ifb and tc filters and check the contents on the station side?

12/24/07 14:00:41 changed by maly(at)warpie.net

router scripts # tcpdump -i ifb0 -n -X -s 1500 tcpdump: WARNING: ifb0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ifb0, link-type EN10MB (Ethernet), capture size 1500 bytes 13:56:27.762724 85:32:00:0e:8e:02 > 85:2c:00:0e:8e:02, ethertype Unknown (0x852c), length 112:

0x0000: 000e 8e02 852c 000e 8e02 8532 0800 4500 .....,.....2..E. 0x0010: 0054 0000 4000 4001 3f4d c0a8 0201 d44d .T..@.@.?M.....M 0x0020: 6465 0800 1cfb ea09 0001 79ac 6f47 1703 de........y.oG.. 0x0030: 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 ................ 0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$% 0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345 0x0060: 3637 67

This is a icmp echo request. Please, email me - this will be mode "interactive" :). (i po polsku)

12/24/07 14:01:52 changed by anonymous

I forgot to "code":

router scripts # tcpdump -i ifb0 -n -X -s 1500
tcpdump: WARNING: ifb0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ifb0, link-type EN10MB (Ethernet), capture size 1500 bytes
13:56:27.762724 85:32:00:0e:8e:02 > 85:2c:00:0e:8e:02, ethertype Unknown (0x852c), length 112: 
        0x0000:  000e 8e02 852c 000e 8e02 8532 0800 4500  .....,.....2..E.
        0x0010:  0054 0000 4000 4001 3f4d c0a8 0201 d44d  .T..@.@.?M.....M
        0x0020:  6465 0800 1cfb ea09 0001 79ac 6f47 1703  de........y.oG..
        0x0030:  0600 0809 0a0b 0c0d 0e0f 1011 1213 1415  ................
        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425  ...........!"#$%
        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435  &'()*+,-./012345
        0x0060:  3637                                     67

(follow-up: ↓ 6 ) 12/24/07 14:07:44 changed by mentor

Also, I'm slightly dubious about updating hard_headerlen on the device for each packet. Surely queuing will mess with this?

(in reply to: ↑ 5 ) 12/27/07 13:52:08 changed by rozteck

Replying to mentor:

Also, I'm slightly dubious about updating hard_headerlen on the device for each packet. Surely queuing will mess with this?

You're right - this is not a good solution. Probably better would be updating the hard_headerlen only when the value has changed - something like:

if (hdrspace != last_hdrspace) {
    dev->hard_header_len = last_hdrspace = hdrspace;
}

I will sit a bit on the IFB when I will have some time, however the guys who made tests for me says that the patch works and the transmitted files are equal to the source ones.