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
>From a quick look changes on the kernel part are minimal, they moved
most of their work on userspace.
Also the ath5k related part is already upstream (half/quarter rate support).
Could we get this upstream and merge it with current tools ? How does it look ?
--
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick
Have you tested your half/quarter rate stuff against what other
vendors are doing? (eg, the half/quarter rate support inside FreeBSD?)
Adrian
On Thu, 2011-11-17 at 22:59 +0200, Nick Kossifidis wrote:
> 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 ?
That, btw, is a complete hack and not an actual implementation of the
802.11p spec -- I don't think we'll want that upstream.
johannes
2011/11/12 Jan de Jongh <[email protected]>:
> 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.
--
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick
2011/11/6 Johannes Berg <[email protected]>:
> 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
>>
>> From a quick look changes on the kernel part are minimal, they moved
>> most of their work on userspace.
>> Also the ath5k related part is already upstream (half/quarter rate support).
>>
>> Could we get this upstream and merge it with current tools ? How does it look ?
>
> It looks like a website with tarballs, we can't put that into the
> kernel :-)
>
> johannes
>
That's because it's somehow complex, I thought you might be interested
to also look the whole thing + docs etc. The kernel-related parts are
inside GCDCCommStackV3-openwrt-gcdc.tgz
(GCDCCommStackV3-release/openwrt-gcdc/gcdc-backfire-10.03-V3/feed/patches/package/).
--
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick
On 11/19/2011 06:46 PM, Adrian Chadd wrote:
> Have you tested your half/quarter rate stuff against what other
> vendors are doing? (eg, the half/quarter rate support inside FreeBSD?)
>
>
>
> Adrian
No, my ZC901 cards use a 900mhz frequency shifter, and it uses a different channel
set than the UBI cards do. I only have the 2, and due to their sizes, they can
only be used in my Routerstation Pros. I'm putting together the e-mail to send
off right now. All it took was adding debugfs entries for it, like was mentioned.
Pat
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
>
> From a quick look changes on the kernel part are minimal, they moved
> most of their work on userspace.
> Also the ath5k related part is already upstream (half/quarter rate support).
>
> Could we get this upstream and merge it with current tools ? How does it look ?
It looks like a website with tarballs, we can't put that into the
kernel :-)
johannes
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
On 11/17/2011 03:59 PM, Nick Kossifidis wrote:
> 2011/11/12 Jan de Jongh<[email protected]>:
>> 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