rt2x00.serialmonkey.com

This is because I have defined a special host-name in my system. Normaly, the dhcp-server should be able to accept the request from the client and advice the client to use the hostname requested.
But actually dhclient doesn't do this for me. The hostname always turns to "noname" instead. This only works for me with dhcpcd. This is why I canged the programs for establishing the connection.
I already made a bug-entry some time ago for this:
http://marc.theaimsgroup.com/?l=dhcp-cl ... 126489&w=2
But still this wasn't fixed from the dhclient-guys.

So this is more or less jut a cosmetic issue, because I get a connection with both solutions - to answer the question about to try out a new script with dhclient.


My AP is a all-in-one solution to go into internet: it's a DSL-modem, AP and DHCP-Server in one box!


Well, I thought things are going this way, aren't they?
Otherwise I needn't the dhclient/dhcpcd - commands...

So if I say I can reach "google", I can go into Internet. But Google unfortunately seems to be just a exeption - most of other sites fail when loading. I thought that this could have something to do with the amount of data to be transmitted?!?!?
Also, I'm unable to reach my FritzBox in WPA-mode...


If I can help you / you can help me this way - of course!.
But I will do that tomorrow, today's already late in the evening.
As I can not reach my FritzBox any more later when switching to WPA-mode, it's a little time-consumting to get my FritzBox "back to life" with all these cables...

Thank you for your fast reply!!!

O.k. - here we go again,

I've downladed a fresh CVS-driver and applied the new patch (I hope I did it).

Hi MadMax,

No solution yet, but I wanted to provide a short status report before you're left swaying in the breeze entirely too long.

The patch looks like it did exactly what it was intended to do.

What it shows is that the AP has sent two extra bytes of zeroes tacked on to the end of the WPA1 IE it sends as part of its beacon frame. Technically, it shouldn't be doing that, but, on the other hand, it doesn't seem to be doing any harm, and the rest of the content conforms to the standard. So the "Invalid WPA IE" hypothesis can be trashed alongside the "Corrupted EAPOL Data" hypothesis.

What I'm looking at now is along the lines of your references to graphics data in your previous posts. There's nothing special about graphics data per se, but there is often a lot of it. So I'm looking into how to see if there are any corner cases with respect to packet data size and send rate.

As soon as I have something ready to go, I'll upload it here, and ask you to test it if you're still interested.

Thanks for the hard work,

Hmm, bad luck for me!

I stay tuned and of course I'm willing to test other patches if ready - I want to have this fixed!

Thanks for your efforts!

Hi MadMax,

Yet another patch - this time to see the effect of the large volumes of data implied by your references to graphics data in previous posts.

It is intended to show the format of transmit skbs as they are passed down to the driver, and the format of receive skbs as they are reported up the network stack, with the intent of finding out if any "nonlinear" skbs are ever used, and if so, the results.

I've uploaded it here as skbl.patch.gz. As before, the previous patch should be discarded, and this patch applied to a vanilla version of the latest CVS. The modified files are rtmp_data.c and rtmp_main.c

---------------------------------------------------------------------
rtmp_data.c
===========
RTMPHandleDecryptionDoneInterrupt()
Instrument to show skb configuration as sent up to netif_rx().

RTMPSendPacket()
Instrument to show total and paged data lengths when called.

rtmp_main.c
===========
RTMPSendPackets()
Instrument to show total and paged data lengths when called.
---------------------------------------------------------------------

If you're still game to continue, please post a log of your results here, and I'll take a look at it. (BTW, no need to wrap a single file inside a tarball; just the gzipped file itself is OK.)

Once again, thanks for slogging through all this,

3rd patch applied - see attachement.


I know, but it's just a habbit to use GUI-programs instead of console as much as possible - therefore I use Krusader to GZIP and do all the file-copy-stuff. Unfortunately Krusader only knows .tar.gz or .tar.bz2 for compressing...

Hope you can spot the problem now....

What I did after establishing WPA-connection:
1. http://www.google.de - o.k.
2. search for "testing ralink" o.k.
3. Try to reach the Web-Interface of my FRITZ!Box http://fritz.box/

After step 3.) there was the break-down of the network - as usual...

Hi MadMax,

First, one observation: On your post of Sat 9/9/06 you wrote:

This may have been because you were still using a RT2500STA.dat file, which is read in as part of the "ifconfig ra0 up" processing. As long as that file is deleted, there should be no problem with the script I proposed. If it does exist, then the entire script (except the 'iwconfig ra0 up' part) should be repeated after issuing the ifup command.

The "ifconfig ra0 essid ..." command really does have to be the last one issued (cf. examples in iwpriv_usage.txt) because the driver starts the association process when it gets it. If you've previously issued - say - an authentication type command, and subsequently issue a command to set a key value, the association may be initiated with an inconsistent set of parameters. This may cause, as they say, indeterminate behavior.

In a previous post, I said I considered the fact that issuing the "iwconfig essid" command starts the association process to be a bug; but it turns out that the Ralink folks were just implementing the M$ NDIS spec. This conflicts with the iwconfig man page, which states that issuing "iwconfig <interface> ap <mac-addr>" causes the card to "register" to the AP. (The order of parameters in the RT2500STA.dat file doesn't matter, since the driver reads the whole thing before starting to do anything.) So the approach the driver takes by starting the association process on the receipt of either command is probably as good as any.

Looking at your latest log, there's not a particularly large amount of traffic, and the data items printed out by the patch look OK.

I have five questions:

1. When the problem occurs, what is your procedure to be able to get to http://www.google.de/ again and also search for some things?

2. What are you trying to do at the AP? Do you get a window display on your browser?

3. What happens if you *never* try to access the web interface of your AP over you wireless link? Can you do everything else OK? For as long as you wish?

4. What happens if you try to access your AP's web interface over the Ethernet wire?

5. Have you tried accessing that AP using different wireless equipment? If so, what was the result?

No, as I wrote somewhere before, I've definetly deleted this file! Just have some backups when I tried out the RaConfig-Tool one time:


As you can see, the file RT2500STA.dat doesn't exist, and as posted before the script in new order doesn't work for me!!! This is why I kept the old one.
Look at my log-file:

I don't understand most of the log - but this means for me that your theory that the file is still there can't be correct.


And one more thing to mention - in the past I also got disconnected trying to reach the internet when using the RaConfig-Tool instead of my script!!!


This is difficult to answer - sometimes it works, sometimes it doesn't. With the last log-file it didn't work - so no site was reachable anymore.


http://fritz.box is just the start-screen of the web-interface - and yes, I normaly should get a screen on my browser if I type in the adress.
I can configure the hole internet-things with it - encryption-type (open, WEP, WPA), setup of my provider-properties, open ports for file-sharing, etc...


No, as written somewhere above - I can not reach most of the internet-pages around - google is just one of a handfull of exeptions.


This is how I get my AP back to life - and switch to WEP-encryption again. Everything works fine with eth1, also with WEP-encryption: no problems!


I can not call too much hardware my own - I only have a WLAN-USB-adaptor which only runs with ndiswrapper. But this didn't work very well for me (system freezes from time to time) - and I never tried out WPA with this adaptor.
This is why I bought a PCI-card with rt2500-chip - because I thought I would have perfect support under Linux.


Maybe this is because there won't be much traffic because the transfer breaks!
I can wait minutes after minutes and don't get the start screen of the web-interface! And of cource the traffic produced from a web-interface shouldn't be so much... but it seems to be enough to blow my connection.

Hi MadMax,

First, thanks for the answers.

After you use the Ethernet link to set up your AP for WEP, which link (Ethernet or Wireless) are you using when you try to set up WPA and TKIP?

Hmm, I don't really understand your question.

Normally it shouldn't make a difference how to be connected to my DSL-modem. With my modem I have these options
* ethernet
* USB (not for Linux, because you need a driver for it which only exists for Windows)
* WLAN (no encryption, WEP, WPA, WPA2)

My computer has ethernet and I have the PCI-card with rt2500-chip. As written above, USB doesn't work under Linux.

So normally I choose WLAN with WEP, because WPA doesn't work for me in the moment. I'm writing these lines via WLAN and WEP-encryption over the rt2500-chipset.
With this it's also possible to switch to WPA-mode. After that of course I loose connection, because the computer is still set up for WEP.
If I would be able to establish a WPA-connection I also could switch back to WEP again via WLAN.
As this doesn't work for me, I plug-in an ethernet-cable, setup the network for it (just with a simple command: dhcpcd eth1) and turn on WEP encryption again.

Then I am able to use WLAN again with WEP-encryption....


Is this what you wanted to know?

Hi MadMax,

Almost. You wrote:

That's the "this" you're referring to? When you switch to WPA-mode, are you doing it over the RT2500-chip?

Yes. I normally switch to WPA over WLAN. Why is this important for you?

Hi MadMax,

The fact that you can communicate at all over your wireless link with your AP shows that an IEEE802.11 association has been established. Otherwise you would not see the AP's Web HTML page.

Two essential attributes of an association are the authentication scheme (how to prove you are who you say you are) and the encryption scheme (how to assure privacy of your data). The values of these attributes have to be agreed on in advance by the AP (your Fritz!Box) and the STA (your PC). They cannot be changed during an active association. When you try to do so, by changing from WEP authentication and encryption to PSK authentication and TKIP encryption, the AP disconnects you.

You might try accessing your AP in advance over the Ethernet link and configuring it for PSK authentication, TKIP encryption, and the value of the PSK key you intend to use. Then try your wireless link using the same authentication scheme, encryption scheme, and key value.

O.k. - tried what you wrote (alhtough I couldn't really believe it):

1. bring network down
2. connect to FritzBox via eth1
3. Switch FritzBox to WPA-mode
4. bring network down
5. connect to FritzBox via WLAN with my script

=> same behaviour as every time!

My FritzBox is able to store the informations about all WLAN-settings also if there is a loss of power. So even if I switch it off and on again to be 100% sure that there is no active WLAN-association anymore - it behaves all the same!

So your new theory can't be correct, either. If so, how could you explain that I can reach Google, but no other sites in WPA-mode?

And something more against your theory: as I switch from WEP to WPA via WLAN-connection - the association can't be active anymore - I logically loose connection in that case, as I also wrote somewhere above.

Hi MadMax,

Looking at the English versions of the WLAN and WLAN 7050 manuals, I see that they both support WPA security. The problem, I think, is that - as I read the manuals - while 802.1X WPA authentication is supported, WPA-PSK (pre-shared key) is not (cf. pp. 47 of WLAN Guidebook, pp. 56 of WLAN 7050 Guidebook - English versions: "This key is regenerated at regular intervals.").

The legacy driver only supports WPA-PSK, and I'm not aware of plans to upgrade it. I think that if you absolutely need 802.1X-style WPA authentication, you need to use the rt2x00 driver. I believe that driver needs kernel 2.6.17. Maybe Ivo or Mark has more information.

Possibly you could contact AVM and see about WPA-PSK support.