Commit 0d528d8 by Felix Fietkau, entitled "mac80211: improve the rate control
API", causes the rtlwifi-family of drivers to be unable to connect to an 802.11g
network. A bisection led to this commit, which was confirmed by reversing the patch.
The drivers can connect to a 802.11n networks, which is why the problem has gone
undetected from kernel 3.10 till now.
These drivers use the rate-control mechanism in their firmware. I suspect that
this is causing the problem. What actions do the drivers need to take that were
not required before this patch?
Larry
On 10/11/2013 02:47 PM, Felix Fietkau wrote:
> On 2013-10-11 9:42 PM, Larry Finger wrote:
>> On 10/10/2013 04:35 PM, Felix Fietkau wrote:
>>> I don't recall any necessary extra actions introduced by this patch.
>>> Please compare the rate selection info passed to the driver before and
>>> after this patch, by dumping info->control.rates.
>>
>> I dumped the structure returned by ieee80211_get_tx_rate(hw, info) and found the
>> same values for the case that worked and the one that failed. The values were:
>> flags 0xc, bitrate 0xa, hw_value 0x0, and hw_value_short 0x0.
> I guess then we need to take another look at what exactly happens when
> the connection fails, I have no idea how that commit can affect rtlwifi.
With NetworkManager, the interface authenticates and associates normally, but it
seems that DHCP never completes. I will fire up my trusty machine that handles
kismet and get a dump of what is on the air.
Larry
On 2013-10-11 9:42 PM, Larry Finger wrote:
> On 10/10/2013 04:35 PM, Felix Fietkau wrote:
>> I don't recall any necessary extra actions introduced by this patch.
>> Please compare the rate selection info passed to the driver before and
>> after this patch, by dumping info->control.rates.
>
> I dumped the structure returned by ieee80211_get_tx_rate(hw, info) and found the
> same values for the case that worked and the one that failed. The values were:
> flags 0xc, bitrate 0xa, hw_value 0x0, and hw_value_short 0x0.
I guess then we need to take another look at what exactly happens when
the connection fails, I have no idea how that commit can affect rtlwifi.
- Felix
On 2013-10-10 11:07 PM, Larry Finger wrote:
> Commit 0d528d8 by Felix Fietkau, entitled "mac80211: improve the rate control
> API", causes the rtlwifi-family of drivers to be unable to connect to an 802.11g
> network. A bisection led to this commit, which was confirmed by reversing the patch.
>
> The drivers can connect to a 802.11n networks, which is why the problem has gone
> undetected from kernel 3.10 till now.
>
> These drivers use the rate-control mechanism in their firmware. I suspect that
> this is causing the problem. What actions do the drivers need to take that were
> not required before this patch?
I don't recall any necessary extra actions introduced by this patch.
Please compare the rate selection info passed to the driver before and
after this patch, by dumping info->control.rates.
- Felix
On 10/10/2013 04:35 PM, Felix Fietkau wrote:
> I don't recall any necessary extra actions introduced by this patch.
> Please compare the rate selection info passed to the driver before and
> after this patch, by dumping info->control.rates.
I dumped the structure returned by ieee80211_get_tx_rate(hw, info) and found the
same values for the case that worked and the one that failed. The values were:
flags 0xc, bitrate 0xa, hw_value 0x0, and hw_value_short 0x0.
Larry