Re: 802.11p implementation...

[Pat Erley <pat-lkml@erley.org>]

On 11/17/2011 03:59 PM, Nick Kossifidis wrote:
> 2011/11/12 Jan de Jongh<jfcmdejongh@gmail.com>:
>> Nick Kossifidis<mickflemm@...>  writes:
>>
>>>
>>> 2011/11/6 Johannes Berg<johannes@...>:
>>>> On Sun, 2011-11-06 at 02:53 +0200, Nick Kossifidis wrote:
>>>>> It seems a group of people have released an 802.11p implementation on
>>>>> top of 2.6.31.
>>>>>
>>>>> http://www.gcdc.net/mainmenu/Home/downloads/Technology
>> ...
>>>> johannes
>>>>
>>>
>> ...
>>
>> Hi Nick, Johannes,
>>
>> First, please note that I haven't checked on recent ath5k support for 802.11p.
>> If such support it already present, this mail is quite obsolete :-)...
>>
>> The Grand Cooperative Driving Challenge succesfully used 802.11p in
>> vehicle-to-vehicle communications and vehicle-to-infrastructure communications,
>> using a modified ath5k driver (which you found on the gcdc.net site).
>> Apart from GCDC, there are many research and commercial projects/products
>> (SPITS/FREILOT/...) using patched ath5k drivers for half-clock-rate operation,
>> ocb, and access to the 5.9-6.0 GHz frequencies.
>> And there are many more to come,.
>> Simply because Atheros-based cards are among the few
>> (if not the only ones)
>> that support 802.11p/5.9GHz operation.
>> For GCDC, the patches had their origins in the CVIS project,
>> and in work by Eric Koenders of Peek Traffic.
>>
>> However, the current situation is far from ideal...
>> By now, the 11p amendment has been ratified,
>> but maintaining 802.11p support for contemparory kernel/compat-wireless combos
>> is near to impossible without structural support from ath/ath5k developers.
>> The result of this effort, in short, would mean 802.11p operation
>> through module parameter and crda/regdb settings only,
>> and without the need to (re)compile kernels and/or kernel modules.
>> 11p Operation would simply imply some configuration efforts
>> on well-known distributions (modules,conf, regdb/crda, iw, and stuff like that)
>> out-of-the-box...
>> I understand that there are regulatory issues
>> (crda, do we want anyone to operate on the ITS frequencies???) involved,
>> but we would be very interested in
>> structural 11p support in the ath5k driver (and, perhaps ath9k).
>> "We" referring to a substantial part of the ITS community.
>> If you can arrange substantial commitment to 11p support in ath5k,
>> I can mobilize people and funding for
>> development/testing/deployment/discussion/feedback.
>>
>> Let me know what you think of this, best wishes,
>>
>> Jan de Jongh
>> GCDC - Technology Leader
>>
>
> ath5k already has half/quarter width channel support, we just don't
> have an interface for it yet (we 'll add one through debugfs soon).
> What else do you need from the driver and the protocol stack ? From a
> quick look at the patches you use, you only want half width channel
> support and to disable beacons by setting beacon interval to 0. Is
> that all ?
>
> Also your patches on ath5k are missing some parts, I suggest you
> update your code or re-base your changes on top of a newer kernel
> version to get proper half width support for more cards and more.
>
> Finally if you want to work with upstream developers I suggest you
> send your code and comments to linux-wireless instead.
>
>
I have a working patch I'm using (and an openwrt implementation patch).  I'll
resubmit them to the ath5k-devel ML monday.  It works quite well.

Pat Erley