I recently wrote about my iwl3945 problems - I usually
have to try 20-50 times before I can use a wep-encrypted access point.
Once the link goes up - no more problems. But getting the first
connection takes time.
Yesterday something weird happened.
I run the same iwconfig command over and over. Then a wild guess:
Perhaps the driver or linux is clever enough to see that I
just set the same essid and key as last time, and optimize the
operation away completely? I have no idea if this actually happens,
but I changed the essid (added a few garbage characters)
in order to force a difference. I was about to run iwconfig again
with the correct essid, when I noticed that the link was up!
An "iwconfig" without parameters showed that the PC indeed
had associated to the usual access point, and the essid was wrong one
indeed.
I then ran "dhclient", got an IP address, and used my home network
for a few hours. No problems, but the essid was wrong all the time.
I thought this ought to be impossible - so I can only guess that
the essid is stored in several places - one place used by "iwconfig"
to display the current essid, and somewhere else used to program
the radio. And the latter place is not necessarily updated when
"iwconfig essid <something>" is run - and therefore the link
worked anyway. This could possibly explain why things fail
so much - perhaps the essid is set correctly only occationally?
Kernel: 2.6.25-rc3, SMP 64-bit. Other sw from debian testing.
Helge Hafting
Anders Eriksson wrote:
>> I recently wrote about my iwl3945 problems - I usually
>> have to try 20-50 times before I can use a wep-encrypted access point.
>> Once the link goes up - no more problems. But getting the first
>> connection takes time.
>>
>
> I can testify that I have the same issue with w2k. I'm not sure how intel
> wired up their drivers package, but I usually have to wait about 1-2 minutes
> to get _any_ package back from the AP (judging from the network icon). Once I
> get the first package back (I'd guess it's a dhcp resp), i can start using the
> network.
>
The linux driver (with the siwessid/siwencode patch) is better than that
now.
It may connect at first try, always at the second or third try. 3 tries only
takes a few seconds. So it is possible to get this right. Hopefully it
can be fixed
further, to always work at first try.
Helge Hafting
> I recently wrote about my iwl3945 problems - I usually
> have to try 20-50 times before I can use a wep-encrypted access point.
> Once the link goes up - no more problems. But getting the first
> connection takes time.
I can testify that I have the same issue with w2k. I'm not sure how intel
wired up their drivers package, but I usually have to wait about 1-2 minutes
to get _any_ package back from the AP (judging from the network icon). Once I
get the first package back (I'd guess it's a dhcp resp), i can start using the
network.
I once picked up somehwere that this wa an issue with wither this intel chip
of the broadcom chip I have in the Linksys AP. Either one of them was picky
on the nitial handshake and the speed/rate used for that handshake. Waiting a
while both ends agree to do it at 1Mbps or something and it all works from
there.
hth,
/Anders
On Wed, Mar 5, 2008 at 2:15 PM, Helge Hafting
<[email protected]> wrote:
> I recently wrote about my iwl3945 problems - I usually
> have to try 20-50 times before I can use a wep-encrypted access point.
> Once the link goes up - no more problems. But getting the first
> connection takes time.
>
> Yesterday something weird happened.
> I run the same iwconfig command over and over. Then a wild guess:
> Perhaps the driver or linux is clever enough to see that I
> just set the same essid and key as last time, and optimize the
> operation away completely? I have no idea if this actually happens,
> but I changed the essid (added a few garbage characters)
> in order to force a difference. I was about to run iwconfig again
> with the correct essid, when I noticed that the link was up!
>
> An "iwconfig" without parameters showed that the PC indeed
> had associated to the usual access point, and the essid was wrong one
> indeed.
> I then ran "dhclient", got an IP address, and used my home network
> for a few hours. No problems, but the essid was wrong all the time.
>
> I thought this ought to be impossible - so I can only guess that
> the essid is stored in several places - one place used by "iwconfig"
> to display the current essid, and somewhere else used to program
> the radio. And the latter place is not necessarily updated when
> "iwconfig essid <something>" is run - and therefore the link
> worked anyway. This could possibly explain why things fail
> so much - perhaps the essid is set correctly only occationally?
>
> Kernel: 2.6.25-rc3, SMP 64-bit. Other sw from debian testing.
>
> Helge Hafting
I've seen some problems with avahi-daemon intercepting wrong SSID
during association
I didn't root caused the problem yet. I'm using Fedora 8 now.
When I've commented the auto selection out
(IEEE80211_STA_AUTO_SSID_SEL) it performed better
Yet I also didin't root caused the problem yet.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>