Are 802.11s and "classical" AP compatible?

Hello, Freebsd-wireless. ath could have several VAPs, each with its own SSID and security settings (but with shared channel(s), of course). Is it possible to do 802.11s node and "classical" AP on one card, to have 802.11s <-> WiFi gateway with one piece of hardware? -- // Black Lion AKA L

Re: Are 802.11s and "classical" AP compatible?

not yet, sorry. adrian On 28 February 2013 02:03, Lev Serebryakov wrote: > Hello, Freebsd-wireless. > > ath could have several VAPs, each with its own SSID and security > settings (but with shared channel(s), of course). > > Is it possible to do 802.11s node and "classical" AP on one car

Re: Are 802.11s and "classical" AP compatible?

Hello, Adrian. You wrote 28 февраля 2013 г., 14:04:41: AC> not yet, sorry. Is it limitation of FreeBSD's drivers or "universal" one? Friend of my have some ideas about such gateway, but he could use Linux-based "firmaware" (OpenWRT-based, really) as well. Do you know if Linux supports such mode?

Re: Are 802.11s and "classical" AP compatible?

On 28 February 2013 02:11, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 28 февраля 2013 г., 14:04:41: > > AC> not yet, sorry. > Is it limitation of FreeBSD's drivers or "universal" one? Friend of > my have some ideas about such gateway, but he could use Linux-based > "firmaware" (OpenWRT-b

Re: ath0 Device Timeout Issues

On 27 February 2013 18:59, Derrick Dantavious Edwards wrote: > > Yes. When I start the system, I get those messages. Wireless Link fails to > establish thus causing all services requring link to failie NFS . Soon > after I am at the command prompt or GUI, I can ping hosts however, I have

Re: ath0 Device Timeout Issues

Just experiment with changing the kern.eventtimer.periodic and kern.timecounter.hardware values. Thanks, Adrian On 28 February 2013 03:20, Derrick Dantavious Edwards wrote: > On 27 February 2013 18:59, Derrick Dantavious Edwards > wrote: >> >> Yes. When I start the system, I get those me

Re: [RFT] net80211 TX serialisation, take #4

Hi, Right - but then I still need to hold long held locks here across the net80211 _and_ the driver. Ie: * net80211 needs to hold a lock for the entire process of dequeuing a frame and running it to completion. It can't do this: * grab lock * dequeue frame * release lock --> here things race

[RFC] replace ic->ic_raw_xmit() calls with a method - ieee80211_raw_xmit()

Hi, As part of eventually making ic_raw_xmit() go via the vap/ic queue, I'd like to methodise this. Right now the stack calls ic->ic_raw_xmit(ni, mbuf, params) directly. I'd like to stick it inside a method call. Later on the raw frames can be queued via the VAP TX queue and processed in-order.