[SOLVED] unstable wifi

rbees · 08-23-2011, 04:27 PM

Ladies & Gents,

I hate to ask but I am out of my depth on this one. The problem is my wireless connection is unstable.

My laptop is using a broadcom card

Code:

02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
        Subsystem: Hewlett-Packard Company Device 1483
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at b5400000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: wl

I have tried 2 different access points with the sames results and both have been rebooted several times. The laptop has been rebooted several times.

The symptoms: After an extended inactive period there is an extreme lag between the time a network request is made until the data returns. the data is returned at dial-up speeds instead of 12m that my cable line gives. If I plug a Ethernet cable in the response time and data speed returns to the speed is should. If I hammer on the connection long enough it goes to working the way it should until the next inactive period.

Example: If I go to one of the many online speed test sites an run the test, at its worst the upload speed test will not complete. Typically a latency of 30ms or so is reported but it takes 2-3 min for that test to complete.

network topology: internet > cable modem > linux external host > switch > wireless access point > laptop.

The external host runs debian-stable (fully up to date). It is dhcp, caching dns, firewall, intrusion detection, ip forwarding to internal hosts. I have ruled this host out because other wired hosts on the network do not suffer from these problems.

As I said I have tried two different access points and both seam to act the same.

I did speak to my neighbors who have the same provider and they are having latency issues too.

A sample of my through put.

Code:

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-22 16:32:00--
Saving to: “linux-2.4.19.tar.bz2”

 5% [===>                                                                                  ] 1,344,744    196K/s  eta 81s     ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-22 16:32:21--
Saving to: “linux-2.4.19.tar.bz2”

26% [=====================>                                                                ] 6,921,128    891K/s  eta 24s     ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-22 21:26:04-- 
Saving to: “linux-2.4.19.tar.bz2”

37% [===============================>                                                      ] 9,734,593   1.33M/s  eta 13s     ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-23 06:03:20-- 
Saving to: “linux-2.4.19.tar.bz2”

 0% [                                                                                      ] 95,257      --.-K/s  eta 51m 33s ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
 
--2011-08-23 06:33:46-- 

24% [====================>                                                                 ] 6,470,800   1.90M/s  eta 10s     ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-23 06:37:32-- 
Saving to: “linux-2.4.19.tar.bz2”

 0% [                                                                                      ] 156,072     --.-K/s  eta 40m 17s ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-23 09:40:48--
Saving to: “linux-2.4.19.tar.bz2”

 8% [======>                                                                               ] 2,203,545    653K/s  eta 37s     ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-23 15:29:41--
Saving to: “linux-2.4.19.tar.bz2”

 1% [>                                                                                     ] 337,073     40.2K/s  eta 9m 37s  ^C

:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
--2011-08-23 16:51:55--
Saving to: “linux-2.4.19.tar.bz2”

13% [==========>                                                                           ] 3,467,648    546K/s  eta 41s     ^C

Radically different amounts of throughput at different times through the day. Note that I did not record when I connected the ethernet wire in the list above. Although the last two are both on the wifi.

I sure hope someone can help me figure out how to correct this problem.

Thanks

salasi · 08-24-2011, 03:10 AM

Right now, this could be just about anything. My primary suspicions would be on wireless signal strength or perhaps DNS, but you could do with getting some useful evidence.

If you are using NM or WiCD, you should have an easy way of measuring wireless signal strength (actually, there will be a command line option, too). It would be very well worthwhile to observe signal strength over a period of time to see whether the signal strength is both adequate and constant. If that fails, look for co-channel interferers.

The other simple thing to check is whether the nameserver looks sensible (what do you expect it to be, is that what actually gets set?) and use dig to measure look up time. If the time to resolve a name is disastrously bad, it will give results similar to a poor data rate, particularly concentrating on a very large, and maybe erratic, latency time.

Another thing that would be worth trying would be to do some testing that remains internal to your network. You could ping your AP, your 'external host' and your cable modem to check that you get low and consistent ping times. (At least at first, ping by IP.)

rbees · 08-24-2011, 10:52 AM

well I thought I had posted this earlier this morning but it seam that it did not take

Thanks salasi,

I am sure that it is not signal strength. The access point currently in use is setting by my feet where I hooked it up to reconfigure it. The normal place for it and where the other one sits is, line of sight 12 feet to my right and above me by 8 feet in the loft over looking the living room. Only the one at my feet is currently active.

Nameserver. my external host is a caching/local nameserver. Current load on that system is <3%. I use opendns for anything that is not currently stored locally.

This morning as normal I had very limited access untill I plugged in the ethernet cable. One thing I do see that I did not mention before is that although it takes awhile for name resolution to occour when the data transfer actuall takes place it starts at normal speed but drops off to nothing over 10 seconds or so.

Dig is reporting a public ip for my local nameserver. And it is not the external ip assined by my isp. Connected by wire at the moment and throughput is normal. It returns the same ip whether the search is by name or by local ip (192.168.x.x).

In the first output for reverse lookup the ethernet wire was connected. In the second it was not.

Code:

:~$ dig -x 192.168.7.1

; <<>> DiG 9.7.3 <<>> -x 192.168.7.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48962
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.7.168.192.in-addr.arpa.      IN      PTR

;; Query time: 0 msec
;; SERVER: 192.168.7.1#53(192.168.7.1)
;; WHEN: Wed Aug 24 07:00:06 2011
;; MSG SIZE  rcvd: 42

:~$ dig -x 192.168.7.1

; <<>> DiG 9.7.3 <<>> -x 192.168.7.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32162
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.7.168.192.in-addr.arpa.      IN      PTR

;; Query time: 851 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Wed Aug 24 07:00:59 2011
;; MSG SIZE  rcvd: 42

Another thing observed is that if I disconnect the wireless manually in kde's network manager I am not able to reestablish a connection without a reboot of the laptop. Well this morning the reboot did not work.

I have Knemo which is a network activity widget for the system tray and it is not showing any activity durring the connect attemps this morning.

Connect attempts are not showing up in syslog on my dhcp server when I try to connect via wireless. But I am not sure that syslog is working right. The time stamps seam wrong.

wpa_supplicant seems to not be able to talk to the access point when the problem is active.

Code:

Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): carrier now ON (device state 2)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): device state change: 2 -> 3 (reason 40)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) starting connection 'Auto eth0'
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): device state change: 3 -> 4 (reason 0)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): device state change: 4 -> 5 (reason 0)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): device state change: 5 -> 7 (reason 0)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> dhclient started with pid 4825
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
Aug 24 06:16:35 Killerbee dhclient: Internet Systems Consortium DHCP Client 4.1.1-P1
Aug 24 06:16:35 Killerbee dhclient: Copyright 2004-2010 Internet Systems Consortium.
Aug 24 06:16:35 Killerbee dhclient: All rights reserved.
Aug 24 06:16:35 Killerbee dhclient: For info, please visit https://www.isc.org/software/dhcp/
Aug 24 06:16:35 Killerbee dhclient: 
Aug 24 06:16:35 Killerbee NetworkManager[1867]: <info> (eth0): DHCPv4 state changed nbi -> preinit
Aug 24 06:16:35 Killerbee dhclient: Listening on LPF/eth0/2c:27:d7:c0:dc:e7
Aug 24 06:16:35 Killerbee dhclient: Sending on   LPF/eth0/2c:27:d7:c0:dc:e7
Aug 24 06:16:35 Killerbee dhclient: Sending on   Socket/fallback
Aug 24 06:16:35 Killerbee dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
Aug 24 06:16:35 Killerbee dhclient: DHCPOFFER from 192.168.7.1
Aug 24 06:16:35 Killerbee dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Aug 24 06:16:36 Killerbee dhclient: DHCPACK from 192.168.7.1
Aug 24 06:16:36 Killerbee dhclient: bound to 192.168.7.23 -- renewal in 10039 seconds.
Aug 24 06:16:37 Killerbee NetworkManager[1867]: <info> Policy set 'Bathome' (eth1) as default for IPv4 routing and DNS.
Aug 24 06:16:37 Killerbee NetworkManager[1867]: <info> (eth0): device state change: 7 -> 8 (reason 0)
Aug 24 06:16:37 Killerbee NetworkManager[1867]: <info> Policy set 'Auto eth0' (eth0) as default for IPv4 routing and DNS.
Aug 24 06:16:37 Killerbee NetworkManager[1867]: <info> Activation (eth0) successful, device activated.
Aug 24 06:16:37 Killerbee NetworkManager[1867]: <info> Activation (eth0) Stage 5 of 5 (IP Configure Commit) complete.
Aug 24 06:20:03 Killerbee avahi-daemon[1593]: Withdrawing address record for fe80::2e27:d7ff:fec0:dce7 on eth0.

Aug 24 06:59:23 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 06:59:29 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 06:59:39 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 06:59:48 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:00:00 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:00:12 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:00:30 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:00:52 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:01:13 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:01:27 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:01:44 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:01:58 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:02:16 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:02:33 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:02:54 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:03:04 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:03:17 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:03:30 Killerbee dhclient: DHCPREQUEST on eth1 to 192.168.7.1 port 67
Aug 24 07:03:30 Killerbee dhclient: DHCPACK from 192.168.7.1
Aug 24 07:03:30 Killerbee dhclient: bound to 192.168.7.6 -- renewal in 10173 seconds.

Aug 24 07:08:45 Killerbee NetworkManager[1867]: <info> (eth1): device state change: 8 -> 3 (reason 39)
Aug 24 07:08:45 Killerbee NetworkManager[1867]: <info> (eth1): deactivating device (reason: 39).
Aug 24 07:08:45 Killerbee NetworkManager[1867]: <info> (eth1): canceled DHCP transaction, DHCP client pid 24579
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) starting connection 'Bathome'
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> (eth1): device state change: 3 -> 4 (reason 0)
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> (eth1): device state change: 4 -> 5 (reason 0)
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1/wireless): connection 'Bathome' requires no security.  No secrets needed.
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Config: added 'ssid' value 'Bathome'
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Config: added 'scan_ssid' value '1'
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Config: added 'key_mgmt' value 'NONE'
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> Config: set interface ap_scan to 1
Aug 24 07:08:57 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  disconnected -> scanning
Aug 24 07:08:58 Killerbee wpa_supplicant[1945]: Trying to associate with 00:18:4d:22:c8:63 (SSID='Bathome' freq=2442 MHz)
Aug 24 07:08:58 Killerbee wpa_supplicant[1945]: Association request to the driver failed
Aug 24 07:08:58 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  scanning -> associating
Aug 24 07:09:03 Killerbee wpa_supplicant[1945]: Authentication with 00:18:4d:22:c8:63 timed out.
Aug 24 07:09:03 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  associating -> disconnected
Aug 24 07:09:03 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  disconnected -> scanning
Aug 24 07:09:04 Killerbee wpa_supplicant[1945]: Trying to associate with 00:18:4d:22:c8:63 (SSID='Bathome' freq=2442 MHz)
Aug 24 07:09:04 Killerbee wpa_supplicant[1945]: Association request to the driver failed
Aug 24 07:09:04 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  scanning -> associating
Aug 24 07:09:09 Killerbee wpa_supplicant[1945]: Authentication with 00:18:4d:22:c8:63 timed out.
Aug 24 07:09:09 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  associating -> disconnected
Aug 24 07:09:09 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  disconnected -> scanning
Aug 24 07:09:10 Killerbee wpa_supplicant[1945]: Trying to associate with 00:18:4d:22:c8:63 (SSID='Bathome' freq=2442 MHz)
Aug 24 07:09:10 Killerbee wpa_supplicant[1945]: Association request to the driver failed
Aug 24 07:09:10 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  scanning -> associating
Aug 24 07:09:15 Killerbee wpa_supplicant[1945]: Authentication with 00:18:4d:22:c8:63 timed out.
Aug 24 07:09:15 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  associating -> disconnected
Aug 24 07:09:15 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  disconnected -> scanning
Aug 24 07:09:16 Killerbee wpa_supplicant[1945]: Trying to associate with 00:18:4d:22:c8:63 (SSID='Bathome' freq=2442 MHz)
Aug 24 07:09:16 Killerbee wpa_supplicant[1945]: Association request to the driver failed
Aug 24 07:09:16 Killerbee NetworkManager[1867]: <info> (eth1): supplicant connection state:  scanning -> associating
Aug 24 07:09:21 Killerbee wpa_supplicant[1945]: Authentication with 00:18:4d:22:c8:63 timed out.

Bruce Hill · 08-24-2011, 10:57 AM

Quote:

Originally Posted by salasi

If that fails, look for co-channel interferers.

Before going much further down the road, try putting this router on a
channel nothing else is on. Typically wireless telephones are down on
channel 1, and moving a router up to channel 11 will help that issue.

rbees · 08-24-2011, 12:12 PM

Thanks Bruce,

We only have cell phones. I have set the "Access Point" to channel 11 and we will see. All routing is handled by the external firewall/dhcp/dns/nat host running Debian Squeeze.

The problem only occurs after long periods of inactivity, normally overnight when there is no phone usage.

We live in a remote area not a big city, so overnight is very quiet. In fact I can even hear the trucks on the highway 6 miles away through the woods at night.

Will be doing some testing with some windows hosts when the problem comes up again.

rbees · 08-25-2011, 06:34 AM

OK setting the access point to a speciffic chanel did not fix it just as I thouht it would not but, hey it was worth a shot. Also note that this problem does not affect another user's xp-pro laptop it only affects the Debian Wheezey laptop.

I have not pulged the ethernet cable in yet this morning so all output if from the wifi.

Code:

kingbee@Killerbee:~$ sudo wget http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
[sudo] password for kingbee: 
--2011-08-25 06:24:13--  http://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
Resolving ftp.kernel.org (ftp.kernel.org)... 149.20.4.69, 149.20.20.133, 2001:4f8:8:10:1994:313:1:0, ...
Connecting to ftp.kernel.org (ftp.kernel.org)|149.20.4.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 26042494 (25M) [application/x-bzip2]
Saving to: `linux-2.4.19.tar.bz2'

 1% [                                                                                      ] 279,153     16.4K/s  eta 24m 5s  ^Ckingbee@Killerbee:~$rm linux-2.4.19.tar.bz*
rm: remove write-protected regular file `linux-2.4.19.tar.bz2'? y

kingbee@Killerbee:~$ sudo ping www.google.com
PING www.l.google.com (74.125.225.49) 56(84) bytes of data.
64 bytes from 74.125.225.49: icmp_req=1 ttl=52 time=29.7 ms
64 bytes from 74.125.225.49: icmp_req=2 ttl=52 time=711 ms
64 bytes from 74.125.225.49: icmp_req=6 ttl=52 time=1885 ms
64 bytes from 74.125.225.49: icmp_req=7 ttl=52 time=878 ms
64 bytes from 74.125.225.49: icmp_req=9 ttl=52 time=19.3 ms
64 bytes from 74.125.225.49: icmp_req=11 ttl=52 time=63.4 ms
^C64 bytes from 74.125.225.49: icmp_req=13 ttl=52 time=62.6 ms

--- www.l.google.com ping statistics ---
13 packets transmitted, 7 received, 46% packet loss, time 42046ms
rtt min/avg/max/mdev = 19.330/521.588/1885.578/647.950 ms, pipe 2

kingbee@Killerbee:~$ date
Thu Aug 25 06:26:31 EDT 2011

As I have thougt and the ping output shows I am loosing packets. I have tcpdump running on a different host capturing the traffic.

The ping output from the external host

Code:

:~$ sudo ping www.google.com
PING www.l.google.com (74.125.225.81) 56(84) bytes of data.
64 bytes from 74.125.225.81: icmp_req=1 ttl=54 time=18.8 ms
64 bytes from 74.125.225.81: icmp_req=2 ttl=54 time=18.8 ms
64 bytes from 74.125.225.81: icmp_req=3 ttl=54 time=18.4 ms
64 bytes from 74.125.225.81: icmp_req=4 ttl=54 time=18.8 ms
64 bytes from 74.125.225.81: icmp_req=5 ttl=54 time=17.0 ms
64 bytes from 74.125.225.81: icmp_req=6 ttl=54 time=18.4 ms
64 bytes from 74.125.225.81: icmp_req=7 ttl=54 time=18.2 ms
64 bytes from 74.125.225.81: icmp_req=8 ttl=54 time=18.5 ms
64 bytes from 74.125.225.81: icmp_req=9 ttl=54 time=17.4 ms
64 bytes from 74.125.225.81: icmp_req=10 ttl=54 time=17.9 ms
64 bytes from 74.125.225.81: icmp_req=11 ttl=54 time=19.0 ms
64 bytes from 74.125.225.81: icmp_req=12 ttl=54 time=16.9 ms
^C
--- www.l.google.com ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11013ms
rtt min/avg/max/mdev = 16.965/18.231/19.041/0.701 ms

:~$ sudo ping Killerbee
PING Killerbee.Torah-disciple.local (192.168.7.6) 56(84) bytes of data.
64 bytes from 192.168.7.6: icmp_req=1 ttl=64 time=0.937 ms
64 bytes from 192.168.7.6: icmp_req=7 ttl=64 time=1.01 ms
64 bytes from 192.168.7.6: icmp_req=13 ttl=64 time=1.07 ms
64 bytes from 192.168.7.6: icmp_req=18 ttl=64 time=804 ms
64 bytes from 192.168.7.6: icmp_req=19 ttl=64 time=0.881 ms
64 bytes from 192.168.7.6: icmp_req=24 ttl=64 time=908 ms
64 bytes from 192.168.7.6: icmp_req=25 ttl=64 time=0.998 ms
64 bytes from 192.168.7.6: icmp_req=27 ttl=64 time=458 ms
64 bytes from 192.168.7.6: icmp_req=31 ttl=64 time=29.5 ms
64 bytes from 192.168.7.6: icmp_req=32 ttl=64 time=0.967 ms
64 bytes from 192.168.7.6: icmp_req=35 ttl=64 time=299 ms
64 bytes from 192.168.7.6: icmp_req=38 ttl=64 time=0.921 ms
^C
--- Killerbee.Torah-disciple.local ping statistics ---
38 packets transmitted, 12 received, 68% packet loss, time 37149ms
rtt min/avg/max/mdev = 0.881/209.061/908.690/322.825 ms

The question is why is it loosing packets. Closer examination of the output (most not posted) shows that when the laptop pings the external host there is no packet loss but when it pings google there is packet loss. The odd thing is that when the external host pings google there is no packet loss but when it pings the laptop there is packet loss.

When a wired host pings the laptop there is packet loss. When the xp-pro laptop pings the Debian laptop there is packet loss but not when it pings anything else.

So now what? Guess I get to learn how to read capture files

rbees · 08-25-2011, 10:41 AM

ok that was weird. I plugged in the cable and ran apt-get update then the wireless reconnected. I had not disconnected it. Strange, but I am not sure it is related.

So moving on to some hours later. I looked at the network capture but can't make any sense of it beyond the superficial.

I have tried unloading the wl driver and reloading it but no joy. I still can not reconnect to the wireless once I disconnect from it.

I have install the wicd network manager, no reboot, and I can not connect with it either.

The wired connection works as normal.

Restarted the external firewall with no joy. But that should not have been the problem anyway unless the IDS wrote a rule for some reason.

I did a capture from the Debian laptop when I was trying to reconnect to the wifi and although the the broadcast is being made there is no response.

So after several reboots trying both wicd and kde-network-manager I was unable to connect. Thought maybe the wifi card in the laptop had crapped out so booted to win7. It also would not connect. Restarted the access point and then was able to connect.

Thing is that just restarting the access point by its self will not correct the problem I am having, or so my testing tells me. Neither does just rebooting the Laptop. Am not sure that a reboot of both does either.

rbees · 08-28-2011, 06:40 AM

Well Ladies & Gents

I do believe that I have solved the problem. It was interference. But not what I expected.

I have the laptop setup to unlock when my cell phone comes near with blueproximity. It seams that when I shut the cell off blueproximity starts doing some heavy lifting trying to reestablish a connection to the phone. That transmitting is interfering with the laptop's ability to send to the access point.

So the simple solution is to disable blueproximity when the cell is turned off, like overnight.

I don't know how the laptop is affected when I am gone out on a job.

I don't know it the problem is specific to this laptop because of its antenna configuration.

I don't know it it is a bug in blueproximity.