Link to home
Start Free TrialLog in
Avatar of jpattee
jpatteeFlag for United States of America

asked on

Cannot Obtain IP Adress with Linux

I have my Dell Inspiron 1501 set up for dual boot to Windows Vista and Debian Linux. Everything is OK except one wireless connection to Linux. The Windows connection works. With Linux it usually works but there is a problem connecting to one network.

I use the wireless connection at home and at school. All networks are unsecured. At school I connect to 2 wireless networks without a problem. At home I need to connect to the "Travel Inn" network. I can connect with Windows but not with Linux. Linux detects the network but cannot find the IP address. When I manually configure it can connect to the network but hangs when it looks up the name.

Why can Linux not connect to this one network?
Is there a way to fix it? The source code for Linux is available so a program fix is possible.

Technical Linux stuff:

The wireless card is a "Dell Wireless 1390 WLAN Mini-Card".
Chipset is BCM4311/BCM2050.

The firmware was extracted with bcm43xx-fwcutter using "wl_apsta-3.130.20.0.o". B43-fwcutter didn't work. I tried ndiswrapper and it worked, but I had the same problem. I tried several Linuxant drivers but they gave an error message when I tried to extract the firmware.

To connect to the network I use wicd. I also used wifi-radar, gtkwifi, and wlassiatant. They all had the same problem as wicd. I tried several others but they didn't work at all. Usually they didn't detect the networks.
Avatar of noci
noci

did you configure dhcp in wicd to obtain an address?
Avatar of jpattee

ASKER

I tried wicd both ways. The automatic configuration could not find an IP address. When I configured manually, it connected to the site but could not communicate with it. The automatic configuration on Windows Vista works OK. I tried other Linux configuration managers and they all did the same thing.

Following is the iwconfig before a wicd connect attempt:

eth0      IEEE 802.11b/g  ESSID:off/any  Nickname:"Broadcom 4311"
          Mode:Managed  Frequency=2.472 GHz  Access Point: Invalid  
          Bit Rate=1 Mb/s   Tx-Power=18 dBm  
          RTS thr:off   Fragment thr:off
          Encryption key:off
          Link Quality=0/100  Signal level=0 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

This is iwconfig after wicd tries to connect:

eth0      IEEE 802.11b/g  ESSID:"Travel Inn"  Nickname:"Broadcom 4311"
          Mode:Managed  Frequency=2.437 GHz  Access Point: 00:11:45:02:3B:C7  
          Bit Rate=24 Mb/s   Tx-Power=18 dBm  
          RTS thr:off   Fragment thr:off
          Encryption key:off
          Link Quality=60/100  Signal level=-71 dBm  Noise level=-69 dBm
          Rx invalid nwid:0  Rx invalid crypt:51  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
             
A "dhclient eth0" command results in:

No DHCPOFFERS received.
No working leases in persistent database - sleeping.

I think there is something about the network that is causing the problem. Check the following link.

http://support.microsoft.com/kb/928233

I have tried to disable the Broadcast flag in Linux and get the following:

root@debian:~# ifconfig eth0 -broadcast
Warning: Interface eth0 still in BROADCAST mode.
root@debian:~#

Do you know how to reset the Broadcast flag in Linux?

I will try any ideas anyone has. I have searched the Internet and this problem occurs occasionally. No one seems to know the solution.
It is a different broadcast flag...
According to the RFC2131 (DHCP RFC,  http://www.ietf.org/rfc/rfc2131.txt)
The broadcast flag SHOULD be set by a client if it requests a DHCP address when the hardware is not capable of receiving UNICAST packets. it should be 0 otherwise. (The bit is specified during discovery phase, and is part of the DHCP protocol).

For systems that are booting from a ROM, and have no real IP stack active yet you might expect this to be one. Otherwise the systems should not use this. Win 2K is correct in its use... besides this:

A RedHat specific extension (built for the zOS linux systems) is -B or the dhclient.conf option bootp-broadcast-allways
will set the bit. Implying that is normaly is not set on unix.

If you were ably to drop the broadcast flag on an ethernet interface(or alike interface) TCPIP would soon cease to function as the ARP protocol can only live with broadcast packets.

Hi, jpattee

You say your home network is secured, but after connection is established there is "Encryption key:off" Also I see 'Rx invalid crypt:51'. So my guess is you are using either invalid encryption key or encryption scheme (say WEP instead of WPA). That's why you can't obtain IP.
Check your correct network connection properties under Windows.
@nopius,

all networks are unsecured, so the encryption key off is correct.
It is strange that encrypted messaged have been received, but that might be collateral from another
accesspoint.

@jpattee,
The question is why dhclient doesn't work... It can mean the accesspoint doesn't accept the messages,
or they are not transmitted. Is it possible to monitor traffic while wicd runs?
tcpdump could be a tool here (or wireshark).
BTW, the addresses you get on windows what range do they have...
might it be in 169.254.x.y?

In that case you need a tool that can negiotiate UPNP addresses as well as DHCP, for UPNP there is no
real need for DHCP. Windows does also use UPNP is dhcp fails.

UPNP would be strange to be used like this as it is a security risk. Through UPNP the admin password of the gateway in question can be asked out. See also: http://www.shorewall.net/UPnP.html

you then might need a tool called linux-igd
Avatar of jpattee

ASKER

Since I connect OK with Windows I have posted the registry values. This connection works and was configured automatically by Windows Vista. The range of addresses are 192.168.0.1 thru 192.168.0.222.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{F372CDB9-37A5-4BE7-AE00-E8CA0AA71944}]
"UseZeroBroadcast"=dword:00000000
"EnableDeadGWDetect"=dword:00000001
"EnableDHCP"=dword:00000001
"NameServer"=""
"Domain"=""
"RegistrationEnabled"=dword:00000001
"RegisterAdapterName"=dword:00000000
"IPAutoconfigurationAddress"="0.0.0.0"
"DhcpIPAddress"="192.168.0.222"
"DhcpSubnetMask"="255.255.255.0"
"DhcpServer"="192.168.0.1"
"Lease"=dword:00015180
"LeaseObtainedTime"=dword:479a8734
"T1"=dword:479b2ff4
"T2"=dword:479bae84
"LeaseTerminatesTime"=dword:479bd8b4
"AddressType"=dword:00000000
"IsServerNapAware"=dword:00000000
"DhcpConnForceBroadcastFlag"=dword:00000001
"DhcpInterfaceOptions"=hex:2e,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00,b4,\
  d8,9b,47,01,00,00,00,0f,00,00,00,00,00,00,00,11,00,00,00,00,00,00,00,b4,d8,\
  9b,47,67,61,74,65,77,61,79,2e,32,77,69,72,65,2e,6e,65,74,00,00,00,01,00,00,\
  00,00,00,00,00,04,00,00,00,00,00,00,00,b4,d8,9b,47,ff,ff,ff,00,03,00,00,00,\
  00,00,00,00,04,00,00,00,00,00,00,00,b4,d8,9b,47,c0,a8,00,01,06,00,00,00,00,\
  00,00,00,04,00,00,00,00,00,00,00,b4,d8,9b,47,c0,a8,00,01,36,00,00,00,00,00,\
  00,00,04,00,00,00,00,00,00,00,b4,d8,9b,47,c0,a8,00,01,35,00,00,00,00,00,00,\
  00,01,00,00,00,00,00,00,00,b4,d8,9b,47,05,00,00,00,fc,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,6a,87,9a,47,3b,00,00,00,00,00,00,00,04,00,00,00,00,\
  00,00,00,b4,d8,9b,47,00,01,27,50,3a,00,00,00,00,00,00,00,04,00,00,00,00,00,\
  00,00,b4,d8,9b,47,00,00,a8,c0,33,00,00,00,00,00,00,00,04,00,00,00,00,00,00,\
  00,b4,d8,9b,47,00,01,51,80
"DhcpDomain"="gateway.2wire.net"
"DhcpSubnetMaskOpt"=hex(7):32,00,35,00,35,00,2e,00,32,00,35,00,35,00,2e,00,32,\
  00,35,00,35,00,2e,00,30,00,00,00,00,00
"DhcpDefaultGateway"=hex(7):31,00,39,00,32,00,2e,00,31,00,36,00,38,00,2e,00,30,\
  00,2e,00,31,00,00,00,00,00
"DhcpNameServer"="192.168.0.1"
Avatar of jpattee

ASKER

I have attached a Wireshark text file.
I don't know if it contains useful information.
It needs to be opened in Wireshark.
wireshark.txt
Ok it tels someone was checking IP addresses, as the gateway appearantly asks addresses from all clients.   ARP = Address Resolution Protocol
The gateways is made by 2wire.
system 0.68 is asking for www.google.com through Netbios Name resolution (misconfigured DNS? in that system)

There seems to some conflicting info:
Macaddress from  wireshark: 00:1b:5b:85:ed:39     - has gateway address 192.168.0.1
Mac address from earlier post: 00:11:45:02:3B:C7 - is accesspoint.
Maybe the registy is outdated info
Have you checked ipconfig /all from a cmd prompt (open it in a window, not as run... from the start menu).

Your system probably is: IntelCor chipset; 00:1vc:bf:14:34:81
At packet 67 it does a request for DHCP, at packet 73 is goes for UPNP address 169.254.125.41..... a second later.
At packet 86 another check if the UPNP address is used.

At packet 113 there is an DHCP ACK broadcasted with address 192.168.0.74
which is picked up according to the ARP packet next to it.
packet 151 is a retransmit of 113

For some reason the gateway keeps on giving DNS denied messages for queries about isatap.gateway.2wire.net name searches.

 think my assumption of the above is wrong, this is only listening on the device it isn't involved in communication as I am missing crucial packets that should be going out..., like requests with the answers I do see.

Would it be possible to do the following:
On windows:
ipconfig /all
Start wireshark - + capture
ipconfig /release
ipconfig /renew
and store it here

start wireshark on the interface
run dhclient
and store that too?
The last 3 commands would be on linux, obviously ;-)
Just a note, I've run into some real issues with the Broadcom 4311 wireless cards and Cisco access points under Debian / Ubuntu.  I've got them up and working fine with Linksys and D-Link wireless routers but I've run into substantial packet loss with the access points to the point where the access point cuts the connection after 10 seconds or so.

If the network in question uses them, it may be that the solution lies in the driver and its dealings with Cisco wireless networks.

The same cards under Windows work flawlessly.

I wonder if Dell has an updated driver since they're recently made the move to selling Ubuntu systems.
Avatar of jpattee

ASKER

Attached are the results of the test.

Syngin9:

I tried every driver available from Dell. The results were the same. I am currently using something called "wl_apsta-3.130.20.0.o" which I don't think is from Dell but is recommended at the fwcutter site. I also tried ndiswrapper with the same results.
ipconfigWindows.txt
wiresharkWindows.txt
dhclientLinux.txt
wiesharkLinux.txt
OK,

Your linux system DOES send DHCPDISCOVERS and receives NOTHING.
From your windows system I do not see a full discover packet, just renewals.  (one DHCPREQUEST + one DHCPACK).
A full cycle is DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK.
This was all from the view point of your PC.

Are you able to capture traffic about your system from the air with another system running wireshark?
If no traffic is visible during which you run a dhclient in linux than that would be proof that the
wireless card has problems with it's driver. or it cannot enable it's transmitter.

Avatar of jpattee

ASKER

Could you give the details of how to capture traffic from the air with another system running wireshark. I am not yet familiar with this network stuff.
ASKER CERTIFIED SOLUTION
Avatar of noci
noci

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jpattee

ASKER

For now, I guess I will have to Live with Linux wireless not working. I will check the firmware extraction programs and try them when there is an update. When I need the Internet I can switch to Windows or use the networks at school.

Since you spent quite a bit of time checking things I will give you most of the points. I appreciate the help.
jpattee, hi.

You may try another way to get it work.

1) Boot to Windows and get a DHCP address. Write it down.
2) Reboot to Linux and assign _the_ _same_ _static_ IP.

There where some firmware problems in Cisco WiFi routers and DHCP and this workaround would work.
Avatar of jpattee

ASKER

I tried this.

It connected to the network but then couldn't receive any data. It seemed to be the same problem as not receiving the IP address.