Can Anyone Explain the over-all view of Wireless Networking?
 

On Tuesday February 2 2010 3:21:33 pm Kent West wrote:
> Listening on LPF/wlan0/00:18:f8:29:b5:96
> Sending on LPF/wlan0/00:18:f8:29:b5:96
> Sending on Socket/fallback
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 20
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
> done.

Does your wireless network use static IP's, or does it use DHCP?

MM


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Can Anyone Explain the over-all view of Wireless Networking?
 

On Tue, 02 Feb 2010 14:03:56 -0600
Kent West <westk@acu.edu> wrote:

...

> Now I get no dhcp offers received. I don't understand how ifup/down and
> /etc/modules and udev and /etc/network/interfaces and "wpa-conf
> /etc/wpa_supplicant/wpa_supplicant.conf" and iwlist/spy/scan/whatever
> and eth0 vs wlan0 vs sit0 and auto eth1 vs allow-hotplug eth1 and wep vs
> wep-key vs open vs wpa, etc, all work together.

Basic idea:

1) Hardware support is required for the network card. If you're using
a stock kernel, it's probably there, with some caveats (e.g.,
firmware). In your case, see below.

2) Manually scanning for available networks (iwlist wlan0 scan) - this
is not generally required for routine operation, but is useful for new
locations, or for troubleshooting.

3) Associating the card with the wireless AP - done with 'iwconfig',
or the Debian way, via /etc/network/interfaces. This means that the
card is now 'connected' to the AP, and this sort of parallels the step
of plugging in a cable between a wired card and a switch. If
encryption is being used, you'll need to invoke wpa_supplicant, or some
other application that invokes it. Again, this can be done
via /etc/network/interfaces

4) Configuring IP on the card - you have to do this for wired or
wireless, and the procedure is identical. You can do this manually
(ifconfig wlan0 192.168.0.7) or via dhcp (dhcp wlan0), and once again,
there's the Debian way, via e.n.i.

It should be clear by now that e.n.i. is just a standardized Debian way
of invoking the manual procedures mentioned above. The ifupdown
scripts read the file, and invoke the various underlying commands
(ifconfig, iwconfig, wpa_supplicant) in the appropriate fashion.

> If I understood all that, I bet I could figure out how to get my
> wireless network working. However, I've been googling/studying off and

Of course you could!

> on for the past year, everytime I try to put Debian (or Ubuntu, or
> whatever) on a laptop that comes across my path (and failing pretty much
> every time on the wireless), but I've never found a site that actually
> has gotten me to an understanding of the process. Some sites talk about
> gui configuration clients I don't have, or compiling drivers manually
> which I don't need to do, or using ndiswrapper (?!), etc.
>
> Maybe the process is just WAY too complex to be explained for mere
> mortals who aren't in the mechanics of Linux networking on a daily basis.
>
> So if there's no good explanation out there, perhaps someone can just
> help me get it working, without me understanding what's going on. Here's
> some relevant information, I believe:
>
> 01:08.0 Network controller: Broadcom Corporation BCM4318 [AirForce One
> 54g] 802.11g Wireless LAN Controller (rev 02)

I have this same Broadcom chipset.

> Subsystem: Linksys WMP54GS version 1.1 [Wireless-G PCI Adapter]
> 802.11g w/SpeedBooster

Well, I certainly don't have this subsystem.

> 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: 64
> Interrupt: pin A routed to IRQ 17
> Region 0: Memory at feade000 (32-bit, non-prefetchable) [size=8K]
> Kernel driver in use: b43-pci-bridge
>
> westk@evoljasen:~$ sudo iwlist wlan0 scan
> wlan0 Scan completed :

Okay, so you have a bunch of cells with the same ESSID, but different
addresses. IIUC, that sounds like an enterprise setup, but it
shouldn't make a difference, or be a problem for us. Encryption is not
in use.

> westk@evoljasen:~$ cat /etc/network/interfaces

...

> auto wlan0
> iface wlan0 inet dhcp
> # wireless_essid humanslivehere
> wireless-essid ACUWireless open
> wireless-keymode open
> #wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

I'd leave the 'open' out of the wireless-essid line.

> (the wired interface works with the above setup. the wireless works at
> the other location (humanslivehere) when that line and the wpa-conf
> lines are uncommented and the other two uncommented lines are not in the
> file)
>
> westk@evoljasen:~$ cat /etc/wpa_supplicant/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=users
> #
> # humanslivehere
> network={
> ssid="humanslivehere"
> psk="it's a secret"
> }

wpa_supplicant (generally?) isn't relevant where encryption isn't in
use. It may be helpful for roaming, but shouldn't be necessary for a
basic connection.

> westk@evoljasen:~$ sudo iwspy
> lo Interface doesn't support wireless statistic collection
>
> eth1 Interface doesn't support wireless statistic collection
>
> wmaster0 Interface doesn't support wireless statistic collection
>
> wlan0 Interface doesn't support wireless statistic collection

You don't need to bother with this.

> westk@evoljasen:~$ sudo /etc/init.d/networking restart

You can also simply do 'ifup wlan0'.

...

> Listening on LPF/eth1/00:0d:56:2c:5e:d6

This is the networking subsystem activating eth1 (the wired interface).

> Sending on LPF/eth1/00:0d:56:2c:5e:d6
> Sending on Socket/fallback
> DHCPRELEASE on eth1 to 150.252.128.107 port 67
> There is already a pid file /var/run/dhclient.wlan0.pid with pid 18812
> killed old client process, removed PID file
> Internet Systems Consortium DHCP Client V3.1.3
> Copyright 2004-2009 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
>
> Listening on LPF/wlan0/00:18:f8:29:b5:96
> Sending on LPF/wlan0/00:18:f8:29:b5:96
> Sending on Socket/fallback
> DHCPRELEASE on wlan0 to 192.168.1.1 port 67
> send_packet: Network is unreachable
> send_packet: please consult README file regarding broadcast address.
> Internet Systems Consortium DHCP Client V3.1.3
> Copyright 2004-2009 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
>
> Listening on LPF/eth1/00:0d:56:2c:5e:d6
> Sending on LPF/eth1/00:0d:56:2c:5e:d6
> Sending on Socket/fallback
> DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 9
> DHCPOFFER from 150.252.8.1
> DHCPREQUEST on eth1 to 255.255.255.255 port 67
> DHCPACK from 150.252.46.1
> bound to 150.252.12.59 -- renewal in 79090 seconds.

Okay, so configuration of the wired interface is working fine.

> Internet Systems Consortium DHCP Client V3.1.3
> Copyright 2004-2009 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
>
> Listening on LPF/wlan0/00:18:f8:29:b5:96

This is the networking subsystem attempting to configure the wireless
interface.

> Sending on LPF/wlan0/00:18:f8:29:b5:96
> Sending on Socket/fallback
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.
> done.

It is failing. Now, IME, most such failures are due to the card not
being properly associated with the AP. You can determine this by
either looking at syslog, or by calling 'iwconfig wlan0'. If it's
properly associated, the first two lines should be something like this:

wlan0 IEEE 802.11bg ESSID:"nnnnnnn"
Mode:Managed Frequency:2.437 GHz Access Point: 12:34:56:78:99:aa

If it's not, you'll see something like this:

wlan0 IEEE 802.11bg ESSID:off/any
Mode:Managed Access Point: Not-Associated

Information in syslog will be helpful in determining the cause of failure.

Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Can Anyone Explain the over-all view of Wireless Networking?
 

Matthew Moore wrote:
> On Tuesday February 2 2010 3:21:33 pm Kent West wrote:
>
>> Listening on LPF/wlan0/00:18:f8:29:b5:96
>> Sending on LPF/wlan0/00:18:f8:29:b5:96
>> Sending on Socket/fallback
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 20
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
>> No DHCPOFFERS received.
>> No working leases in persistent database - sleeping.
>> done.
>>
>
> Does your wireless network use static IP's, or does it use DHCP?
>
> MM
>
>

DHCP


--
Kent West <*)))><
http://kentwest.blogspot.com
Praise Yah! o/



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Can Anyone Explain the over-all view of Wireless Networking?
 

Celejar wrote:
> This is the networking subsystem attempting to configure the wireless
> interface.
>
>
>> Sending on LPF/wlan0/00:18:f8:29:b5:96
>> Sending on Socket/fallback
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
>> No DHCPOFFERS received.
>> No working leases in persistent database - sleeping.
>> done.
>>
>
> It is failing. Now, IME, most such failures are due to the card not
> being properly associated with the AP. You can determine this by
> either looking at syslog, or by calling 'iwconfig wlan0'. If it's
> properly associated, the first two lines should be something like this:
>
> wlan0 IEEE 802.11bg ESSID:"nnnnnnn"
> Mode:Managed Frequency:2.437 GHz Access Point: 12:34:56:78:99:aa
>
> If it's not, you'll see something like this:
>
> wlan0 IEEE 802.11bg ESSID:off/any
> Mode:Managed Access Point: Not-Associated
>
> Information in syslog will be helpful in determining the cause of failure.
>
Stuff like this in dmesg:

status=10 aid=0)
[ 575.125696] wlan0: AP denied association (code=10)
[ 575.321089] wlan0: association with AP 00:0b:86:bb:83:40 timed out
[ 594.893308] wlan0: deauthenticated (Reason: 1)
[ 652.178643] wlan0: direct probe to AP 00:0b:86:bb:83:40 try 1



But, I gave up on it for now, having to move the machine back to its
original location, where when I set things back to the way they were
before I replaced the box around the hard drive, the wireless network
worked perfectly first time booting. So it must have something to do
with the ACUWireless network rejecting my system somehow.

I thought I was through with the machine, but I may have to bring it
back up to the ACUWireless network, so I might get to play with it some
more. The freeze/lock-ups I've mentioned are apparently not related to
the wireless setup, but to a more generalized flakiness in the box
itself. I ran memtest86+ (interestingly, memtest86 just rebooted the
machine everytime), and it didn't find any errors after about an hour's
worth of testing, but after about three minutes of me playing around in
memtest86+'s configuration screens, the machine froze (well, the
keyboard froze - previously freezings allowed the mouse cursor to move,
but not to click, and the keyboard also was frozen). Since memtest86+ is
just a simple app running directly on the hardware just after the
BIOS/POST (i.e., it's it's own mini-OS), that tells me the freezes are
definitely hardware-related. I'll swap the RAM sticks around a bit,
maybe play with the BIOS settings, but I think the mobo is probably
flakey, and I'll have to find yet another computer to replace this one; arg!

Thanks for all the help, folks! I'm still no where close to seeing the
big picture of how all the components of networking fit together, but
I'm a little less in the dark than I was. I appreciate it!

--
Kent West <*)))><
http://kentwest.blogspot.com
Praise Yah! o/



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Can Anyone Explain the over-all view of Wireless Networking?
 

Kent West:
>
> westk@evoljasen:~$ dmesg | grep wlan
-- snip
> [ 267.697118] wlan0: AP denied association (code=10)

Well, there you have it. The access point does not want to talk to you.
You said it works using the same card in a different machine? -Otherwise
I would suspect the access points have MAC filtering enabled and you
need to talk to your wireless provider in order to have your card
whitelisted.

What I find a little bit strange is that the card always tries to
associate with the same AP. You could try using another one from the
list provided by running 'iwlist wlan0 scan'. Get the address from one
AP with a high quality and set it manually by running 'iwconfig wlan0 ap
<hex-address-of-ap>'.

J.
--
After the millenium I would tell lies only to those who deserved them.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>

Can Anyone Explain the over-all view of Wireless Networking?
 

On Wed, Feb 03, 2010 at 12:44:45AM -0600, Kent West wrote:
> Celejar wrote:
> > This is the networking subsystem attempting to configure the wireless
> > interface.
> >
> >
> >> Sending on LPF/wlan0/00:18:f8:29:b5:96
> >> Sending on Socket/fallback
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
> >> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
> >> No DHCPOFFERS received.
> >> No working leases in persistent database - sleeping.
> >> done.
> >>
> >
> > It is failing. Now, IME, most such failures are due to the card not
> > being properly associated with the AP. You can determine this by
> > either looking at syslog, or by calling 'iwconfig wlan0'. If it's
> > properly associated, the first two lines should be something like this:
> >
> > wlan0 IEEE 802.11bg ESSID:"nnnnnnn"
> > Mode:Managed Frequency:2.437 GHz Access Point: 12:34:56:78:99:aa
> >
> > If it's not, you'll see something like this:
> >
> > wlan0 IEEE 802.11bg ESSID:off/any
> > Mode:Managed Access Point: Not-Associated
> >
> > Information in syslog will be helpful in determining the cause of failure.
> >
> Stuff like this in dmesg:
>
> status=10 aid=0)
> [ 575.125696] wlan0: AP denied association (code=10)
> [ 575.321089] wlan0: association with AP 00:0b:86:bb:83:40 timed out
> [ 594.893308] wlan0: deauthenticated (Reason: 1)
> [ 652.178643] wlan0: direct probe to AP 00:0b:86:bb:83:40 try 1
>

I have seen this exact behavior at my uni. The wireless tools are
picking, generally, the AP with the strongest signal and trying to
associate with it. But that AP denies association for whatever reason
(too busy perhaps), but the tools aren't smart enough to realize this
and move on to the next AP and try associating.

My solution, for quite a while, was repeated issuances of:

sudo iwconfig wlan0 ap off

while watching a syslog tail. Then I would see it finally associate
and *hopefully* do it before dhclient times out.

In my experience, this means that your wireless is essentially working
correctly, but is just not getting association with a free AP. Around
my school, this behavior is correlated with the number of running
laptops in the vicinity. For example, over in the liberal arts areas,
there are relatively few laptops and the AP's are generally
available. I can associate on the first or second try. Meanwhile in
the CS and engineering areas, laptops proliferate like bunnies and it
can take several attempts to get association.


[...]

> I thought I was through with the machine, but I may have to bring it
> back up to the ACUWireless network, so I might get to play with it some
> more.

I finally installed wicd and it is sophisticated enough to handle this
situation. Now my wireless just works. It can be slow to come alive if
there is a lot of traffic around, but it still gets me connected with
no fiddling on my part.

very much my .02

A

Can Anyone Explain the over-all view of Wireless Networking?
 

On Tue, Feb 02, 2010 at 04:04:54PM -0600, Kent West wrote:

[...]

>
> After a couple of reboots, and after running wicd-client from the actual
> machine instead of over ssh, the machine did not lock up; it did see the
> various ACUWireless networks, but when I tried clicking on the first
> one, it thought for a minute or two, then reported "Connection failed:
> Unable to get IP Address".

in the properties of the "ACUWireless" network (in wicd's interface)
there is a check box for "treat all networks with this name the same
way" or something to that effect. Select that box and then it will
automatically work it's way through the list of available APs
attempting to connect until it finally works.

A