.. ideally, these people would've created a google code or github
project and dumped their work into that.
Maybe if we ask them nicely, they'll do just that.
Adrian
On 7 April 2013 03:51, Nick Kossifidis <[email protected]> wrote:
> I don't know, so far I 've talked with many people about 802.11p, I 've
> helped most of them with their implementations and so far we have no
> incoming patches. They just don't seem to care if 802.11p support goes
> into mainline.
Shocking!
:-)
One of the FreeBSD wifi developers has nicely built a table for what's
needed for 802.11p support, at least from the kernel side. I'll get it
tidied up and pushed online so we can both take a stab at fixing up
the kernel/driver support.
Some of it is mostly done in linux (half/quarter rate), we will need a
new mode where beacons are disabled; but the fun bits are stuff like
the QoS configuration parameters, time synchronisation stuff and
apparently some requirement that channel change happen within a TU.
That last one? Full of hilarity.
Adrian
On Fri Apr 5 23:37:03 2013, Adrian Chadd wrote:
> .. ideally, these people would've created a google code or github
> project and dumped their work into that.
>
> Maybe if we ask them nicely, they'll do just that.
>
>
>
>
> Adrian
I don't know, so far I 've talked with many people about 802.11p, I 've
helped most of them with their implementations and so far we have no
incoming patches. They just don't seem to care if 802.11p support goes
into mainline.
.. here's what Monthadar has put together thus far:
https://wiki.freebsd.org/802.11p
The two interesting bits:
1) reset within two TU;
2) timing: 'From amendment: "When a STA transmits the Timing
Advertisement frame, the Timestamp shall be set to the value of the
STA?s TSF timer at the time that the data symbol containing the first
bit of the Timestamp is transmitted to the PHY plus the transmitting
STA?s delays through its local PHY from the MAC-PHY interface to its
interface with the WM [e.g., antenna, light emitting diode (LED)
emission surface]'
Are these still required in 802.11-2012? If so, that's going to be fun to meet:
* Ar9380 and later have what I believe is supported and tested
fast-channel-change within a single band (ie, 5GHz-5GHz changes, but
not 5->2 or 2->5 changes) so that should be met.
* .. but the timing advertisement frame is going to be fun to meet. I
don't think Atheros hardware supports that out of the box. So we may
not be able to meet that requirement.
Hm! I'll ask around internally and see what people think.
But the rest of 802.11p is definitely doable.
Grr, these people defining standards that requires the MAC and PHY to
inject crap into the stream.. making things non backwards compatible.
Sigh.
Adrian