Searched hist:244060 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-11.0-release/sys/net80211/ | ||
| H A D | ieee80211_sta.h | diff 244060 Sun Dec 09 23:04:11 MST 2012 adrian Handle ath-specific and WME IE's in adhoc mode. The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer. It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters. Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky. So ensure that you configure your adhoc nodes with the same WME parameters. Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly. TODO: * I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode. Tested: * AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.) PR: kern/165969 |
| H A D | ieee80211_adhoc.c | diff 244060 Sun Dec 09 23:04:11 MST 2012 adrian Handle ath-specific and WME IE's in adhoc mode. The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer. It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters. Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky. So ensure that you configure your adhoc nodes with the same WME parameters. Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly. TODO: * I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode. Tested: * AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.) PR: kern/165969 |
| H A D | ieee80211_sta.c | diff 244060 Sun Dec 09 23:04:11 MST 2012 adrian Handle ath-specific and WME IE's in adhoc mode. The Adhoc support wasn't parsing and handling the ath specific and WME IEs, thus the atheros vendor support and WME TXOP parameters aren't being copied from the peer. It copies the WME parameters from whichever adhoc node it decides to associate to, rather than just having them be statically configured per adhoc node. This may or may not be exactly "right", but it's certainly going to be more convienent for people - they just have to ensure their adhoc nodes are setup with correct WME parameters. Since WME parameters aren't per-node but are configured on hardware TX queues, if some nodes support WME and some don't - or perhaps, have different WME parameters - things will get quite quirky. So ensure that you configure your adhoc nodes with the same WME parameters. Secondly - the Atheros Vendor IE is parsed and operated on per-node, so this should work out ok between nodes that do and don't do Atheros extensions. Once you see a becaon from that node and you setup the association state, it _should_ parse things correctly. TODO: * I do need to ensure that both adhoc setup paths are correctly updating the IE stuff. Ie, if the adhoc node is created by a data frame instead of a beacon frame, it'll come up with no WME/ath IE config. The next beacon frame that it receives from that node will update the state. I just need to sit down and better understand how that's suppose to work in IBSS mode. Tested: * AR5416 <-> AR9280 - fast frames and the WME configuration both popped up. (This is with a local HAL patch that enables the fast frames capability on the AR5416 chipsets.) PR: kern/165969 |
Completed in 135 milliseconds