[TAG] LG 127 Wifi

[Benjamin A. Okopnik]

On Sat, Aug 05, 2006 at 11:58:29PM -0600, jeff at jeffroot.us wrote:
> 
>   So this is exactly the sort of info I'm looking for: where do I look
>   to see what's going on?  I just checked /var/log/daemon.log and
>   found a set of "No DHCPOFFERS recieved".

Just for future reference, Jeff - and a bit of knowledge that I hope
will propagate into our readership as well - here is a cardinal rule of
error reporting: never retype, always copy-and-paste. Given that this
error is your interface with the problem, you need to report it as
exactly as possible, and retyping introduces possible transmission
errors.
 
>   So, I guess the way to approach this is to walk up the stack.

Didn't you say that you were able to connect with other networks? That
should eliminate the link, the network, and the transport layers...
well, it may be worthwhile to take a look at the mode in which the card
is "listening" versus the one that the AP is using - the AP could be
using, say, mode B while your card is only set for A.

>   I stripped my /etc/network/interfaces pretty much down to your
>   minimum version:
> 
>     iface wlan0 inet dhcp
> 	wireless-mode managed

Out of curiosity, what does "iwpriv wlan0 get_mode" return for you?
Mine, since I set it explicitly, says just what I'd expect:

``
ben at Fenrir:~$ iwpriv wlan0 get_mode
wlan0     get_mode:802.11bg (6)
''

Check the AP mode as well.

>   From here, I can run Kismet and see the "OldTownWifi" network, but
>   I'm not that sure I understand what Kismet is telling me.

So what is it telling you? Maybe one of us could interpret it.

>   Some
>   networks list an "IP range", but most don't.
> 
>   So, I run "iwconfig wlan0 essid OldTownWifi", and I now have wlan0
>   in both iwconfig and ifconfig.  But, understandably, the ifconfig
>   stanza is not showing an IP address for the interface.

Right - no negotiation has happened yet.
 
>   I made a few stabs at dhclient, and see nothing but the
>   aforementioned "No DHCPOFFERS" messages.

Is there a way to make its reporting more verbose? 'pump', by contrast,
is very "talky" in the logs - I like it that way, actually.
 
>   I _did_ see the 'pump' references and installed it, but since there
>   are no (intentionally) open AP's within range I could not test it.

Do make sure to uninstall 'dhclient' so you can test properly - you
don't want those two contending for top spot (in the case of
'ifup/ifdown', 'dhclient' has a higher precedence than 'pump' and will
be used if both are installed.)
 
>   The best I could do was to use my Netgear MR814v2 router as a dummy
>   network.  I hooked it into my Dell's ethernet port and set it as an
>   open AP.  Setting the 'interfaces' stanza to:
> 
>    iface wlan0 inet dhcp
> 	wireless-essid any
> 	wireless-mode managed
> 
>   seems to work magic.  Now when I push the card into its slot, the
>   frelling thing just pops up with an IP and essid set!

Just as it should. :)
 
>   > I never have to set the ESSID
> 
>   Really?  I assumed the essid was necessary before you could talk to
>   the AP; does pump configure this for you?

Yes.

>   And since Kismet is
>   showing me several apparently open AP's; how would you know which
>   one you're on?

I was curious about this in the past, and did a little experimenting; it
seems that, by default, it latches onto the one with the lowest channel
number - unless you preset the channel to something different.

In fact, now that I recall it, I have a somewhat amusing story related
to this. I was in a hotel room in Atlanta with my then-girlfriend (now
my wife) Kat; the hotel offered wireless access. I turned on my Linux
laptop, typed 'ifup wlan0', and was off and running - but Kat simply
couldn't get on the network with her Wind0ws machine. I poked it with a
long stick, then examined the situation from my laptop - and saw that
their AP was broadcasting on two channels. A little more investigation
showed that you could *connect* to the first one, but it wouldn't do you
any good: "there was no 'there' there." In other words, the radio link
worked fine, but the network side was down. The second channel worked
fine... but since it was a different channel on the same AP, Windows
just blithely latched on to the first available channel - *and there was
no way to change it.* I'd tried, using everything from searching the Net
to twiddling nearly random registry keys; it was useless.

The hotel's network tech recommended - ready for this? - taking the
laptop all the way to the end of the hall, where channel 1 might
possibly be a little too weak to reach, and _then_ try connecting.
Believe it or not, it worked. Kat could then walk back to the room and
happily browse away.

Not quite defenestration, but close...

'pump', as I'd mentioned before, just did The Right Thing. I don't
recall what the log said, but it had tried channel 1, found that it
couldn't connect, dropped it, and quietly jumped to channel two without
bothering me about it. Which is, if you think about it, the Robustness
Principle up close and in person - exactly how it should work.

>  (I seem to recall something about ghost AP's at
>   coffee shops being a security risk; is this what happens?  You
>   connect to something without knowing what you're really connecting
>   to?)

It could indeed happen, but it's not a question that's likely to matter
for the way I use my computer on wireless networks. I'm certainly not
going to send, e.g., my bank statement to some wireless printer at some
random coffee shop...
 
>   I saw the essid set with my dummy configuration, but I tried not to
>   draw too many conclusions from that setup.  BTW, both pump and
>   dchpclient3 seem to work fine for this lashup.
> 
>   So, where next?  I figure on trying again with pump installed and
>   using the above config.  But what to check?  tail -f
>   /var/log/daemon.log?  Anything else worth monitoring while I
>   experiment?

I'd say that the first thing to do is actually test it. If it fails, the
first place I'd go is '/var/log/daemon.log' and copy-and-paste the
results into an email back to this list. If you're feeling energetic,
then fire up some sort of a network traffic dumper - say, 'tcpdump -i
all' - and grab everything relevant from the first DHCP request until
the attempt fails. Send that as well.
 
But do hope for the best. :)

>   (I'm not sure I'll get back downtown until Monday.  This debug may
>   proceed in burst mode.  Unless it just works with pump...)

That's the thing to hope for!
 

* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *