r8712u issue
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Stefan Assmann
Hi Larry,
I'm wondering if you're looking into any issues concerning the driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
Btw I'm using a 0bda:8172 usb adapter with 2.6.39. Thanks for your help!
I need more details. What distro? How are you controlling the network? If NetworkManager, what version?
When this situation occurs, what is output to the dmesg log?
I do not see this situation on my system/device. Whenever the connection is dropped, NM reconnects.
There are a recent patches that might have an effect. Can you build your own kernel?
Larry
Hi Stefan,
Quoted 8 lines · Larry Finger
Quoted 7 lines · Stefan Assmann
Hi Larry,
I'm wondering if you're looking into any issues concerning the driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
I have seen some behaviour in my testing that is not dissimilar to this. But I was going to tackle this in a week or two. This code's state-tracking needs some more work, IIRC.
Quoted 7 lines
Quoted 3 lines
Btw I'm using a 0bda:8172 usb adapter with 2.6.39. Thanks for your help!
I need more details. What distro? How are you controlling the network? If NetworkManager, what version?
Quoted 6 lines
When this situation occurs, what is output to the dmesg log?
I do not see this situation on my system/device. Whenever the connection is dropped, NM reconnects.
There are a recent patches that might have an effect. Can you build your own kernel?
Larry,
the state flags (bup and bDriverStopped) are playing a role here, of course. IIRC bDriverStopped still has some clean-up outstanding. I'll look into my logs.
regards,
ali
Quoted 9 lines · Larry Finger
Quoted 8 lines · Stefan Assmann
Hi Larry,
I'm wondering if you're looking into any issues concerning the driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
Quoted 5 lines
Quoted 2 lines
Btw I'm using a 0bda:8172 usb adapter with 2.6.39. Thanks for your help!
I need more details. What distro? How are you controlling the network? If NetworkManager, what version?
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to /etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
No NM involved.
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
Quoted 5 lines
I do not see this situation on my system/device. Whenever the connection is dropped, NM reconnects.
There are a recent patches that might have an effect. Can you build your own kernel?
Sure, just let me know what to test.
Ccing Ali Bahar to this reply, since he has seen something similar. Ali, if I can help with testing please let me know. And no rush in case you're busy with something else atm. I appreciate the help.
Stefan
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 9 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
Quoted 8 lines
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.confNo NM involved.
So wpa_supplicant is controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
Quoted 23 lines · Ali Bahar
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 16 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.conf
Quoted 8 lines
Quoted 1 line
No NM involved.
So
wpa_supplicantis controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)
OK, so I first recognized the problem when I rebooted my AP and the host in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Quoted 6 lines
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
I see. :)
Stefan
Quoted 8 lines · Stefan Assmann
Quoted 4 lines · Ali Bahar
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)
OK, so I first recognized the problem when I rebooted my AP and the host
Got it. Now I understand.
Quoted 6 lines
in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.
It would (retain its IP#), unless if wpa_supplicant steps in. Frankly, I am not familiar enough with the/any monitoring behaviour of wpa_supplicant to know whether it'd step in. AFAIK it should and it would.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
I don't need this anymore/yet.
Quoted 5 lines
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Thought so. Thanks.
I'll try to reproduce this here.
thanks much,
ali
Quoted 58 lines · Stefan Assmann
Quoted 23 lines · Ali Bahar
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 16 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.confQuoted 8 lines
Quoted 1 line
No NM involved.
So
wpa_supplicantis controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)OK, so I first recognized the problem when I rebooted my AP and the host in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.Quoted 8 lines
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
I see. :)
Please post your wpa_supplicant.conf. In particular, what is the value for scan_ssid?
Larry
Quoted 66 lines · Larry Finger
Quoted 65 lines · Stefan Assmann
Quoted 23 lines · Ali Bahar
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 16 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.confQuoted 8 lines
Quoted 1 line
No NM involved.
So
wpa_supplicantis controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)OK, so I first recognized the problem when I rebooted my AP and the host in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.Quoted 8 lines
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Quoted 6 lines
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
Quoted 4 lines
Quoted 1 line
I see. :)
Please post your wpa_supplicant.conf. In particular, what is the value for
scan_ssid?
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=2
network={
ssid="<ssid>"
id_str="<ssid>"
priority=5
proto=RSN
key_mgmt=WPA-PSK
psk=<psk>
}Should I try again with scan_ssid=1 ? From reading the man page this makes a difference if the ssid is hidden, which is not the case.
Stefan
Quoted 85 lines · Stefan Assmann
Quoted 66 lines · Larry Finger
Quoted 65 lines · Stefan Assmann
Quoted 23 lines · Ali Bahar
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 16 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.confQuoted 8 lines
Quoted 1 line
No NM involved.
So
wpa_supplicantis controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)OK, so I first recognized the problem when I rebooted my AP and the host in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.Quoted 8 lines
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Quoted 6 lines
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
Quoted 4 lines
Quoted 1 line
I see. :)
Please post your wpa_supplicant.conf. In particular, what is the value for
scan_ssid?ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=2network={ ssid="<ssid>" id_str="<ssid>" priority=5 proto=RSN key_mgmt=WPA-PSK psk=<psk> }
Quoted 2 lines
Should I try again with scan_ssid=1 ? From reading the man page this makes a difference if the ssid is hidden, which is not the case.
Yes. It also changes the scan behavior.
Larry
Quoted 86 lines · Larry Finger
Quoted 85 lines · Stefan Assmann
Quoted 66 lines · Larry Finger
Quoted 65 lines · Stefan Assmann
Quoted 23 lines · Ali Bahar
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics, as asked below.
Quoted 16 lines · Stefan Assmann
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
driver. The problem I'm currently facing is that the driver does not recognize any network disconnects. So whenever the network goes down the driver will still report it's connected and thus doesn't reconnect when the network is up again.
The system is a headless debian squeeze with a self build vanilla 2.6.39 kernel. The network is handled by debian scripts I just added the following to
/etc/network/interfaces:
auto wlan0
iface wlan0 inet dhcp
wpa-conf/etc/wpa_supplicant/wpa_supplicant.confQuoted 8 lines
Quoted 1 line
No NM involved.
So
wpa_supplicantis controlling (and presumably monitoring) the connection.
How are you seeing that (to quote the above) "the network goes down" and that the driver reports that "it's connected"? (Typically, I use only ifconfig and iwconfig, but those don't monitor the connection.)OK, so I first recognized the problem when I rebooted my AP and the host in question didn't get back online. Checking the host itself it seemed that the network is doing fine, ifconfig showed the interface has an IP but I couldn't ping any hosts. After an ifdown ; ifup cycle everything was back to normal.
I pulled the power from the AP, waited a few minutes and checked back. The ifconfig output still showed that the device had its IP.Quoted 8 lines
Quoted 5 lines
Quoted 1 line
When this situation occurs, what is output to the dmesg log?
Sorry, I don't have the output at hand but IIRC basically nothing special occurred in dmesg. The interface even keeps it's IP although the wireless was long gone.
So ifconfig shows the IP#. I'm assuming that it no longer shows a state of "UP".
I would assume so, but I'll have to reproduce to make sure.
Quoted 3 lines
This'd seem an inane question, but I must ask: What exactly do you mean by the wireless being "gone"? Which GUI/utility/effect do you see? Is it a powered-down AP, roaming, iwconfig's output, or what?
I pulled the power from the AP. :)
Quoted 6 lines
Quoted 1 line
Ccing Ali Bahar to this reply, since he has seen something similar.
To clarify: I just meant that I've seen quite a number of similar inconsistencies in my testing as well as in my analysis of the code. So, when I read your post, it came as no surprise to me. These'll get fixed ... uh, let's hope soon! ;-)
Quoted 4 lines
Quoted 1 line
I see. :)
Please post your wpa_supplicant.conf. In particular, what is the value for
scan_ssid?ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=2network={ ssid="<ssid>" id_str="<ssid>" priority=5 proto=RSN key_mgmt=WPA-PSK psk=<psk> }
Quoted 4 lines
Quoted 2 lines
Should I try again with scan_ssid=1 ? From reading the man page this makes a difference if the ssid is hidden, which is not the case.
Yes. It also changes the scan behavior.
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Stefan
Quoted 21 lines · Stefan Assmann
Quoted 20 lines · Larry Finger
Quoted 19 lines · Stefan Assmann
Quoted 4 lines · Larry Finger
On 07/18/2011 03:46 AM, Stefan Assmann wrote:
Please post your wpa_supplicant.conf. In particular, what is the value for
scan_ssid?ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=2network={ ssid="<ssid>" id_str="<ssid>" priority=5 proto=RSN key_mgmt=WPA-PSK psk=<psk> }
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Should I try again with scan_ssid=1 ? From reading the man page this makes a difference if the ssid is hidden, which is not the case.
Yes. It also changes the scan behavior.
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
I have not yet managed to reproduce your problem, unfortunately. I will watch for it, though.
regards,
ali
Quoted 2 lines
Stefan
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting scan_ssid for wpa_supplicant establishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.
The ultimate fix will be to convert to the driver to use mac80211, which is a much better MAC layer. That is on my TODO list, but it has low priority.
Larry
Quoted 15 lines · Larry Finger
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting
scan_ssidforwpa_supplicantestablishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.
Quoted 1 line
The ultimate fix will be to convert to the driver to use mac80211,
Just what I've been thinking lately. I didn't think it very worthwhile to invest too much into fixing the miscellany.
regards,
ali
Quoted 4 lines
which is a much better MAC layer. That is on my TODO list, but it has low priority.
Larry
Quoted 16 lines · Ali Bahar
Quoted 15 lines · Larry Finger
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting
scan_ssidforwpa_supplicantestablishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.
Quoted 4 lines
Quoted 1 line
The ultimate fix will be to convert to the driver to use mac80211,
Just what I've been thinking lately. I didn't think it very worthwhile to invest too much into fixing the miscellany.
Agreed! Maybe we could add a note to the documentation to make the behaviour more obvious.
Stefan
Quoted 17 lines · Stefan Assmann
Quoted 16 lines · Ali Bahar
Quoted 15 lines · Larry Finger
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting
scan_ssidforwpa_supplicantestablishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
The ultimate fix will be to convert to the driver to use mac80211,
Just what I've been thinking lately. I didn't think it very worthwhile to invest too much into fixing the miscellany.
Agreed! Maybe we could add a note to the documentation to make the behaviour more obvious.
There's documentation?! ;-|
... The following could be an option:
http://linuxwireless.org/en/users/Drivers/rtl819x
Larry's the author, and so it's _his_ call. _I_ am just tackling whatever problems I run into; at the moment, that happens to be the r8712u driver.
regards,
ali
Quoted 1 line
Stefan
Quoted 23 lines · Ali Bahar
Quoted 22 lines · Stefan Assmann
Quoted 20 lines · Ali Bahar
Quoted 15 lines · Larry Finger
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting
scan_ssidforwpa_supplicantestablishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.Quoted 1 line
The ultimate fix will be to convert to the driver to use mac80211,
Just what I've been thinking lately. I didn't think it very worthwhile to invest too much into fixing the miscellany.
Quoted 7 lines
Quoted 2 lines
Agreed! Maybe we could add a note to the documentation to make the behaviour more obvious.
There's documentation?! ;-|
... The following could be an option:
http://linuxwireless.org/en/users/Drivers/rtl819x
Good idea!
Quoted 4 lines
Larry's the author, and so it's _his_ call. _I_ am just tackling whatever problems I run into; at the moment, that happens to be the r8712u driver.
Right, my statement wasn't directed strictly to you, I was just thinking of how to improve the situation. :)
Stefan
Quoted 35 lines · Stefan Assmann
Quoted 23 lines · Ali Bahar
Quoted 22 lines · Stefan Assmann
Quoted 20 lines · Ali Bahar
Quoted 15 lines · Larry Finger
Quoted 3 lines · Stefan Assmann
So far I can say that with scan_ssid=1 after rebooting the AP the connection is properly re-established. Looks promising.
Your results make sense. The driver is fairly passive in all this. It gets TX requests from the MAC layer, and passes received data back up to that layer. It seems likely that the MAC layer built into r8712u is not keeping track of missing responses, or it is not probing the AP. In either case, it would not be productive to devote any effort to fixing that part when either using NetworkManager or setting
scan_ssidforwpa_supplicantestablishes periodic scans. When these fail to get response from the AP, the softmac code will respond, as you see.Quoted 1 line
The ultimate fix will be to convert to the driver to use mac80211,
Just what I've been thinking lately. I didn't think it very worthwhile to invest too much into fixing the miscellany.
Quoted 7 lines
Quoted 2 lines
Agreed! Maybe we could add a note to the documentation to make the behaviour more obvious.
There's documentation?! ;-|
... The following could be an option:
http://linuxwireless.org/en/users/Drivers/rtl819xGood idea!
Quoted 1 line
Quoted 6 lines
Quoted 3 lines
Larry's the author, and so it's _his_ call. _I_ am just tackling whatever problems I run into; at the moment, that happens to be the r8712u driver.
Right, my statement wasn't directed strictly to you, I was just thinking of how to improve the situation. :)
The wpa_supplicant documentation is what should be changed to note that scan_ssid is useful for more than hidden ESSIDs. On the other hand, EVERY wireless example in 'man wpa_supplicant.conf' shows "scan_ssid=1".
Larry
Quoted 6 lines · Larry Finger
Quoted 4 lines · Stefan Assmann
Quoted 2 lines · Ali Bahar
Quoted 2 lines
Agreed! Maybe we could add a note to the documentation to make the behaviour more obvious.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
... The following could be an option:
http://linuxwireless.org/en/users/Drivers/rtl819xGood idea!
The
wpa_supplicantdocumentation is what should be changed to note thatscan_ssidis useful for more than hidden ESSIDs. On the other
I assume that you've informed Jouni ([email protected]) already.
Quoted 2 lines
hand, EVERY wireless example in 'man wpa_supplicant.conf' shows "scan_ssid=1".
They do, but none of the examples in/usr/share/doc/wpasupplicant/examples/ uses it.
regards,
ali
Quoted 1 line
Larry