# too many packets lost (t40p with wlan)

## Pinky

Hi Folks,

finally I mananged connecting my notebook (t40p) with 2.6.3 via madwifi-driver to my router (incl. WEP).

but when i ping my router I get the following output:

```

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

64 bytes from 192.168.0.1: icmp_seq=1 ttl=127 time=1.23 ms

64 bytes from 192.168.0.1: icmp_seq=7 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=8 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=9 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=10 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=11 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=12 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=13 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=14 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=15 ttl=127 time=1.20 ms

64 bytes from 192.168.0.1: icmp_seq=16 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=17 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=18 ttl=127 time=1.20 ms

64 bytes from 192.168.0.1: icmp_seq=25 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=26 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=27 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=28 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=29 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=30 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=31 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=32 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=33 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=34 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=35 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=36 ttl=127 time=1.23 ms

64 bytes from 192.168.0.1: icmp_seq=43 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=44 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=45 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=46 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=47 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=48 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=49 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=50 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=51 ttl=127 time=1.21 ms

64 bytes from 192.168.0.1: icmp_seq=52 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=53 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=54 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=61 ttl=127 time=1.22 ms

64 bytes from 192.168.0.1: icmp_seq=62 ttl=127 time=1.21 ms

 

--- 192.168.0.1 ping statistics ---

62 packets transmitted, 39 received, 37% packet loss, time 61031ms

rtt min/avg/max/mdev = 1.205/1.219/1.236/0.044 ms

```

as you can clearly see, roughly 1/3 of the packets get lost. the strange thing is that these do not get lost randomly. there are always 6-8 packets lost in a row.

this behaviour is independent of the link quality. it doesn't matter if my laptop is half a meter away or 10 meters (more than 90% downto 40%).

under doze this problem does not occur. 

any hints to solve this?

Thanks in advance.

Pinky

----------

## ben

Hi,

If you use ACPI and you loaded processor.o you could have this problem. You could try to  unload processor and then reload it.

what gives dmesg?

Do you use the cvs version of madwifi?

Ben

----------

## Pinky

Hi Ben,

I have already read something about troubles from acpi concerning wlan. and indeed i have

acpi turned on [it's a laptop  :Smile:  ].  Nevertheless I'll give it a try.

output from dmesg

```

...

ACPI: RSDP (v002 IBM                                       ) @ 0x000f6b40

ACPI: XSDT (v001 IBM    TP-1R    0x00002110  LTP 0x00000000) @ 0x1ff6c263

ACPI: FADT (v003 IBM    TP-1R    0x00002110 IBM  0x00000001) @ 0x1ff6c300

ACPI: SSDT (v001 IBM    TP-1R    0x00002110 MSFT 0x0100000e) @ 0x1ff6c4b4

ACPI: ECDT (v001 IBM    TP-1R    0x00002110 IBM  0x00000001) @ 0x1ff77e26

ACPI: TCPA (v001 IBM    TP-1R    0x00002110 PTL  0x00000001) @ 0x1ff77e78

ACPI: BOOT (v001 IBM    TP-1R    0x00002110  LTP 0x00000001) @ 0x1ff77fd8

ACPI: DSDT (v001 IBM    TP-1R    0x00002110 MSFT 0x0100000e) @ 0x00000000

...

ACPI: Subsystem revision 20040211

ACPI: IRQ9 SCI: Edge set to Level Trigger.

ACPI: Found ECDT

AE_AML_REGION_LIMIT

ACPI: Interpreter enabled

ACPI: Using PIC for interrupt routing

ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)

ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)

ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)

ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)

ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11)

ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11)

ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11)

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)

ACPI: PCI Root Bridge [PCI0] (00:00)

....

ACPI: AC Adapter [AC] (on-line)

ACPI: Battery Slot [BAT0] (battery present)

ACPI: Battery Slot [BAT1] (battery absent)

ACPI: Power Button (FF) [PWRF]

ACPI: Lid Switch [LID]

ACPI: Sleep Button (CM) [SLPB]

ACPI: Processor [CPU] (supports C1 C2 C3, 8 throttling states)

ACPI: Thermal Zone [THM0] (58 C)

....
```

btw. I use the ebuild, it is quite new.

thx 

Pinky

----------

## ben

Hi Pinky,

First, you could have a look at my page http://www.ontheedge.ch/acpi.html

which describes my probe with acpi. Basically, if I recall correctly, the processor module (you did make it a module, right?) interfere badly with madwifi. You should see a lot of ath0 resetting: hardware errors in dmesg.

I use madwifi-cvs because of the RFMON capabilities (wardriving) that where not present in the ebuild in december-january.

I really think that the processor.o module is causing the problem, but it could also be some networking problem, so how does your routes look likes (netstat -nr) ?

HTH

Ben

P.S. I know the t40p is a laptop, I have the same wonderfull machine

http://www.ontheedge.ch/t40p.html

Arg, edit:

the processor module is almost only used to get the temperature, so even if you do want to stick with acpi (In my opinion apm is much better for the moment, for this laptop, suspend to ram works, battery life is much longer...), you can have all speedsted you want without processor.o.

Then if you rmmod processor.o, the kernel will oops, and then you can modprobe it again, and everything works alright, e.g. madwifi and temperature.

----------

## Pinky

Hi Ben,

I had acpi compiled into my kernel. but this should not be the problem. yesterday I built one without any acpi support and I have the exact same problem. 

sorry, what is wardriving?

and here my netstat -nr output

```

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 ath0

127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo

0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 ath0

```

ps: I know your page  :Wink: 

Pinky

----------

## ben

Ah ha, so, you are the *one* who read my page !

Wardriving is more or less the ability to sniff wireless data. Basically you need to put the interface in monitoring mode to be able to see the raw packet. (Actually it means driving around to find hot spot you can connect to)

Back to your problem: do you know if you get the same problem with a wired link (standart ethernet).? I had some problem with another computer of mine because of a race condition between two interrupts. Since then, I disable APIC (yes this time it is APIC, not ACPI) in the BIOS, and I make sure that I don't have smp support on uniprocessor.

HTH

Ben

----------

## Pinky

oh, forgot to mention:

the problem only occurs with wlan

eth runs smoothly.

pinky

----------

## ben

Sorry that I can't help you much more. Some idea to go further:

Try without WEP to see what happened

diff your kernel config and mine to see the difference (everything related to ACPI, SMP, net)

Good luck

Ben

BTW, it really look like there is a conflict between processor.o and madwifi. Are you sure to run the kernel without ACPI? (I know, I know, but I have to ask)

----------

## rcast

Just a note,

the hardware reset error that you get with the madwifi driver only occur when the processor is in the c3 state. Running xmms in the background does seem to stop this and stop the hardware reset error.

```

$ cat /proc/acpi/processor/CPU/power

active state:            C2

default state:           C1

bus master activity:     ffffffff

states:

    C1:                  promotion[C2] demotion[--] latency[000] usage[00000010]

   *C2:                  promotion[C3] demotion[C1] latency[001] usage[14988879]

    C3:                  promotion[--] demotion[C2] latency[085] usage[00041696]

```

When it comes to using madwifi, i found that i managed to get a lot better connection with the cvs releases, there have been a lot of changes since february, and i would recomend Pinky upgrade to the latest cvs and try that.

I don't know howto write a ebuild but you can try this:

```

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/madwifi login

<enter> 

cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/madwifi co madwifi

```

if you have the t40p with the wifi led under the display, the following will enable the led showing when you have a connection:

```
 

export COPTS=-DSOFTLED

```

then  as root

```

make 

make install 

```

this works for my t40p, hope this helps.

Rene

----------

## amoc

I think it has something to do with WEP. When I use my T40p without WEP it works just fine. Haven't found a solution tho.

I know about the issue concerning cvs and ebuilds, but I think there should be a cvs ebuild for madwifi in this case.

----------

## Pinky

@ rcast

I've tried cvs-madwifi as well (without success). the newest version, I checked out today, even worsens performance.  Sorry, but I couldn't catch your idea about xmms. Could you explain it?

```

ping xxx.xxx.xxx.xxx

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) 56(84) bytes of data.

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=127 time=1.19 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=127 time=1.20 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=127 time=1.18 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=9 ttl=127 time=1.19 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=10 ttl=127 time=1.19 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=11 ttl=127 time=1.19 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=12 ttl=127 time=1.19 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=13 ttl=127 time=1.20 ms

64 bytes from xxx.xxx.xxx.xxx: icmp_seq=14 ttl=127 time=1.19 ms

ping: sendmsg: No buffer space available

ping: sendmsg: No buffer space available

ping: sendmsg: No buffer space available

ping: sendmsg: No buffer space available

ping: sendmsg: No buffer space available

 

--- xxx.xxx.xxx.xxx ping statistics ---

19 packets transmitted, 9 received, 52% packet loss, time 37023ms

rtt min/avg/max/mdev = 1.185/1.195/1.204/0.028 ms

```

The LED option for TPs is commented in README, too. But nevertheless thx.

@ amoc

I do not believe that this strange behaviour has something to do with WEP, 'cos I disabled WEP and nothing changed.

May be I find some time to try madwifi with my Suse distro  :Wink: 

----------

## amoc

Yes, I believe it's the WEP. I have another laptop in the same WLAN that works great with another driver (different card).

When I was visiting a friend recently I accessed his WLAN without WEP and it was rock stable (I was connected for several days) using the 0.1_pre20040212 ebuild.

----------

## rcast

I have npt yet experienced any problems using WEP and madwifi, though i only used it a few days while i was at home. At unni they don't have wep enabled so i can't say much about that.

The tip that i gave about xmms is something i read on a fourum which preveneted the processor from going into the C3 powersaving mode. 

if 

```

 cat /proc/acpi/processor/CPU/power 

```

this shows the processor in C3 state (indicated by a * ) then this is likely to be a reason for your network dropping packets. And it will help to either remove  processor.o or do somethign in the background which uses a few percent of your cpu. 

Rene

----------

## Pinky

```

cat /proc/acpi/processor/CPU/power

states:

    C1:                  promotion[C2] demotion[--] latency[000] usage[00000010]

   *C2:                  promotion[C3] demotion[C1] latency[001] usage[00607275]

    C3:                  promotion[--] demotion[C2] latency[085] usage[00000635]

```

I think I'll test it with Suse, someday.

Anyway, thanks.

----------

## amoc

I'm not using ACPI (I use APM) and I'm still having the same problem with my T40p.

----------

## rcast

Sorry, can't help you much then.

Though you might want to ocnsider using driverloader(worked without a single issue)  or ndiswrapper (personally i never got this to work)

Rene

----------

## Pinky

Hi folks, I could finally solve (at least) my problem.

while windows was resistant to some router (mis)settings, linux seems to be more sensitive. I had to reduce both, my router's BASIC  and TX rate to 11Mbs. Somehow the TX rate were set to 22Mbs.

but nevertheless thx a lot for your patience and ideas. 

Pinky

----------

## ben

I just wanted to add  my voice too:

I *HAD* madwifi from cvs working very well with kernel 2.6.1 with apm (even with acpi, but without processor module loaded).

Then I upgraded to kernel 2.6.5 and now I have the same problem with acpi and with apm: ath0 is choppy under load, althoug it seems to work a bit better with acpi. Too bad acpi is not good at power consumption during a sleep (around 10 hours instead of many days under apm)

So every input would be appreciated.

Ben

----------

## ben

Well, some news about this:

As I said, it used to work with the cvs version of around january under apm and acpi provided processor was not loaded (with acpi).

Then I upgraded to kernel 2.6.5 and also to the latest cvs. Madwifi would then throw ath0: transmit timed out and resetting hardware every minutes or so, especially under load. This happened with apm and with acpi with and without processor loaded.

So I learned that:

1.- REGPARM should not be set in the kernel (conflict with proprietary modules)

2.- the madwificvs from early 2004 works ok under apm, and may be dependant of C2 under acpi

3.- the latest madwifi-cvs does reset (timed out) under both apm and acpi. This one has the nifty feature of lightening the wifi led. It was compiled with and without COPTS= -NOWME. Still the 4 queues appeared in dmesg.

Conclusion:

For me, my t40p work very well with apm, kernel 2.6.5, REGPARM not set, madwifi-cvs from early 2004 (but not the latest).

HTH

Ben

P.S. I really can't wait for the time acpi will be fully supported (meaning that the laptop can really suspend to ram (power consumption), and can properly resume (especially the usb subsystem)). In the mean time I'll stay with apm.

----------

## rab

Hello ben

How can I get madwifi-cvs "but not the latest"?

(i don't know cvs at all   :Sad:   ) 

rab

----------

## ben

hi,

Bad news I don't know either. I had a copy from that time  :Smile: 

It is something like cvs -D date. Maybe man cvs could help.

Good news. The very latest cvs is or will real soon now corrected. Atheros_greg released a hal.o which is ok. 

You may be able to find it in the archive of madwifi mailind list in case it is not already in cvs.

HTH

Ben

----------

