802.11p implementation...

802.11p implementation...

[Nick Kossifidis]

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

Re: 802.11p implementation...

[Johannes Berg]

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

Re: 802.11p implementation...

[Nick Kossifidis]

2011/11/6 Johannes Berg <johannes@sipsolutions.net>:
> 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

Re: 802.11p implementation...

[Jan de Jongh]

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

Re: 802.11p implementation...

[Nick Kossifidis]

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.


-- 
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: 802.11p implementation...

[Johannes Berg]

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

Re: 802.11p implementation...

[Pat Erley]

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

Re: 802.11p implementation...

[Adrian Chadd]

Have you tested your half/quarter rate stuff against what other
vendors are doing? (eg, the half/quarter rate support inside FreeBSD?)



Adrian

Re: 802.11p implementation...

[Pat Erley]

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

802.11p implementation

[Hernán Maximiliano]

Hello everyone,

I am working to adapt the ath5k module to transmit in the 5850..5925GHz
range, in order to comply with IEEE 802.11p requirements. Our plan is to
liberate the code to the community as soon as we develop it. I originally
posted this in ath5k-devel mailing list, but someone suggested me to post
try here too.


I have already compiled a new regdomains database with wireless-regdb and
crda, and we are using the module in ATH5K_TEST_CHANNELS mode. The database
is now defined as follows:

(2402 - 2472 @ 40), (3, 27)
(5170 - 5250 @ 40), (3, 17)
(5250 - 5330 @ 40), (3, 20)
(5490 - 5600 @ 40), (3, 20)
(5650 - 5710 @ 40), (3, 20)
(5735 - 5835 @ 40), (3, 30)
(5835 - 5925 @ 10), (3, 30) -> For 802.11P

However, when I execute "iw wlan1 ibss join TFG 5850" it returns the -22
error number, indicating that we are using a frequency not defined.