Wireless connection woes.

Hi folks,

as I do a lot of traveling, I depend on wireless access from my laptop.
However, wireless access gives me a headache, even though the chip set
(the intel 3945) is well-supported. I'm not even clear that the driver
is faulty here, but let me explain:

Here in the hotel I'm currently staying, free wireless access is
provided. The access points are visible if I do an "iwlist eth1
scanning", though I cannot connect. Gnome's network manager applet
keeps going and going, but nothing happens, until it finally gives up.

The following however, does allow me to connect: ("A bad hack")

a) First configure the channel manually. (iwconfig eth1 channel xx) to
the strongest access point (why doesn't pick it the best channel in
first place?). All access points have the same essid, but use different
channels and provide varying quality, dependent on the room where they
are mounted.

b) Set the mode to "ad-hoc" (even though the access points are run in
the managed mode). I've no idea why this step is a good thing to do, or
why it works at all, but it doesn't go without it, no chance.

c) Try to connect to the access point again.

This will give me fine access, i.e. DHCP and so on works great.

Needless to say, access works flawless with the operating system from
Redmond.

The problem appears, as said, with the intel 3945 chipset, and the
ipw3945 driver. The free (or "more free") iwl3945 is even messier that
I cannot even try to reconnect once the connection failed, i.e. if the
first attempt to establish a connection fails, there is no second
attempt I have - I need to reboot the machine. The ipw driver is the
1.2.2 release, the iwl is the one that comes with the 2.6.24.2. (That
said, I cannot recommend the iwl module at all, sorry.)

I'm not even sure that this is a problem with the driver - it might be a
problem with an intermediate layer.

What else can I do to get the problem fixed? (Actually, I finally hoped
that with a new laptop and a well-supported chip set wireless problems
would be gone, but, as ever, linux plus wireless = headaches. Sigh)

Any pointers???

So long,
Thomas

> a) First configure the channel manually.[color=blue]
> b) Set the mode to "ad-hoc"
> c) Try to connect to the access point again.[/color]

I don't know if it's the driver or if it's dhcpcd / dhclient3. There's a
number of sites where I have to set the mode, rate, essid, key, and channel
before dhclient3 works for me. Using a BCM4318 chipset and ndiswrapper.
Although there are other locations where dhclient3 works out of the box,
no prep work involved. So it may not be anything linux related. Just (as
windows would say) lazy admins that never upgraded.

But once connected it works flawlessly and much faster than that redmond
OS. In the sense that there's no needless netbeui packets, windows update
packets, and whatever worm/virus of the month spewing packets out to where
ever. Just watch the internal interface with tcpdump on a linux router
connected to the internet and you'll see what I mean. Only connected to a
linux machine and all's quiet on the western front. Connect a windows
machine and golly, no wonder we need gigabit network adapters these days.

Thomas Richter wrote:
[color=blue]
> The following however, does allow me to connect: ("A bad hack")
>
> a) First configure the channel manually. (iwconfig eth1 channel xx) to
> the strongest access point (why doesn't pick it the best channel in
> first place?). All access points have the same essid, but use different
> channels and provide varying quality, dependent on the room where they
> are mounted.
>
> b) Set the mode to "ad-hoc" (even though the access points are run in
> the managed mode). I've no idea why this step is a good thing to do, or
> why it works at all, but it doesn't go without it, no chance.
>
> c) Try to connect to the access point again.
>
> This will give me fine access, i.e. DHCP and so on works great.[/color]

Update to this: I'm now in a different hotel (again), and it's exactly
the same mess. This is not an isolated problem (and it's a different
brand of broadband access, and a different hotel chain).

So long,
Thomas

Thomas Richter <thor@math.tu-berlin.de> writes:
[color=blue]
> Thomas Richter wrote:
>[color=green]
>> The following however, does allow me to connect: ("A bad hack")
>> a) First configure the channel manually. (iwconfig eth1 channel xx)
>> to the strongest access point (why doesn't pick it the best channel
>> in first place?). All access points have the same essid, but use
>> different channels and provide varying quality, dependent on the
>> room where they are mounted.
>> b) Set the mode to "ad-hoc" (even though the access points are run
>> in the managed mode). I've no idea why this step is a good thing to
>> do, or why it works at all, but it doesn't go without it, no chance.
>> c) Try to connect to the access point again.
>> This will give me fine access, i.e. DHCP and so on works great.[/color]
>
> Update to this: I'm now in a different hotel (again), and it's exactly
> the same mess. This is not an isolated problem (and it's a different
> brand of broadband access, and a different hotel chain).
>
> So long,
> Thomas[/color]

Sometimes, I get into the same trouble. At my faculty, there's a
wireless network everywhere in the campus, with internet connection. But
in some parts of the campus, I have to wait minutes before having any
internet access. I've experienced this in two places. In one it was just
once, but in the other, it happens every time I try to connect to the
internet there. Eventually, it will get connected. Probably it will get
disconnected a few seconds or minutes later.

I've never been able to fix this issue, but I've done no debug on this.

It's a laptop running Gentoo GNU/Linux, and it's configured to use
wpa_supplicant. Wireless is provided by an Atheros chipset based PCMCIA
card. (Which involves some piece of proprietary binary code tainting the
kernel, so I'd also consider blaming that piece in my case.)

Never tested it with a Redmond OS, as my laptop doesn't run one.

If someday I get into one of those places again, I'll try to do those
steps (just adding the part which is needed to use wpa) to see if it
fixes the issue.

--
Nuno J. Silva (aka njsg)
LEIC student at Instituto Superior Técnico
Lisbon, Portugal
Homepage: [url]http://njsg.no.sapo.pt/[/url]
Gopherspace: [url]gopher://sdf-eu.org/11/users/njsg[/url]
Registered Linux User #402207 - [url]http://counter.li.org[/url]

-=-=-
``I'd love to go out with you, but my favorite commercial is on TV.''

> If someday I get into one of those places again, I'll try to do those[color=blue]
> steps (just adding the part which is needed to use wpa) to see if it
> fixes the issue.[/color]

I have WPA installed on this laptop now (and have no ideal if and how it
works). Even though I have to setup mode, rate, essid, key, channel, mtu,
and sometimes IP (local library). I still consider that better than
having to hack the windows registry to change the MTU size. (and do so
differently between different OS versions and interfaces). Even though
iwconfig and ifconfig get worked to prep dhclient3 I still consider that
better IMO. By no means perfect, but neither is that other thing.

Thomas Richter wrote:[color=blue]
> Thomas Richter wrote:
>[color=green]
>> The following however, does allow me to connect: ("A bad hack")
>>
>> a) First configure the channel manually. (iwconfig eth1 channel xx) to
>> the strongest access point (why doesn't pick it the best channel in
>> first place?). All access points have the same essid, but use
>> different channels and provide varying quality, dependent on the room
>> where they are mounted.
>>
>> b) Set the mode to "ad-hoc" (even though the access points are run in
>> the managed mode). I've no idea why this step is a good thing to do,
>> or why it works at all, but it doesn't go without it, no chance.
>>
>> c) Try to connect to the access point again.
>>
>> This will give me fine access, i.e. DHCP and so on works great.[/color]
>
> Update to this: I'm now in a different hotel (again), and it's exactly
> the same mess. This is not an isolated problem (and it's a different
> brand of broadband access, and a different hotel chain).[/color]

Update to the update: Could it possibly be that the problem appears if
two separate networks send on the same channel? I have the impression
(but this is just a suspicion, I've no evidence) that the machine tries
to speak to the wrong router?

I'd love to help to improve the wlan stack by providing any debug data
to narrow the problem, but what would I need to collect?

The "older" laptop had an orinoco chipset, this one comes with the intel
ipw3945, but the problems were the same. No wireless access in public
places (i.e. I only get wireless when I don't need it anyhow because I
would have cable access in first place).

So long,
Thomas

> No wireless access in public places

Well, I get wireless access in public places. It just takes a bit of
effort to make the connection. Upwards of ten minutes in some cases where
quality is 10/100-ish. And waiting for dhclient3 to timeout several
times. I've actually scripted a couple of the places where I connect
often.

# McDonalds
# although they don't appear to be connected to the internet yet.

DHCP_CHANNEL=1
DHCP_RATE=11
DHCP_KEY=off
DHCP_MODE=Managed
DHCP_ESSID=Wayport_Access
wireless_interface=wlan0

iwconfig $wireless_interface essid $DHCP_ESSID
iwconfig $wireless_interface mode $DHCP_MODE
iwconfig $wireless_interface key $DHCP_KEY
iwconfig $wireless_interface channel $DHCP_CHANNEL
dhclient3 $wireless_interface -s $DHCP_ESSID

# end

Shadow_7 wrote:[color=blue][color=green]
>> No wireless access in public places[/color]
>
> Well, I get wireless access in public places. It just takes a bit of
> effort to make the connection. Upwards of ten minutes in some cases where
> quality is 10/100-ish. And waiting for dhclient3 to timeout several
> times. I've actually scripted a couple of the places where I connect
> often.[/color]

The connection is here 50/100, actually using the same provider
("Wayport"). Still, a no-go unless you fiddle with the connection
yourself, i.e. you do have to first set the mode to "ad-hoc", then do an
"iwlist" on the device, and then it works.

I don't think this is the result of a bad connection - looks like
something else is broken.
[color=blue]
> DHCP_CHANNEL=1
> DHCP_RATE=11
> DHCP_KEY=off
> DHCP_MODE=Managed
> DHCP_ESSID=Wayport_Access
> wireless_interface=wlan0
>
> iwconfig $wireless_interface essid $DHCP_ESSID
> iwconfig $wireless_interface mode $DHCP_MODE
> iwconfig $wireless_interface key $DHCP_KEY[/color]

What does this do (iwconfig key)?
[color=blue]
> iwconfig $wireless_interface channel $DHCP_CHANNEL
> dhclient3 $wireless_interface -s $DHCP_ESSID[/color]

So long,
Thomas

> The connection is here 50/100, actually using the same provider[color=blue]
> ("Wayport").[/color]

Fiddling is fine IMO. Although you have to be root or otherwise have
admin priviledges for the network settings. Definitely not ideal for most
lowly users.
[color=blue]
> I don't think this is the result of a bad connection - looks like
> something else is broken.[/color]

The below are variables that contain pre-determined parameters based on
what I know about that access point. As for-told by the all mighty iwlist.
[color=blue][color=green]
>> DHCP_CHANNEL=1
>> DHCP_RATE=11
>> DHCP_KEY=off
>> DHCP_MODE=Managed
>> DHCP_ESSID=Wayport_Access
>> wireless_interface=wlan0[/color][/color]

[color=blue]
> What does this do (iwconfig key)?[/color]

iwconfig wlan0 key off

I use wep at home, so making sure things line up with what iwlist tells me
about the connection I'm trying to make. aka Encryption: off

for that specific location without the dynamic variables:

iwconfig wlan0 essid "Wayport_Access"
iwconfig wlan0 key off
iwconfig wlan0 mode "Managed"
iwconfig wlan0 channel 1
iwconfig wlan0 rate 11
dhclient3 wlan0 -s "Wayport_Access"

Generally I need Mode, and Channel(texas rest stops). For older 802.11b I
also need rate(diamond jacks, bosier city, LA). And for some I need the
essid matched. Although dhclient3 wlan0 -s "essid" might aid that
dependancy. Or at least make it timeout quicker when in the presence of a
dozen or more essid's. (like the bank, a few blocks away from the library)

Most of the extra stuff is just to ensure I don't have to revisit any
missed parameters after dhclient3 timed out.

HTH

Shadow_7 <wwwShadow7@NOSPAMyahoo.comNOSPAM> writes:
[color=blue]
> I don't know if it's the driver or if it's dhcpcd / dhclient3. There's a
> number of sites where I have to set the mode, rate, essid, key, and channel
> before dhclient3 works for me.[/color]

Isn't that the way it's always done? Who sets all that, if not you?
[color=blue]
> But once connected it works flawlessly and much faster than that redmond
> OS. In the sense that there's no needless netbeui packets, windows update
> packets, and whatever worm/virus of the month spewing packets out to where
> ever. Just watch the internal interface with tcpdump on a linux router
> connected to the internet and you'll see what I mean.[/color]

So true. Found that out when I connected a friend's Windows laptop to
my network.

--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
[url]http://www.theregister.co.uk/2008/01/27/bush_nsa_internal/[/url]
[url]http://www.wired.com/politics/security/news/2007/08/wiretap[/url]
[url]http://www.hermes-press.com/police_state.htm[/url]
[url]http://www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597[/url]

Thomas Richter wrote:
[color=blue]
> Any pointers???[/color]

This can happen if wpa_supplicant is running in parallel.

Technically it's not even possible to select a channel in managed
mode, the channel is selected automatically to the AP. To select
a specific access point you use the iwconfig option "ap" with
the access point's address. My best guess is, that switching
into ad-hoc mode and back to managed resets the hardware/driver.
This can also be done using the iwpriv tool.

Wolfgang Draxinger
--
E-Mail address works, Jabber: [email]hexarith@jabber.org[/email], ICQ: 134682867