I have a Ralink rt73usb wireless dongle that normally works without any problems. However I have noticed that when I have a pen drive plugged into an adjacent socket, the dongle plays up and I can't get the interface to work.

I don't think it's anything to do with the seating of the dongle in its socket, because that would prevent wlan0 from coming up at all. In fact it does come up as a local interface but fails to communicate properly with my router. It gets as far as sending out a DHCP request but then claims to have received no offers. ip link show gives "No carrier".

Can anyone suggest a way of investigating this. It's a trivial problem but it's illogical and it annoys me.

Probably the first place to start is with the lsusb -v command.

Also, carefully look at the system logs (probably /var/log/syslog or something like it ...) before and after you insert or remove these various devices.

If you want to thoroughly diagnose a situation like this, yeah it's a bit of work, but ... you should observe all possible situations, and take notes:

• Disk (alone) is inserted, then removed.
• Wireless (again, alone), is inserted, then removed.
• Wireless inserted, then disk. (Then two possibilities as to which one is removed first.)
• Disk first ... "ditto (two)."

Two entirely different software agents will respond in due course, both to the insertion of their device-of-interest, and to its removal. Looks like there are six total possibilities here.

Methodically work through all six of them and you should be able to find your problem, then tell the rest of us and mark this thread [SOLVED].

(And, mind you, I am not making any sort of 'humor [at your expense]' here!) This seems to be 'some kind of a timing problem,' and there are a mere six possible courses to consider.

1 members found this post helpful.

ideas.

interference, power issue, controller borked, connector borked, poor alignment.

It doesn't depend on a second usb device being connected. Today I booted with just the dongle and it failed. I've checked the logs carefully, comparing failed and successful attempts. In both cases the usb device is recognised and the correct driver loaded, followed by the loading of requested firmware. Then the device requests a DHCP address like this:
In a bad run, this happens repeatedly, in a good run only once or twice.

syslog has it like this:
But today it came up quite suddenly and spontaneously about half an hour after booting.

It must be bad seating after all.

Well, I've established that the presence of another usb device is not always necessary to cause the problem. The two usb sockets are adjacent, so plugging in another device could affect the seating of the dongle (which is quite large). But I'm still dissatisfied. Previous experience with usb suggests to me that a badly seated device usually affects the usb controller, which reports that the device is being repeatedly removed and reinserted. That isn't happening here. Instead the problems arise later, during dhcp negotiation.

One problem is that I have no idea how wpa_supplicant and the dhcp client cooperate over this job. Only wpa_supplicant and the kernel seem to report to syslog. There appear to be two steps: authentication and association. I assume authentication means that the router has decrypted the request and got plain text, and can therefore confirm that wpa_supplicant is using the correct key. But what is association? It's clearly not the association of an IP address with the card because that isn't happening.

PS: just found this. It's very helpful.

What happened this morning is that I booted around 12:00 and wifi didn't come up, but it came up spontaneously around 12:27 according to syslog. Any ideas?

Based on what I am reading so far, I suggest that "USB is a red herring."

Most likely, your true culprit is "wpa_supplicant key-renegotiation," which indeed does occur "from time to time" and which certainly could have occurred "after about half an hour."

(So far as I know, the log in post #4 indicates successful(!) re-negotiation. And yet, the only subsequent comment you make refers to "bad seating after all.")

Therefore, I suggest that you should pursue this problem henceforth as: "never mind the fact that the interface is USB." The true root-cause is most likely to be the supplicant. I am so-far of the opinion that it has nothing to do with "seating," nor with any aspect of your [USB] hardware.

The difference between these two software agents is as follows:

1. "wpa_supplicant" is responsible for periodically re-negotiating a random hardware cipher-key. (This is the primary security-improvement of WPAx versus WEP: although the same underlying hardware-encryption technology is still used, the key is no longer "simply, and unchangingly" tied to a "simple password." Instead, the two parties periodically negotiate a new key.)
2. "dhcp_agent" is responsible for talking to a DHCP server to establish a local IP-address. (It is used in any network connection, "wireless" or not.) Ordinarily, this agent should perform and should complete its negotiations only once, and the periodic re-negotiation of a cipher key (by "wpa_supplicant") should not interfere with this, nor even be visible to it. The fact that you see "dhcp_agent" becoming involved again, indicates simply that the link dropped ... hence, "wpa_supplicant" did not succeed in doing its job.

Your "root cause problem" therefore appears now-revealed to be (IMHO) ... not USB, but the supplicant.

1 members found this post helpful.

That's a huge step forward!
Yes, sorry. Tomorrow I'll post up a bad one so that you can see what that looks like.

So they use one-time keys? How are these related to the permanent shared secret that I created? A link would be useful.
Well, now at least I know what to look for. My current guess is that dhcpc failed to find the server simply because there was no carrier. That's irrelevant. wpa is the system that's misbehaving. Tomorrow is another day!

So here is an attachment showing today's work. wifi failed to come on at boot but it did later on. Maybe someone can see the difference between the unsuccessful attempts and the final successful one.

Attached Files

dongle.txt (9.5 KB, 9 views)

I'm bumping this thread because I've discovered something new and potentially useful. As you can see from the attachment to the previous post, the dongle will authenticate and associate with the router successfully but then deauthenticates before the dhcp client can make use of the link. And this happens repeatedly.

Dec 7 11:50:54 Oldboy kernel: [ 118.646471] wlan0: deauthenticating from 00:13:f7:45:a8:ff by local choice (Reason: 3=DEAUTH_LEAVING)

I assumed from this that the dongle was making some kind of decision to break the link for reasons that were not being made clear. Isn't that what you would naturally assume from the reference to "local choice"? Apparently that is not so. After much browsing, I found a list of the numeric codes for these reasons for deauthenticating at http://www.aboutcher.co.uk/2012/07/l...d-reason-codes .
Reason 3 is given as "The access point went offline, deauthenticating the client." In other words, it's the router that keeps dropping the connection. Now can anyone suggest why that is happening?

I give up! I spent most of yesterday evening googling this error message and concluded that even if it is the router that drops the connection, it does so because of misbehaviour by the client. For example, there was a big bug report a few years ago with contributions from over 100 Ubuntards who found their wifi didn't work properly any more after they upgraded to Lucid Lynx. Same symptoms: the NIC authenticated, associated, and then deauthenticated with reason 3. Many of them found "solutions" and curiously every one of these worked brilliantly for some users and not at all for others. And no one ever explained why.

I wrote out all these solutions, determined to go through them systematically today. I also planned to test the router by using my laptop, littleboy, first downstairs and then upstairs in the room where oldboy lives to see if there was any difference in reception. And waddyaknow! Wifi on oldboy came up at boot just the way it's supposed to. It hasn't done that for weeks. So no chance of testing anything.

I've decided that computers are just irrational and that I shall never understand them if I live to be 100.