Hey!
I am having a severe problem with the devices mentioned in the subject.
I can establish a connection to the access point just fine, but data
traffic is veeerrryyy (unusable!) slow. However, according to ping, no
packet loss seems to occur.
Also there is no big latency between the packets. It just takes ages
for the next one to be sent. Obviously, the same applies to browsing
etc.
I am pretty sure it is a driver problem. Here's why I think so:
- With my Android handset I can not reproduce this problem
- On Windows, this problem does not occur, either (one (relevant?)
thing: the AP reports an active STBC mode with the Windows driver, on
Linux it doesn't)
I have tried several things:
- Pretty much any IEEE 802.11 mode / Disabling the N-mode
- Disabling the encryption
- Establishing a connection on the 5Ghz band
I was previously using Linux 3.0.4. I'm now using
3.1.0-rc7-next-20110926 (linux-next mirror from sfrothwell,
https://github.com/sfrothwell/linux-next).
I have contacted AVM about this, and they have experienced issues with
Intel Centrino chips before, but they believe it's a driver issue.
Other accesspoints always seemed to have worked fine.
I have attached a dmesg. The card is in a Lenovo Thinkpad x220i.
QVZNIEZyaXR6IUJveCBGb24gV0xBTiA3MzkwDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IGxpbnV4LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxp
bnV4LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIFZlbmthdGFy
YW1hbiwgTWVlbmFrc2hpDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNiwgMjAxMSAyOjA3IFBN
DQpUbzogSGVucmlrIEZyaWVkcmljaHNlbg0KQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVs
Lm9yZw0KU3ViamVjdDogUkU6IGl3bGFnbjogIkludGVsIENlbnRyaW5vIEFkdmFuY2VkLU4gNjIw
NSBBR04iIGFuZCAiQVZNIEZyaXR6IUJveCAoNzM5MCkiIGluY29tcGF0aWJsZQ0KDQpIaSBIZW5y
aWssDQoNCj5UaGF0J3MgY29ycmVjdC4gT24gV2luZG93cyB0aGUgcHJvYmxlbSBkb2VzIG5vdCBv
Y2N1ciB3aXRoIHRoYXQgcGFydGljdWxhcg0KPnJvdXRlci4gQWxzbyBJIGRvbid0IHRoaW5rIEkg
aGF2ZSBoYWQgY29tcGFyYWJsZSBwcm9ibGVtcyB3aXRoIG90aGVyIHJvdXRlcnMsDQo+YXQgbGVh
c3Qgbm90IGluIG15IGhvbWUgKG5vdCBvbiBMaW51eCwgZWl0aGVyKS4NCj5JJ20gdXNpbmcgYSBk
aWZmZXJlbnQgQVAgcmlnaHQgbm93IGFuZCBpdCB3b3JrcyBqdXN0IGZpbmUuDQoNCltNVl0gVGhh
dCdzIGludGVyZXN0aW5nLiBXaGF0IGlzIHRoZSBtb2RlbCBvZiB0aGUgQVAgdGhhdCB3b3Jrcz8g
QXJlIHlvdSB1c2luZyB0aGUgc2FtZSBrZXJuZWwgdmVyc2lvbiB3aXRoIHRoaXMgQVAgKGp1c3Qg
d2FudCB0byBjb25maXJtIHdpdGggeW91KT8gQWxzbywgYXJlIHlvdSBpbiBhIHBvc2l0aW9uIHRv
IHNlbmQgdXMgKG9ubHkpIGEgc25pZmZlciBsb2c/IA0KDQpUaGFua3MsDQpNZWVuYWtzaGkNCg0K
BO+/vXsubu+/vSvvv73vv73vv73vv73vv73vv73vv70rJe+/ve+/vWx6d23vv73vv71i77+966ey
77+977+9cu+/ve+/vXpY77+977+9HCLvv73vv71e77+9yKfvv70X77+977+93Kh977+977+977+9
xqB677+9Jmo6K3bvv73vv73vv70N77+977+977+977+9elor77+977+9K3pm77+977+977+9aO+/
ve+/ve+/vX7vv73vv73vv73vv71p77+977+977+9eu+/vR7vv71377+977+977+9P++/ve+/ve+/
ve+/vSbvv70p36IbZg0K
Meenakshi,
On Mon, 2011-09-26 at 14:02 -0700, Henrik Friedrichsen wrote:
> Hey Meenakshi,
>
> On Mon, Sep 26, 2011 at 10:59 PM, Venkataraman, Meenakshi
> <[email protected]> wrote:
> > [MV] You're running Windows using the same card (6205), right? Also, have you ever seen good performance with your 6205 on your Linux system? What about with a different AP?
>
> That's correct. On Windows the problem does not occur with that
> particular router. Also I don't think I have had comparable problems
> with other routers, at least not in my home (not on Linux, either).
> I'm using a different AP right now and it works just fine.
yes, we know this could be AP related, Larry also seeing some issues
against this AP, but I still like to understand and root cause the issue
and find a solution or W/A for it.
Henrik. what kind of traffic you are running? what I see from the log,
there are not many aggregated frames, (what I mean is I do not see a lot
of BA in the log) which is very different from what I am test here. also
I see the retry ratio is high in the aggregated frame compare to what I
have here.
Wey
On 09/26/2011 10:20 AM, Henrik Friedrichsen wrote:
>> 1. AP brand and model
> AVM Fritz!Box Fon WLAN 7390
FWIW, we are working on a problem with using rtl8192cu and a Fritz!Box 7270 that
doesn't seem to happen with any other AP. Our symptoms are different, but therre
might be a related cause. If you find a fix, please let the list know. Our
debugging is waiting for either Realtek to get access to such an AP, or for the
OP to provide a Wireshark air dump. That AP is too pricey for my budget.
Larry
Hey!
On Mon, Sep 26, 2011 at 11:06 PM, Venkataraman, Meenakshi
<[email protected]> wrote:
> [MV] That's interesting. What is the model of the AP that works? Are you using the same kernel version with this AP (just want to confirm with you)? Also, are you in a position to send us (only) a sniffer log?
Well, I can't really tell you which router models worked fine, because
I almost never had physical access to them (or bothered, for that
matter ;)). The Netgear WGR614v10, which I used to have at home,
worked without problems. Same with a few TP-Link routers. Turning my
HTC Desire HD (Android) handset to a WiFi hotspot worked fine, too. So
this one is pretty much the first one that I am encountering.
Unfortunately I don't have any other Fritz!Boxes by AVM at the moment.
The one I am connected to right now is a ZyXEL ISP rebrand. I don't
have physical access to it, so I can't really tell you what model it
is.
What kind of a sniffer log. You mean TCP packets?
SGkgSGVucmlrLA0KDQo+PiBbTVZdIFRoYXQncyBpbnRlcmVzdGluZy4gV2hhdCBpcyB0aGUgbW9k
ZWwgb2YgdGhlIEFQIHRoYXQgd29ya3M/IEFyZSB5b3UNCj51c2luZyB0aGUgc2FtZSBrZXJuZWwg
dmVyc2lvbiB3aXRoIHRoaXMgQVAgKGp1c3Qgd2FudCB0byBjb25maXJtIHdpdGggeW91KT8NCj5B
bHNvLCBhcmUgeW91IGluIGEgcG9zaXRpb24gdG8gc2VuZCB1cyAob25seSkgYSBzbmlmZmVyIGxv
Zz8NCj4NCj5XZWxsLCBJIGNhbid0IHJlYWxseSB0ZWxsIHlvdSB3aGljaCByb3V0ZXIgbW9kZWxz
IHdvcmtlZCBmaW5lLCBiZWNhdXNlIEkgYWxtb3N0DQo+bmV2ZXIgaGFkIHBoeXNpY2FsIGFjY2Vz
cyB0byB0aGVtIChvciBib3RoZXJlZCwgZm9yIHRoYXQgbWF0dGVyIDspKS4gVGhlDQo+TmV0Z2Vh
ciBXR1I2MTR2MTAsIHdoaWNoIEkgdXNlZCB0byBoYXZlIGF0IGhvbWUsIHdvcmtlZCB3aXRob3V0
DQo+cHJvYmxlbXMuIFNhbWUgd2l0aCBhIGZldyBUUC1MaW5rIHJvdXRlcnMuIFR1cm5pbmcgbXkg
SFRDIERlc2lyZSBIRA0KPihBbmRyb2lkKSBoYW5kc2V0IHRvIGEgV2lGaSBob3RzcG90IHdvcmtl
ZCBmaW5lLCB0b28uIFNvIHRoaXMgb25lIGlzIHByZXR0eQ0KPm11Y2ggdGhlIGZpcnN0IG9uZSB0
aGF0IEkgYW0gZW5jb3VudGVyaW5nLg0KPlVuZm9ydHVuYXRlbHkgSSBkb24ndCBoYXZlIGFueSBv
dGhlciBGcml0eiFCb3hlcyBieSBBVk0gYXQgdGhlIG1vbWVudC4NCj5UaGUgb25lIEkgYW0gY29u
bmVjdGVkIHRvIHJpZ2h0IG5vdyBpcyBhIFp5WEVMIElTUCByZWJyYW5kLiBJIGRvbid0IGhhdmUN
Cj5waHlzaWNhbCBhY2Nlc3MgdG8gaXQsIHNvIEkgY2FuJ3QgcmVhbGx5IHRlbGwgeW91IHdoYXQg
bW9kZWwgaXQgaXMuDQoNCltNVl0gQWxscmlnaHQuLi50aGF0J3MgaGVscGZ1bC4gTm90IHN1cmUg
aG93IGF0IHRoZSBtb21lbnQsIGJ1dCB3ZSBjYW4gZmlndXJlIHRoYXQgb3V0Lg0KDQo+V2hhdCBr
aW5kIG9mIGEgc25pZmZlciBsb2cuIFlvdSBtZWFuIFRDUCBwYWNrZXRzPw0KDQpbTVZdIFdlbGwu
Li53aGF0IEknbSBpbnRlcmVzdGVkIGluIGlzIHJlYWxseSB0aGUgSUVFRTgwMi4xMSBwYWNrZXRz
IGZvciB3aGVuIHlvdSBhdHRlbXB0IHRvIGJyb3dzZSB0aGUgd2ViIChvciBvdGhlciB3b3JrbG9h
ZHMpIHdoZXJlIHlvdSdyZSBzZWVpbmcgdGhlIGlzc3VlLiBPZiBjb3Vyc2UsIFRDUCB0cmFmZmlj
IHRoYXQgdGhlc2UgcGFja2V0cyBhcmUgY2Fycnlpbmcgd2lsbCBhbHNvIGJlIGhlbHBmdWwuDQoN
ClRoYW5rcywNCk1lZW5ha3NoaQ0K
On 09/26/2011 04:31 PM, Henrik Friedrichsen wrote:
> On Mon, Sep 26, 2011 at 11:17 PM, wwguy<[email protected]> wrote:
>> how about just doing a flood ping to your AP
>> #sudo ping -f<AP's ip address>
>
> Okay, here's what's happening:
> ~> ping -f fritz.box
> PING fritz.box (192.168.178.1) 56(84) bytes of data.
> ping: cannot flood; minimal interval, allowed for user, is 200ms
>
> When I send regular pings:
> ~> ping -c5 fritz.box
> PING fritz.box (192.168.178.1) 56(84) bytes of data.
> 64 bytes from fritz.box (192.168.178.1): icmp_req=1 ttl=64 time=1.31 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=2 ttl=64 time=1.26 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=3 ttl=64 time=1.30 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=4 ttl=64 time=2.51 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=5 ttl=64 time=1.22 ms
>
> --- fritz.box ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 32046ms
> rtt min/avg/max/mdev = 1.226/1.524/2.515/0.496 ms
>
> As you can see, the packets get there and the response goes back to
> me. But it seems to take ages for the package to be sent. I've sent
> five pings and got my response back in regular latency, however the
> whole process took 32 seconds.
Of course, it should take a little over 4 sec. Try adding the -D switch to the
ping command. Does repeating the ping command immediately change the timing?
Larry
On Mon, Sep 26, 2011 at 11:24 PM, Venkataraman, Meenakshi
<[email protected]> wrote:
> [MV] Well...what I'm interested in is really the IEEE802.11 packets for when you attempt to browse the web (or other workloads) where you're seeing the issue. Of course, TCP traffic that these packets are carrying will also be helpful.
I see. You're going to have to excuse me here, though. I have never
done WiFi debugging. What would be the easiest (and for you most
useful) way to capture IEEE802.11 packets?
On Mon, Sep 26, 2011 at 11:17 PM, wwguy <[email protected]> wrote:
> how about just doing a flood ping to your AP
> #sudo ping -f <AP's ip address>
Okay, here's what's happening:
~ > ping -f fritz.box
PING fritz.box (192.168.178.1) 56(84) bytes of data.
ping: cannot flood; minimal interval, allowed for user, is 200ms
When I send regular pings:
~ > ping -c5 fritz.box
PING fritz.box (192.168.178.1) 56(84) bytes of data.
64 bytes from fritz.box (192.168.178.1): icmp_req=1 ttl=64 time=1.31 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=2 ttl=64 time=1.26 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=3 ttl=64 time=1.30 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=4 ttl=64 time=2.51 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=5 ttl=64 time=1.22 ms
--- fritz.box ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 32046ms
rtt min/avg/max/mdev = 1.226/1.524/2.515/0.496 ms
As you can see, the packets get there and the response goes back to
me. But it seems to take ages for the package to be sent. I've sent
five pings and got my response back in regular latency, however the
whole process took 32 seconds.
Hi Henrik,
On Mon, 2011-09-26 at 07:07 -0700, Henrik Friedrichsen wrote:
> One more thing I have noticed:
>
> This message is only being printed when I connect to the AP, that I
> have problems with:
>
> Sep 26 07:05:03 dharma kernel: [ 2213.379252] iwlagn 0000:03:00.0: Tx
> aggregation enabled on ra = xx:xx:xx:xx:xx:xx tid = 0
>
this message telling us "11n/aggregation" is started; so looks like the
problem is aggregation related.
> On the APs that work fine, it DOES NOT get printed.
I don't see anything special in the dmesg log you send, could you
provide us more information?
1. AP brand and model
2. channel band and number
3. firmware version
4. system setup (bluetooth or any other wireless devices on the system?)
5. if you can provide us more detail log, it will be great. (loading the
iwlagn with debug=0x43fff)
Thanks
Wey
> T
SGVucmlrLA0KDQo+PiBPZiBjb3Vyc2UsIGl0IHNob3VsZCB0YWtlIGEgbGl0dGxlIG92ZXIgNCBz
ZWMuIFRyeSBhZGRpbmcgdGhlIC1EDQo+PiBzd2l0Y2ggdG8gdGhlIHBpbmcgY29tbWFuZC4gRG9l
cyByZXBlYXRpbmcgdGhlIHBpbmcgY29tbWFuZA0KPj4gaW1tZWRpYXRlbHkgY2hhbmdlIHRoZSB0
aW1pbmc/DQo+DQo+VGhlcmUgeW91IGdvOg0KPn4gPiBwaW5nIC1EYzUgZnJpdHouYm94DQo+UElO
RyBmcml0ei5ib3ggKDE5Mi4xNjguMTc4LjEpIDU2KDg0KSBieXRlcyBvZiBkYXRhLg0KPlsxMzE3
MDc0Nzk2LjE0MDQ2OF0gNjQgYnl0ZXMgZnJvbSBmcml0ei5ib3ggKDE5Mi4xNjguMTc4LjEpOg0K
PmljbXBfcmVxPTEgdHRsPTY0IHRpbWU9MS4xOSBtcw0KPlsxMzE3MDc0ODA0LjE1NDQyNV0gNjQg
Ynl0ZXMgZnJvbSBmcml0ei5ib3ggKDE5Mi4xNjguMTc4LjEpOg0KPmljbXBfcmVxPTIgdHRsPTY0
IHRpbWU9MS41MiBtcw0KPlsxMzE3MDc0ODEyLjE2NTk0N10gNjQgYnl0ZXMgZnJvbSBmcml0ei5i
b3ggKDE5Mi4xNjguMTc4LjEpOg0KPmljbXBfcmVxPTMgdHRsPTY0IHRpbWU9MS4yMCBtcw0KPlsx
MzE3MDc0ODIwLjE3NzI1Ml0gNjQgYnl0ZXMgZnJvbSBmcml0ei5ib3ggKDE5Mi4xNjguMTc4LjEp
Og0KPmljbXBfcmVxPTQgdHRsPTY0IHRpbWU9MS4yMyBtcw0KPlsxMzE3MDc0ODI4LjE4NzQ3MF0g
NjQgYnl0ZXMgZnJvbSBmcml0ei5ib3ggKDE5Mi4xNjguMTc4LjEpOg0KPmljbXBfcmVxPTUgdHRs
PTY0IHRpbWU9MS43NiBtcw0KPg0KPk5vcGUsIGl0IGRvZXNuJ3QuDQoNCltNVl0gWW91J3ZlIHBy
b2JhYmx5IGFscmVhZHkgZG9uZSB0aGlzLCBidXQgd2hhdCBhYm91dCBpZiB5b3UgY29ubmVjdGVk
IHRvIHRoZSBBUCB2aWEgYW4gRXRoZXJuZXQgY2FibGUsIGFuZCB0aGVuIHRyaWVkIHRoZSBwaW5n
Pw0KDQpNZWVuYWtzaGkNCg==
Hey Wey,
Sure! Here's the information you asked for:
On Mon, Sep 26, 2011 at 4:54 PM, wwguy <[email protected]> wrote:
> Hi Henrik,
>
> On Mon, 2011-09-26 at 07:07 -0700, Henrik Friedrichsen wrote:
>> One more thing I have noticed:
>>
>> This message is only being printed when I connect to the AP, that I
>> have problems with:
>>
>> Sep 26 07:05:03 dharma kernel: [ 2213.379252] iwlagn 0000:03:00.0: Tx
>> aggregation enabled on ra = xx:xx:xx:xx:xx:xx tid = 0
>>
> this message telling us "11n/aggregation" is started; so looks like the
> problem is aggregation related.
I see. Well only after that has been printed, I can surf the internet.
It takes a few seconds for that message to appear (after DHCP info
retrieval).
>
>> On the APs that work fine, it DOES NOT get printed.
>
> I don't see anything special in the dmesg log you send, could you
> provide us more information?
>
> 1. AP brand and model
AVM Fritz!Box Fon WLAN 7390
> 2. channel band and number
It happens in the 2,4GHz and 5GHz frequencies, no matter what channel I use.
> 3. firmware version
17.168.5.3 build 42301
> 4. system setup (bluetooth or any other wireless devices on the system?)
It's a Lenovo x220i laptop. It does have a Bluetooth chip, which is,
however, deactived. Other than that there are no other wireless
devices.
> 5. if you can provide us more detail log, it will be great. (loading the
> iwlagn with debug=0x43fff)
Here's a more detailed log connecting to that AP in the 5GHz range:
http://diff.cc/tmp/kernel_iwlagn.log
>
>
> Thanks
> Wey
>> T
>
>
If you need anything else, let me know.
Thanks
Henrik
Henrik,
On Mon, 2011-09-26 at 16:03 -0700, Henrik Friedrichsen wrote:
> Okay. As it turns out, the problem was distribution related (combined
> with a few config changes I made when I was in China) and NOT
> hardware. I'd rather not go into it, because it's almost too
> embarrassing to admit. Either way, I would like to thank everyone of
> you for the time and effort and apologize for the trouble. For me, it
> is quite a relief, but I can understand if it pisses you off (wasted
> time, etc.). Sorry guys!
>
> Anyway, here's a free drink/tea/coffee coupon for compensation.. =X
No problem, enjoy doing it with you, you are quick in response and very
helpful :-)
Wey
On Mon, 2011-09-26 at 14:21 -0700, Henrik Friedrichsen wrote:
> Hello Wey,
>
> On Mon, Sep 26, 2011 at 11:11 PM, wwguy <[email protected]> wrote:
> > Henrik. what kind of traffic you are running? what I see from the log,
> > there are not many aggregated frames, (what I mean is I do not see a lot
> > of BA in the log) which is very different from what I am test here. also
> > I see the retry ratio is high in the aggregated frame compare to what I
> > have here.
>
> It's nothing big really. The router is not yet connected to the
> internet, so I am mainly just opening the webpanel of the router or
> ping it.
how about just doing a flood ping to your AP
#sudo ping -f <AP's ip address>
Wey
Hi HEnrik,
On Mon, 2011-09-26 at 08:20 -0700, Henrik Friedrichsen wrote:
> Hey Wey,
>
> Sure! Here's the information you asked for:
>
> On Mon, Sep 26, 2011 at 4:54 PM, wwguy <[email protected]> wrote:
> > Hi Henrik,
> >
> > On Mon, 2011-09-26 at 07:07 -0700, Henrik Friedrichsen wrote:
> >> One more thing I have noticed:
> >>
> >> This message is only being printed when I connect to the AP, that I
> >> have problems with:
> >>
> >> Sep 26 07:05:03 dharma kernel: [ 2213.379252] iwlagn 0000:03:00.0: Tx
> >> aggregation enabled on ra = xx:xx:xx:xx:xx:xx tid = 0
> >>
> > this message telling us "11n/aggregation" is started; so looks like the
> > problem is aggregation related.
> I see. Well only after that has been printed, I can surf the internet.
> It takes a few seconds for that message to appear (after DHCP info
> retrieval).
> >
> >> On the APs that work fine, it DOES NOT get printed.
> >
> > I don't see anything special in the dmesg log you send, could you
> > provide us more information?
> >
> > 1. AP brand and model
> AVM Fritz!Box Fon WLAN 7390
> > 2. channel band and number
> It happens in the 2,4GHz and 5GHz frequencies, no matter what channel I use.
> > 3. firmware version
> 17.168.5.3 build 42301
> > 4. system setup (bluetooth or any other wireless devices on the system?)
> It's a Lenovo x220i laptop. It does have a Bluetooth chip, which is,
> however, deactived. Other than that there are no other wireless
> devices.
> > 5. if you can provide us more detail log, it will be great. (loading the
> > iwlagn with debug=0x43fff)
> Here's a more detailed log connecting to that AP in the 5GHz range:
> http://diff.cc/tmp/kernel_iwlagn.log
> >
> >
> >
not seeing anything stand-out in the log.
few things I will suggest and please give a try:
1. Please try to apply the following two patches I attach here.
2. load the iwlagn with debug=0x45800006, the log will be big, but it
will contain more information on the tx/rx path.
thanks
Wey
On 09/26/2011 05:12 PM, Henrik Friedrichsen wrote:
> On Mon, Sep 26, 2011 at 11:56 PM, Larry Finger
> <[email protected]> wrote:
>> Of course, it should take a little over 4 sec. Try adding the -D switch to
>> the ping command. Does repeating the ping command immediately change the
>> timing?
>
> There you go:
> ~> ping -Dc5 fritz.box
> PING fritz.box (192.168.178.1) 56(84) bytes of data.
> [1317074796.140468] 64 bytes from fritz.box (192.168.178.1):
> icmp_req=1 ttl=64 time=1.19 ms
> [1317074804.154425] 64 bytes from fritz.box (192.168.178.1):
> icmp_req=2 ttl=64 time=1.52 ms
> [1317074812.165947] 64 bytes from fritz.box (192.168.178.1):
> icmp_req=3 ttl=64 time=1.20 ms
> [1317074820.177252] 64 bytes from fritz.box (192.168.178.1):
> icmp_req=4 ttl=64 time=1.23 ms
> [1317074828.187470] 64 bytes from fritz.box (192.168.178.1):
> icmp_req=5 ttl=64 time=1.76 ms
>
> Nope, it doesn't.
Your ping seems to have an interval of 8 seconds, not 1 like the man page says.
Mine shows
finger@larrylap:~> ping -D -c5 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
[1317073193.249666] 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.19 ms
[1317073194.251148] 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=2.27 ms
[1317073195.250589] 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.14 ms
[1317073196.252548] 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.76 ms
[1317073197.253527] 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.801 ms
What does 'ping -i1 -D -c5 <AP>' show?
Larry
On Mon, Sep 26, 2011 at 11:56 PM, Larry Finger
<[email protected]> wrote:
> Of course, it should take a little over 4 sec. Try adding the -D switch to
> the ping command. Does repeating the ping command immediately change the
> timing?
There you go:
~ > ping -Dc5 fritz.box
PING fritz.box (192.168.178.1) 56(84) bytes of data.
[1317074796.140468] 64 bytes from fritz.box (192.168.178.1):
icmp_req=1 ttl=64 time=1.19 ms
[1317074804.154425] 64 bytes from fritz.box (192.168.178.1):
icmp_req=2 ttl=64 time=1.52 ms
[1317074812.165947] 64 bytes from fritz.box (192.168.178.1):
icmp_req=3 ttl=64 time=1.20 ms
[1317074820.177252] 64 bytes from fritz.box (192.168.178.1):
icmp_req=4 ttl=64 time=1.23 ms
[1317074828.187470] 64 bytes from fritz.box (192.168.178.1):
icmp_req=5 ttl=64 time=1.76 ms
Nope, it doesn't.
On Mon, 2011-09-26 at 08:41 -0700, Larry Finger wrote:
> On 09/26/2011 10:20 AM, Henrik Friedrichsen wrote:
>
> >> 1. AP brand and model
> > AVM Fritz!Box Fon WLAN 7390
>
> FWIW, we are working on a problem with using rtl8192cu and a Fritz!Box 7270 that
> doesn't seem to happen with any other AP. Our symptoms are different, but therre
> might be a related cause. If you find a fix, please let the list know. Our
> debugging is waiting for either Realtek to get access to such an AP, or for the
> OP to provide a Wireshark air dump. That AP is too pricey for my budget.
>
Same here :-), the AP is too pricey and we have problem re-produce the
problem in-house with other APs. But we are very active working on it
and will share anything we found.
Best Regards
Wey
>
>
One more thing I have noticed:
This message is only being printed when I connect to the AP, that I
have problems with:
Sep 26 07:05:03 dharma kernel: [ 2213.379252] iwlagn 0000:03:00.0: Tx
aggregation enabled on ra = xx:xx:xx:xx:xx:xx tid = 0
On the APs that work fine, it DOES NOT get printed.
Hello Wey,
On Mon, Sep 26, 2011 at 11:11 PM, wwguy <[email protected]> wrote:
> Henrik. what kind of traffic you are running? what I see from the log,
> there are not many aggregated frames, (what I mean is I do not see a lot
> of BA in the log) which is very different from what I am test here. also
> I see the retry ratio is high in the aggregated frame compare to what I
> have here.
It's nothing big really. The router is not yet connected to the
internet, so I am mainly just opening the webpanel of the router or
ping it.
SGkgSGVucmlrLA0KDQo+PiBwbGVhc2UgcmVzZXQgdGhlIHJlcG9zaXRvcnkgdG8NCj4+IGNvbW1p
dCMxZjdiNjE3MmRiODZlOWFiMmI0Y2Q3OTQ0NDFiYjJjNDBhYjI4N2ZjDQo+Pg0KPj4gYW5kIGdp
dmUgYSB0cnkgdG8gc2VlIGlmIHlvdSBzdGlsbCBzZWVpbmcgdGhlIGlzc3VlLg0KPg0KPk5vIG5v
dGljZWFibGUgZGlmZmVyZW5jZSA6KA0KDQpbTVZdIFlvdSdyZSBydW5uaW5nIFdpbmRvd3MgdXNp
bmcgdGhlIHNhbWUgY2FyZCAoNjIwNSksIHJpZ2h0PyBBbHNvLCBoYXZlIHlvdSBldmVyIHNlZW4g
Z29vZCBwZXJmb3JtYW5jZSB3aXRoIHlvdXIgNjIwNSBvbiB5b3VyIExpbnV4IHN5c3RlbT8gV2hh
dCBhYm91dCB3aXRoIGEgZGlmZmVyZW50IEFQPw0KDQpUaGFua3MsDQpNZWVuYWtzaGkNCg==
On Mon, 2011-09-26 at 14:31 -0700, Henrik Friedrichsen wrote:
> On Mon, Sep 26, 2011 at 11:17 PM, wwguy <[email protected]> wrote:
> > how about just doing a flood ping to your AP
> > #sudo ping -f <AP's ip address>
>
> Okay, here's what's happening:
> ~ > ping -f fritz.box
> PING fritz.box (192.168.178.1) 56(84) bytes of data.
> ping: cannot flood; minimal interval, allowed for user, is 200ms
>
> When I send regular pings:
> ~ > ping -c5 fritz.box
> PING fritz.box (192.168.178.1) 56(84) bytes of data.
> 64 bytes from fritz.box (192.168.178.1): icmp_req=1 ttl=64 time=1.31 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=2 ttl=64 time=1.26 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=3 ttl=64 time=1.30 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=4 ttl=64 time=2.51 ms
> 64 bytes from fritz.box (192.168.178.1): icmp_req=5 ttl=64 time=1.22 ms
>
> --- fritz.box ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 32046ms
> rtt min/avg/max/mdev = 1.226/1.524/2.515/0.496 ms
>
> As you can see, the packets get there and the response goes back to
> me. But it seems to take ages for the package to be sent. I've sent
> five pings and got my response back in regular latency, however the
> whole process took 32 seconds.
$sudo ping -f fritz.box
Wey
Hey Meenakshi,
On Mon, Sep 26, 2011 at 10:59 PM, Venkataraman, Meenakshi
<[email protected]> wrote:
> [MV] You're running Windows using the same card (6205), right? Also, have you ever seen good performance with your 6205 on your Linux system? What about with a different AP?
That's correct. On Windows the problem does not occur with that
particular router. Also I don't think I have had comparable problems
with other routers, at least not in my home (not on Linux, either).
I'm using a different AP right now and it works just fine.
SGkgSGVucmlrLA0KDQo+VGhhdCdzIGNvcnJlY3QuIE9uIFdpbmRvd3MgdGhlIHByb2JsZW0gZG9l
cyBub3Qgb2NjdXIgd2l0aCB0aGF0IHBhcnRpY3VsYXINCj5yb3V0ZXIuIEFsc28gSSBkb24ndCB0
aGluayBJIGhhdmUgaGFkIGNvbXBhcmFibGUgcHJvYmxlbXMgd2l0aCBvdGhlciByb3V0ZXJzLA0K
PmF0IGxlYXN0IG5vdCBpbiBteSBob21lIChub3Qgb24gTGludXgsIGVpdGhlcikuDQo+SSdtIHVz
aW5nIGEgZGlmZmVyZW50IEFQIHJpZ2h0IG5vdyBhbmQgaXQgd29ya3MganVzdCBmaW5lLg0KDQpb
TVZdIFRoYXQncyBpbnRlcmVzdGluZy4gV2hhdCBpcyB0aGUgbW9kZWwgb2YgdGhlIEFQIHRoYXQg
d29ya3M/IEFyZSB5b3UgdXNpbmcgdGhlIHNhbWUga2VybmVsIHZlcnNpb24gd2l0aCB0aGlzIEFQ
IChqdXN0IHdhbnQgdG8gY29uZmlybSB3aXRoIHlvdSk/IEFsc28sIGFyZSB5b3UgaW4gYSBwb3Np
dGlvbiB0byBzZW5kIHVzIChvbmx5KSBhIHNuaWZmZXIgbG9nPyANCg0KVGhhbmtzLA0KTWVlbmFr
c2hpDQoNCg==
On Mon, Sep 26, 2011 at 11:29 PM, wwguy <[email protected]> wrote:
> $sudo ping -f fritz.box
Oh I'm sorry.
~ > ping -f fritz.box
PING fritz.box (192.168.178.1) 56(84) bytes of data.
.^C
--- fritz.box ping statistics ---
48268 packets transmitted, 48267 received, 0% packet loss, time 81796ms
rtt min/avg/max/mdev = 1.066/1.642/54.477/1.830 ms, pipe 4, ipg/ewma
1.694/1.342 ms
Okay. As it turns out, the problem was distribution related (combined
with a few config changes I made when I was in China) and NOT
hardware. I'd rather not go into it, because it's almost too
embarrassing to admit. Either way, I would like to thank everyone of
you for the time and effort and apologize for the trouble. For me, it
is quite a relief, but I can understand if it pisses you off (wasted
time, etc.). Sorry guys!
Anyway, here's a free drink/tea/coffee coupon for compensation.. =X