[ath9k-devel] ath9k version and commits

[gtolon at inti.gob.ar <gtolon@inti.gob.ar>]

Hi, i was looking into the wireless-testing git, and i don?t understand 
the relationship between the different commits and the srcversion of the 
ath9k drivers. For example i have the srcversion 
3D4208C725AB8FBF6E5A21B, and i couldn?t find that number in the 
wireless-testing ath9k git commits. I?d like to relate the different 
commit comments to the srcversions. Sorry if this is too basic but i?ve 
been searching for documentation about this without success.

El 22/07/2011 12:05 p.m., Mohammed Shafi escribi?:
> On Fri, Jul 22, 2011 at 7:14 PM, Gabriel Tol?n<gtolon@inti.gob.ar>  wrote:
>> Thank you for your answer. I?ll put it in two different cases:
>>
>>   1) with the ath9k driver with comes with compat wireless 2.6.39-1:
>>
>>     Yes, like you said that ?s the message i get from dmesg when i try to
>> create the ad-hoc interface after another interface is up. However if i
>> first create the ad-hoc interface then i can bring up the original     wlan0
>> and run hostapd on it. But when i try to create an IBSS with "ibss join" i
>> get "device or resource bussy". I don?t know why the order of interface
>> creation/bringing up is important in this case.
> this check might be missing there
>
> commit 59575d1c717815d62f1b5aeac74e5e60a1b27428
> Author: Rajkumar Manoharan<rmanoharan@atheros.com>
> Date:   Mon Apr 4 22:56:16 2011 +0530
>
>      ath9k: deny new interface addtion on IBSS mode
>
>      The present check denies the IBSS interface addtion if we
>      already have any other vifs. But it fails to deny interface
>      addition if IBSS was already present.
>
>      Signed-off-by: Rajkumar Manoharan<rmanoharan@atheros.com>
>      Signed-off-by: John W. Linville<linville@tuxdriver.com>
>
>>   2) with older ath9k versions, for example compat wireless 2.6.32-16:
>>
>>     In this case i can run hostapd in wlan0 and then create and bring up an
>> ad-hoc interface without problems, furthermore i can join to an ibss with
>> "iw ibss join" and all works fine.
> commit 4801416c76a3a355076d6d371c00270dfe332e1c
> Author: Ben Greear<greearb@candelatech.com>
> Date:   Sat Jan 15 19:13:48 2011 +0000
>
>      ath9k: Fix up hardware mode and beacons with multiple vifs.
>
>>
>> The main doubt i have is why the case 2) is not supported anymore, if is
>> something wrong about it. Thank you again.
> I am not aware of the details, but I think it is because of TSF timer
> handling in driver
>>
>>
>>
>> El 22/07/2011 02:03 a.m., Mohammed Shafi escribi?:
>>> On Fri, Jul 22, 2011 at 1:15 AM, Gabriel Tol?n<gtolon@inti.gob.ar>    wrote:
>>>> Hi
>>>>
>>>> I?ve been using an Atheros 9285 chipset in a 2.6.32-32 kernel with ath9k
>>>> and two virtual interfaces, one in ad-hoc mode and the other in master
>>>> mode using hostapd. That configuration worked fine, with some computers
>>>> connected to the Acces Point and others to the IBSS running in the
>>>> ad-hoc interface. The only problem was that when bringing up the IBSS
>>>> (using iw) the interface using hostapd stopped sending beacons, but as
>>>> far as i understood all kept working thanks to the probe requests and
>>>> responses.
>>>>
>>>> Then i upgraded the ath9k driver using compat wireless-2.6.32.16 and all
>>>> worked like before. But when i used the ath9k driver of compat
>>>> wireless-2.6.39-1 i couldn ?t bring the IBSS up when the hostapd was
>>>> running (i could bring the ad hoc interface up, but not the IBSS with
>>>> "iw ibss join"). I?d like to know if this configuration is not supported
>>>> or will not be supported anymore, and if it could be possible to have
>>>> the AP beaconing together with an IBSS. Thank you!
>>> you would have got ?
>>> [ 2841.528600] ath: Cannot create ADHOC interface when other
>>> interfaces already exist.
>>>
>>> because of this check in main.c
>>>
>>>    if ((ah->opmode == NL80211_IFTYPE_ADHOC) ||
>>>              ((vif->type == NL80211_IFTYPE_ADHOC)&&
>>>               sc->nvifs>    0)) {
>>>                  ath_err(common, "Cannot create ADHOC interface when other"
>>>                          " interfaces already exist.\n");
>>>                  ret = -EINVAL;
>>>                  goto out;
>>>          }
>>>
>>>
>>>
>>>
>>>>
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>
>
>