Re: r8712u issue

Re: r8712u issue

[Larry Finger]

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

Re: r8712u issue

[Ali Bahar]

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

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Ali Bahar]

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! ;-)

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Ali Bahar]

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

Re: r8712u issue

[Larry Finger]

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

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Larry Finger]

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

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Ali Bahar]

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
> 

Re: r8712u issue

[Larry Finger]

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

Re: r8712u issue

[Ali Bahar]

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

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Ali Bahar]

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

Re: r8712u issue

[Stefan Assmann]

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

Re: r8712u issue

[Larry Finger]

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

Re: r8712u issue

[Ali Bahar]

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 (hostap@lists.shmoo.com) 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