On 07/15/2011 09:42 AM, Stefan Assmann wrote:
> 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
On Tue, Jul 19, 2011 at 07:16:36PM +0200, Stefan Assmann wrote:
> On 19.07.2011 18:16, Ali Bahar wrote:
> > On Tue, Jul 19, 2011 at 11:06:55AM -0500, Larry Finger wrote:
> >> On 07/19/2011 08:24 AM, Stefan Assmann wrote:
> >>>
> >>> 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,
> >
> > 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
> Stefan
On 07/19/2011 08:24 AM, Stefan Assmann wrote:
>
> 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
On 18.07.2011 16:53, Larry Finger wrote:
> On 07/18/2011 03:46 AM, Stefan Assmann wrote:
>> On 18.07.2011 10:27, Ali Bahar wrote:
>>> Stefan,
>>>
>>> I'd like to reproduce this problem. So I'd appreciate some specifics,
>>> as asked below.
>>>
>>>
>>> On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
>>>> On 15.07.2011 17:15, Larry Finger wrote:
>>>>> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>>>
>>>>>> 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
>>>>
>>>> No 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.)
>>
>> 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.
>>
>>>>> 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.
>>
>>> 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. :)
>>
>>>> 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?
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
On 07/18/2011 10:01 AM, Stefan Assmann wrote:
> On 18.07.2011 16:53, Larry Finger wrote:
>> On 07/18/2011 03:46 AM, Stefan Assmann wrote:
>>> On 18.07.2011 10:27, Ali Bahar wrote:
>>>> Stefan,
>>>>
>>>> I'd like to reproduce this problem. So I'd appreciate some specifics,
>>>> as asked below.
>>>>
>>>>
>>>> On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
>>>>> On 15.07.2011 17:15, Larry Finger wrote:
>>>>>> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>>>>
>>>>>>> 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
>>>>>
>>>>> No 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.)
>>>
>>> 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.
>>>
>>>>>> 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.
>>>
>>>> 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. :)
>>>
>>>>> 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?
>
> 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.
Yes. It also changes the scan behavior.
Larry
On 18.07.2011 10:27, Ali Bahar wrote:
> Stefan,
>
> I'd like to reproduce this problem. So I'd appreciate some specifics,
> as asked below.
>
>
> On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
>> On 15.07.2011 17:15, Larry Finger wrote:
>>> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>
>>>> 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
>>
>> No 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.)
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.
>>> 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.
> 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. :)
>> 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
On Tue, Jul 19, 2011 at 11:06:55AM -0500, Larry Finger wrote:
> On 07/19/2011 08:24 AM, Stefan Assmann wrote:
> >
> >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,
Just what I've been thinking lately. I didn't think it very worthwhile
to invest too much into fixing the miscellany.
regards,
ali
> which is a much better MAC layer. That is on my TODO list, but it
> has low priority.
>
> Larry
On 18.07.2011 17:44, Larry Finger wrote:
> On 07/18/2011 10:01 AM, Stefan Assmann wrote:
>> On 18.07.2011 16:53, Larry Finger wrote:
>>> On 07/18/2011 03:46 AM, Stefan Assmann wrote:
>>>> On 18.07.2011 10:27, Ali Bahar wrote:
>>>>> Stefan,
>>>>>
>>>>> I'd like to reproduce this problem. So I'd appreciate some specifics,
>>>>> as asked below.
>>>>>
>>>>>
>>>>> On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
>>>>>> On 15.07.2011 17:15, Larry Finger wrote:
>>>>>>> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>>>>>
>>>>>>>> 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
>>>>>>
>>>>>> No 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.)
>>>>
>>>> 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.
>>>>
>>>>>>> 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.
>>>>
>>>>> 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. :)
>>>>
>>>>>> 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?
>>
>> 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.
>
> 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
On 07/19/2011 12:38 PM, Stefan Assmann wrote:
> On 19.07.2011 19:32, Ali Bahar wrote:
>> On Tue, Jul 19, 2011 at 07:16:36PM +0200, Stefan Assmann wrote:
>>> On 19.07.2011 18:16, Ali Bahar wrote:
>>>> On Tue, Jul 19, 2011 at 11:06:55AM -0500, Larry Finger wrote:
>>>>> On 07/19/2011 08:24 AM, Stefan Assmann wrote:
>>>>>>
>>>>>> 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,
>>>>
>>>> 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
>
> Good idea!
>
>>
>> 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
Hi Stefan,
On Fri, Jul 15, 2011 at 10:15:16AM -0500, Larry Finger wrote:
> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
> >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.
> >
> >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,
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
On 15.07.2011 17:15, Larry Finger wrote:
> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>> 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?
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.
> 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.
>
> 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
On Tue, Jul 19, 2011 at 12:45:21PM -0500, Larry Finger wrote:
> On 07/19/2011 12:38 PM, Stefan Assmann wrote:
> >On 19.07.2011 19:32, Ali Bahar wrote:
> >>>Agreed! Maybe we could add a note to the documentation to make the
> >>>behaviour more obvious.
> >>... The following could be an option:
> >>http://linuxwireless.org/en/users/Drivers/rtl819x
> >
> >Good idea!
> The wpa_supplicant documentation is what should be changed to note
> that scan_ssid is useful for more than hidden ESSIDs. On the other
I assume that you've informed Jouni ([email protected]) already.
> 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
> Larry
Stefan,
I'd like to reproduce this problem. So I'd appreciate some specifics,
as asked below.
On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
> On 15.07.2011 17:15, Larry Finger wrote:
> > On 07/15/2011 09:42 AM, Stefan Assmann wrote:
> >> 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
>
> No 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.)
> > 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?
> 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! ;-)
On 19.07.2011 18:16, Ali Bahar wrote:
> On Tue, Jul 19, 2011 at 11:06:55AM -0500, Larry Finger wrote:
>> On 07/19/2011 08:24 AM, Stefan Assmann wrote:
>>>
>>> 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,
>
> 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
On 19.07.2011 19:32, Ali Bahar wrote:
> On Tue, Jul 19, 2011 at 07:16:36PM +0200, Stefan Assmann wrote:
>> On 19.07.2011 18:16, Ali Bahar wrote:
>>> On Tue, Jul 19, 2011 at 11:06:55AM -0500, Larry Finger wrote:
>>>> On 07/19/2011 08:24 AM, Stefan Assmann wrote:
>>>>>
>>>>> 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,
>>>
>>> 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
Good idea!
>
> 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
On Tue, Jul 19, 2011 at 03:24:29PM +0200, Stefan Assmann wrote:
> On 18.07.2011 17:44, Larry Finger wrote:
> > On 07/18/2011 10:01 AM, Stefan Assmann wrote:
> >> On 18.07.2011 16:53, Larry Finger wrote:
> >>> 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=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.
> >
> > 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
> Stefan
>
On Mon, Jul 18, 2011 at 10:46:24AM +0200, Stefan Assmann wrote:
> On 18.07.2011 10:27, Ali Bahar wrote:
> > 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.
> 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.
> >> 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.
> > 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
On 07/18/2011 03:46 AM, Stefan Assmann wrote:
> On 18.07.2011 10:27, Ali Bahar wrote:
>> Stefan,
>>
>> I'd like to reproduce this problem. So I'd appreciate some specifics,
>> as asked below.
>>
>>
>> On Mon, Jul 18, 2011 at 09:49:00AM +0200, Stefan Assmann wrote:
>>> On 15.07.2011 17:15, Larry Finger wrote:
>>>> On 07/15/2011 09:42 AM, Stefan Assmann wrote:
>>
>>>>> 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
>>>
>>> No 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.)
>
> 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.
>
>>>> 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.
>
>> 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. :)
>
>>> 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