Hi First, now i re-read the code u send at first post and after Harald commentaries i understand better your code modifications, its like having a "iwconfig ath1 channel x" inside the driver, that executes just at the moment and within the packet of interest. Nice!
Obviously if u abuse of this packet the device will be blocking and reseting queues a lot, and this sounds a little weird, but what the hell , if it is working for you! its ok. jeje nice questions, ok, i try: 1) ok 2) Sounds good, it is the desired behavior, and the expected timing. It should be useful to put 2 monitor devices, one at channel 6 and one at channel 11, and verify that each one is receiving the corresponding packet. 3) No, TX hardware queues are always used from 1-9 depending of using 802.11e, beacon queues, etc. To transmit, u send a packet to tx hardware queue. For monitor mode look at ath_tx_startraw() in ath.c, it prepares some descriptors and send the packet to queue. For me sounds good, u couldn't change the channel during the retry phase, in this phase the packet is in the firmware , the firmware is doing the retries, and the code involved in changing the channel is waiting the firmware to finish current retries. Then it locks the device , change the channel and unlocks the device. No problem here, your result looks nice. Another interesting experiment should be to send burst packets, and one of this burst packets signaling a change of channel, u should try to look if the change of channel happens at desired packet. Regards Javier PD if this driver is working send a copy (if it is legally possible) to Ashishs, after read all these "short" mails he deserves the gift. _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
