[CLOSED. MOVED.
Folks, thank you for all your help. I am now working with someone on the Ubuntu Wireless Forum to install ndiswrapper. I appreciate your
sharing your time and knowledge. Peter.
]



Hi. I'm a Linux noob (Ubuntu 7.04 server w/ Gnome on top) w/ wireless probs. I could SWEAR I had it all working at one time, using the instructions in Howto:Broadcom Wireless

Configuration: Compaq R3000z laptop 512MB. AMD 2800 (32-bit). Ubuntu 7.04 server w/ Gnome installed on top. Dual boot w/ WinXP. Gnome-network-manager installed. On-board Broadcom wireless. D-Link DI-514 802.11b router. 2 other Windows machines hung off this router (and the WinXP instance running on the dual-boot machine) all have full wireless functionality.

Symptoms: Glacially slow to non-existent response time across multiple applications (e.g., http(Firefox and Opera), telnet, ftp); Wired is fine; Wireless connection recognized by network manager w/ good signal (70-80%).

Actions taken:
1. I tried disabling IPv6 per this post, but neither of the approaches actually seemed to work. I.e., I created an /etc/modprobe.d/bad_list file, populated it per the post, and rebooted. But afterward the cmd " ip a | grep inet6" was still returning output, so I assumed IPv6 was not disabled. Nor was it disabled when I directly edited the aliases file and made the changes suggested in the post. OTOH, one poster indicates the "Having IPv6 be the cause of 'slow' connection is actually a common
misconception", so I'm not sure whether the exercise was even worthwhile.
2. I tried also to update my resolv.conf file w/ a different nameserver entry than my router, but network manager just overwrites the file sans the entry. Per the ping results below, it doesn't seem to be a nameserver prob anyway.

Comment: I swear, this is all that stands between me and jettisoning Windows once and for all! Also, I have a Netgear WG511T PCMCIA cardbus in hand. Is it possible to override the default Broadcom hardware and try this card instead? Thanks. Peter


Diagnostics:

Here are the results of pinging the router (I figure that since the problem manifests this far up the food chain, I don't need to be pinging more distant locations):

Wired:
peter@cosmo:~$ ping -c 10 192.168.0.1
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=255 time=0.499 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.493 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.489 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.490 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=255 time=0.490 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=255 time=0.492 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=255 time=0.496 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=255 time=0.484 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=255 time=0.489 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=255 time=0.485 ms

--- 192.168.0.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8994ms
rtt min/avg/max/mdev = 0.484/0.490/0.499/0.026 ms
###########################################################
Wireless (Linux/Ubuntu):
peter@cosmo:~$ ping -c 10 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=46.4 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=255 time=15.8 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=255 time=37.1 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=255 time=5.23 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=255 time=17.7 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=255 time=6.97 ms

--- 192.168.0.1 ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 9008ms
rtt min/avg/max/mdev = 5.230/21.549/46.416/15.202 ms
###########################################################
Wireless (WinXP on the same machine, FWIW):
C:\Documents and Settings\Peter>ping -n 10 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:

Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=2ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=2ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.0.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
###########################################################
lspci:
peter@cosmo:~$ lspci
00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev a6)
00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4)
00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5)
00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2)
00:06.1 Modem: nVidia Corporation nForce3 Audio (rev a2)
00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5)
00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3)
02:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
02:04.0 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.1 CardBus bridge: Texas Instruments PCI1620 PC Card Controller (rev 01)
02:04.2 System peripheral: Texas Instruments PCI1620 Firmware Loading Function (rev 01)
###########################################################
iwconfig:
peter@cosmo:~$ iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 IEEE 802.11b/g ESSID:"peter" Nickname:"Broadcom 4306"
Mode:Managed Frequency=2.462 GHz Access Point: 00:0D:88:28:D7:94
Bit Rate=11 Mb/s Tx-Power=19 dBm
RTS thr:off Fragment thr:off
Link Quality=71/100 Signal level=-53 dBm Noise level=-69 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
###########################################################
ifconfig:
peter@cosmo:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:90:4B:B7:E2:40
inet addr:192.168.0.107 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::290:4bff:feb7:e240/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:340 errors:0 dropped:1 overruns:0 frame:0
TX packets:542 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:112262 (109.6 KiB) TX bytes:25295 (24.7 KiB)
Interrupt:11 Base address:0xc000

eth1 Link encap:Ethernet HWaddr 00:0F:B0:4C:46:89
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:306 errors:0 dropped:0 overruns:0 frame:0
TX packets:237 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:245571 (239.8 KiB) TX bytes:32240 (31.4 KiB)
Interrupt:17 Base address:0xe800

eth1:avah Link encap:Ethernet HWaddr 00:0F:B0:4C:46:89
inet addr:166.254.5.21 Bcast:166.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:17 Base address:0xe800

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:727 (727.0 b) TX bytes:727 (727.0 b)"]
###########################################################
lshw -C network
*-network:0
description: Ethernet interface
product: RTL-8139/8139C/8139C+
vendor: Realtek Semiconductor Co., Ltd.
physical id: 1
bus info: pci@02:01.0
logical name: eth1
version: 10
serial: 00:0f:b0:4c:46:89
width: 32 bits
clock: 33MHz
capabilities: bus_master cap_list ethernet physical
configuration: broadcast=yes driver=8139too driverversion=0.9.28 ip=192.168.0.115 latency=64 maxlatency=64 mingnt=32 multicast=yes
resources: ioport:7000-70ff iomemory:e0108800-e01088ff irq:17
*-network:1
description: Wireless interface
product: BCM4306 802.11b/g Wireless LAN Controller
vendor: Broadcom Corporation
physical id: 2
bus info: pci@02:02.0
logical name: eth0
version: 03
serial: 00:90:4b:b7:e2:40
width: 32 bits
clock: 33MHz
capabilities: bus_master ethernet physical wireless
configuration: broadcast=yes driver=bcm43xx driverversion=2.6.20-16-server latency=64 multicast=yes wireless=IEEE 802.11b/g
resources: iomemory:e0104000-e0105fff irq:21
###########################################################

Many thanks.
P.S. As I write this, I'm glancing over at my WinVista machine, BSODing, dumping, and restarting--all without a single keystroke or mouse click on my part. How very feature-rich!!!

I would use a sniffer to watch the packets over the wireless. You can use tcpdump but I prefer Wireshark.

http://www.wireshark.org/

I would look for things like out of order packets, retransmitted packets, and that sort of thing.

The performance under Windows XP is also an excellent diagnostic. That tells you that the wireless NIC and the wireless access point can work well together. That means that you have a software problem. So that bit of information is worth a lot.

You might ask what Wireshark is going to tell you. Right now we are looking for what is working and what is not working. That will help us diagnose the problem. So I don't know whether Wireshark will show a problem or not. Either way it will help to fill in our understanding of what is happening.

You could also look at the system log files. Problems with hardware drivers are often logged there. Particularly look at the beginning of the log file where the wireless NIC's module is loaded.

Stress-junkie:

Thank you! Have installed Wireshark on Ubuntu.

True to my noob-itude, I have some questions and will need some time:
1) Assume I should be running Wireshark under Linux and not Windows (or both?)
2) I'm vaguely familiar w/ /var/log but know little about the individual files. I intend to slog through them this weekend, as a tutorial of sorts, but meanwhile, do you have any specific suggestions about which logs to search and suspicious strings to look for?
3) Please be patient. I need to learn Wireshark before I run it. Will whack away at it this weekend and hopefully produce some useful output in a day or two.
Thanks again.

The best way to run Wireshark is to start it as root, click on Capture -> Options.
A new window will appear. Select the correct network card. In the same window enable the three display options. The name resolution options are interesting to mix and match. Finally click on the Start button at the bottom of the window.

Then as a normal user you can use the ping utility as you did before. You can use a web browser. Anything that sends and receives network traffic is fine. You will know which packets are bad. They will be shown in black or red and the information column will say things like out of order or retransmission or duplicate packet.

The system log files are pretty easy to figure out. The one log file that acts as a catch all is /var/log/messages. You can read that and look for errors during boot or at the end of the file when you are using the wireless NIC.
If your system has a file named /var/log/dmesg then this will contain messages of things that happened during system startup.
Unfortunately different distributions do different things with the log files. You may have a file named /var/log/boot.log or /var/log/boot.msg. Either of these will have messages from events that happened during system startup. You should be looking for errors that happen when the wireless NIC driver is loaded or when the network software is started.

I wouldn't place Gnome's network manager above suspicion at this point. I've seen some truly odd behavior, like

• a pop-up telling my I was now connected to the wired network when I was just then staring at an unplugged Ethernet cable
• connectivity icons (terminals for wired, signal strength bars for wireless) that would simply disappear regardless of current network status

-to name a few. We'll see...

Thanks for the Wireshark and syslog tips. Will jump in and see what I find.

I've encountered similar behavior when there are other accesspoints on the same channel, but then you'll get lots of "Rx invalid nwid" with iwconfig. You have none, so that's not the problem, unless you were lucky when you ran that command . You could dump the gnome network manager and try wpa_supplicant to see if it helps. Take a look at my HOWTO at http://users.utu.fi/sjsepp/hostapd/hostap.html to see how to configure wpa_supplicant the "Debian way".

I conducted a troubleshooting session yesterday. The system logs from that session are availble here. In addition to the 6 logs, there is a .pcap file showing Wireshark output for the session, plus PeterUserLog.odt in which I describe and timestamp my mouse and keyboard actions (so you can more or less see what user actions are associated with what log entries).

I tried to create .odt versions of all the logs, so I could highlight and annotate suspicious (to my untrained eye) entries, but uploads that worked yesterday are failing today.

Here are some excerpts (though I have no idea whether they are what I'm after):

1) A couple of entries suggesting conflict in the assignment of wireless drivers. See messages0812 file:
Aug 12 07:47:56 cosmo kernel: [ 8.430000] 8139cp 0000:02:01.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
Aug 12 07:47:56 cosmo kernel: [ 8.430000] 8139cp 0000:02:01.0: Try the "8139too" driver instead.
Aug 12 07:47:56 cosmo kernel: [ 8.480000] 8139too Fast Ethernet driver 0.9.28
Aug 12 07:47:56 cosmo kernel: [ 8.480000] eth0: RealTek RTL8139 at 0xe09a6800, 00:0f:b0:4c:46:89, IRQ 17

versus
Aug 12 07:47:56 cosmo kernel: [ 26.030000] bcm43xx driver
2) Also from the messages0812 file
Aug 12 07:48:54 cosmo dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason
Aug 12 07:49:17 cosmo kernel: [ 114.540000] SoftMAC: Open Authentication completed with 00:0d:88:28:d7:94
Aug 12 07:49:18 cosmo kernel: [ 114.830000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Aug 12 07:49:28 cosmo dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.host_name
Aug 12 07:49:28 cosmo dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.domain_name
Aug 12 07:49:28 cosmo dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.nis_domain
Aug 12 07:49:28 cosmo dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.nis_servers

3) From dmesg:
[ 8.480000] eth0: RealTek RTL8139 at 0xe09a6800, 00:0f:b0:4c:46:89, IRQ 17
[ 8.480000] eth0: Identified 8139 chip type 'RTL-8101'
and
[ 26.030000] bcm43xx driver

4) From kern.log (2 messages displayed on startup every time):
Aug 12 07:47:56 cosmo kernel: [ 20.329173] PCI: Failed to allocate mem resource #10:4000000@e4000000 for 0000:02:04.0
Aug 12 07:47:56 cosmo kernel: [ 20.329232] PCI: Failed to allocate mem resource #10:4000000@e4000000 for 0000:02:04.

5) From the syslog:
A ton of messages from Network Manager best viewed via the link at the top of this post.

6) From udev:
UEVENT[1186904802.789611] add /class/net/eth0 (net)
ACTION=add
DEVPATH=/class/net/eth0
SUBSYSTEM=net
SEQNUM=1724
PHYSDEVPATH=/devices/pci0000:00/0000:00:0a.0/0000:02:01.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=8139too
INTERFACE=eth0

and

UDEV [1186904802.971685] add /class/net/eth1 (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/class/net/eth1
SUBSYSTEM=net
SEQNUM=1724
PHYSDEVPATH=/devices/pci0000:00/0000:00:0a.0/0000:02:01.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=8139too
INTERFACE=eth1
UDEVD_EVENT=1
INTERFACE_OLD=eth0

and

UEVENT[1186930069.392520] add /class/net/eth0 (net)
ACTION=add
DEVPATH=/class/net/eth0
SUBSYSTEM=net
SEQNUM=2522
PHYSDEVPATH=/devices/pci0000:00/0000:00:0a.0/0000:02:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=bcm43xx
INTERFACE=eth0

and finally

UDEV [1186930069.739166] add /class/net/eth0 (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/class/net/eth0
SUBSYSTEM=net
SEQNUM=2522
PHYSDEVPATH=/devices/pci0000:00/0000:00:0a.0/0000:02:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=bcm43xx
INTERFACE=eth0
UDEVD_EVENT=1

Any further guidance deeply appreciated.

I saw the same thing happen when I was trying to conduct a wireless survey with a live cd and and a HP with the bcm4606 - slow speed and eth0/eth1 conflicts. I believe you can make a temporary change by removing the bcm43xx module using:

modprobe -r bcm43xx.

Then you can then plug in your netgear card. That is what I did so that I had only one wireless interface running. I believe the madwifi drivers are installed by default and will run just beautifully. To return bcm43xx:

modprobe bcm43xx

To permanently prevent loading bcm43xx at boot try:

echo 'blacklist bcm43xx' | sudo tee -a \
/etc/modprobe.d/blacklist

My observation is that around the time detection of the nics is underway something in udev or hal or something creates a conflict between eth0 and eth1 where the bcm43xx is assigned eth0 while the system expects the wired that exists is going to be eth0 rather than eth1. (I had the same problem with fedora 7 beta although I haven't tested it since).

I recently found that you need to use the windows drivers that came with the computer/nic to extract the firmware. It seems to work better with my bcm4318 (haven't tested it on bcm4306).

Feistyfeline:

I did this:

Edited the blacklist file and added these two lines:
#blacklist broadcomm wireless driver in favor of 8139too
blacklist bcm43x

Shut down, inserted the WG511T and restarted.

Results:
Pretty much no recognition of the card. iwconfig returns nothing at all for eth0
peter@cosmo:~$ iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

Network manager sees no wireless networks. And selecting "manual configuration" shows no entry for wireless.

However the dmesg log shows
[ 8.540000] eth0: RealTek RTL8139 at 0xe0954800, 00:0f:b0:4c:46:89, IRQ 17 (router MAC address is correct)
[ 8.540000] eth0: Identified 8139 chip type 'RTL-8101'
while lspci shows
02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

Am going to update my O.P. on the Ubuntu forum with latest results. Meanwhile, am open to other ideas. I'm certainly out or 'em. Thanks.

FYI, the 8139too driver is for wired network connections only, not wireless. What does lspcmcia show when the wg511t is plugged in? There's a chance it, too, may contain a broadcom chipset.