Johannes,
I am unable to connect to my AP with at76c50x-usb. I believe the
cause is at76c50x-usb and mac80211 trying to send separate auth and
assoc packets to an AP. Unfortunately the packets for these commands,
while sent over USB to the device, are not actually transmitted. My
understanding is prior to joining a network, packet transmission is
block. However, there is a USB command, CMD_JOIN, for connecting to
wireless networks. Kalle, please correct me if I am wrong on any
details.
CMD_JOIN is a good mapping for cfg80211_ops connect. The complication
is that at76c50x-usb inherits mac80211_config_ops and there does not
seem to be a way to disable auth and assoc in addition to overriding
connect.
Have you thought about such functionality and do you have any ideas
about how it would (or should) be implemented?
Thanks,
Jason
>> However, there is still nothing seen on the monitor interface and it
>> is seeing plenty of other traffic. I am trying to filter with
>> wlan.addr == <Mac Address> in wireshark for what it's worth.
>>
>> Since I am not seeing anything with the CMD_JOIN being sent, I am
>> wondering if my device has failed.
A quick test under OpenBSD doesn't show any transmitted packets on the
monitor interface either and the device doesn't connect to the AP.
Makes me more suspicious of the device having failed.
Jason
On Tue, Dec 8, 2009 at 2:36 AM, Kalle Valo <[email protected]> wrote:
> Jason Andryuk <[email protected]> writes:
>
> Hi Jason,
>
>> I am unable to connect to my AP with at76c50x-usb. I believe the
>> cause is at76c50x-usb and mac80211 trying to send separate auth and
>> assoc packets to an AP. Unfortunately the packets for these commands,
>> while sent over USB to the device, are not actually transmitted. My
>> understanding is prior to joining a network, packet transmission is
>> block. However, there is a USB command, CMD_JOIN, for connecting to
>> wireless networks.
>
> I actually think that the problem is because of missing bssid. I
> recall that when I was, a long time ago, porting at76 to mac80211
> CMD_JOIN didn't work unless I used the correct bssid. I tried to find
> a workaround, for example all zeros or all 0xffs bssid, but no luck.
> So I had to make an ugly hack that uses CMD_SCAN if the bssid is not
> set and CMD_JOIN otherwise.
>
> If you have the time, you could test my theory by hardcoding the bssid
> for CMD_JOIN. Alternatively you could try Luciano Coelho's oper_bssid
> patches from a month back.
Kalle,
My logs do not show CMD_JOIN getting sent after executing an "iw
connect". dmesg shows the three direct probe attempts being sent to
the device in at76_mac80211_tx, but a separate monitor interface does
see them transmitted. at76_mac80211_tx_callback has urb->status == 0;
So I think the direct probes failure is halting mac80211 before it
gets any further. This corresponds to the flows in Johannes's
mac80211 MLME diagrams.
Hacking in the bssid, by initially setting priv->bssid and re-copying
on _bss_info_changed, does have CMD_JOIN get sent. However, it
returns "at76_wait_completion failed: 7" CMD_STATUS_TIME_OUT == 0x07.
iw connect is hung too.
It looked like priv->essid wasn't getting set, so I hacked that one in
too. With the essid hack, the at76_wait_completion disappears, but
there is still no connection. However, there is still nothing seen on
the monitor interface and it is seeing plenty of other traffic. I am
trying to filter with wlan.addr == <Mac Address> in wireshark for what
it's worth.
Since I am not seeing anything with the CMD_JOIN being sent, I am
wondering if my device has failed.
Jason
Jason Andryuk <[email protected]> writes:
> On Wed, Dec 9, 2009 at 5:54 PM, Jason Andryuk <[email protected]> wrote:
>> A quick test under OpenBSD doesn't show any transmitted packets on the
>> monitor interface either and the device doesn't connect to the AP.
>> Makes me more suspicious of the device having failed.
>
> Going back to 2.6.31 and using the staging driver still works.
Good to hear that the hardware still works.
> I am not sure it matters, but the previous hack attempt did not set
> the WEP key. I also noticed a couple of differences with CMD_STARTUP
> between at76_usb and at76c50x-usb. I have not fully investigated the
> differences at this time, but I plan to do so as time permits.
Great that you can work on this, thank you for that.
--
Kalle Valo
Jason Andryuk <[email protected]> writes:
> Kalle,
Hi Jason,
> My logs do not show CMD_JOIN getting sent after executing an "iw
> connect". dmesg shows the three direct probe attempts being sent to
> the device in at76_mac80211_tx, but a separate monitor interface does
> see them transmitted. at76_mac80211_tx_callback has urb->status == 0;
Earlier I have noticed that transmission doesn't work at all with
CMD_SCAN. I used it only to enable monitoring.
> So I think the direct probes failure is halting mac80211 before it
> gets any further. This corresponds to the flows in Johannes's
> mac80211 MLME diagrams.
Yes, that seems to be the case here.
> Hacking in the bssid, by initially setting priv->bssid and re-copying
> on _bss_info_changed, does have CMD_JOIN get sent. However, it
> returns "at76_wait_completion failed: 7" CMD_STATUS_TIME_OUT == 0x07.
>
> iw connect is hung too.
>
> It looked like priv->essid wasn't getting set, so I hacked that one in
> too. With the essid hack, the at76_wait_completion disappears, but
> there is still no connection.
Ok, so CMD_JOIN should work properly then.
I have to admit that the firmware is weird and I have frustrutated
with multiple times. Maybe it's now preventing probe requests and only
allowing authentication and association requuests? If you can hack
mac80211 to skip or ignore probe request phase, that might tell us
more.
> However, there is still nothing seen on the monitor interface and it
> is seeing plenty of other traffic. I am trying to filter with
> wlan.addr == <Mac Address> in wireshark for what it's worth.
>
> Since I am not seeing anything with the CMD_JOIN being sent, I am
> wondering if my device has failed.
Unfortunately I'm busy with other stuff and I can't test it. But if
you can send the patches anyway, and if I find the time at some point,
I can test it with my device.
--
Kalle Valo
On Wed, Dec 9, 2009 at 5:54 PM, Jason Andryuk <[email protected]> wrote:
> A quick test under OpenBSD doesn't show any transmitted packets on the
> monitor interface either and the device doesn't connect to the AP.
> Makes me more suspicious of the device having failed.
Going back to 2.6.31 and using the staging driver still works.
I am not sure it matters, but the previous hack attempt did not set
the WEP key. I also noticed a couple of differences with CMD_STARTUP
between at76_usb and at76c50x-usb. I have not fully investigated the
differences at this time, but I plan to do so as time permits.
Jason
Jason Andryuk <[email protected]> writes:
Hi Jason,
> I am unable to connect to my AP with at76c50x-usb. I believe the
> cause is at76c50x-usb and mac80211 trying to send separate auth and
> assoc packets to an AP. Unfortunately the packets for these commands,
> while sent over USB to the device, are not actually transmitted. My
> understanding is prior to joining a network, packet transmission is
> block. However, there is a USB command, CMD_JOIN, for connecting to
> wireless networks.
I actually think that the problem is because of missing bssid. I
recall that when I was, a long time ago, porting at76 to mac80211
CMD_JOIN didn't work unless I used the correct bssid. I tried to find
a workaround, for example all zeros or all 0xffs bssid, but no luck.
So I had to make an ugly hack that uses CMD_SCAN if the bssid is not
set and CMD_JOIN otherwise.
If you have the time, you could test my theory by hardcoding the bssid
for CMD_JOIN. Alternatively you could try Luciano Coelho's oper_bssid
patches from a month back.
--
Kalle Valo