ok change the channel at ieee80211_hardstart() when the TX queues initialize no problem.
But u can change the channel per packet basis? i think this is not possible, to change the channel the drivers needs to reset the chip and restart the tx queues. It is not like change the rate , or the retries.. which can be made per packet basis. But certainly i not tried or worked at it, may be i am wrong. Regards Javier 2009/7/27 Robert Sombrutzki <[email protected]>: > Hi Javier, > i set the channel in ieee80211_hardstart() before ieee80211_monitor_encap() is > called: > > if (vap->iv_opmode == IEEE80211_M_MONITOR) { > if ( ( (vap->iv_flags_ext & IEEE80211_FEXT_CHANNELSWITCH) != 0 ) && ( > skb->dev->type == ARPHRD_IEEE80211_ATHDESC2 ) ) > { > /*I edit the current channel structure, the other option is to create new > structure*/ > chan = ic->ic_curchan; > ath2_h = ( struct ath2_header*)(skb->data + ATHDESC_HEADER_SIZE); > > if ( ( ath2_h->anno.tx_anno.channel != 0 ) && ( > ath2_h->anno.tx_anno.channel != chan->ic_ieee ) ) { > //printk("channelswitch: %d > to %d\n",chan->ic_ieee,ath2_h->anno.tx_anno.channel); > chan->ic_ieee = ath2_h->anno.tx_anno.channel; > chan->ic_freq = ieee80211_ieee2mhz( chan->ic_ieee , chan->ic_flags); > //see ieee80211_input.c and what is done here > ic->ic_set_channel(ic); > } > /*end of channel switching*/ > } > > ieee80211_monitor_encap(vap, skb); > ieee80211_parent_queue_xmit(skb); > return NETDEV_TX_OK; > } > > I add a new header-type (ATHDESC2), which is nearly the same as athdesc, but > with some extention. IEEE80211_FEXT_CHANNELSWITCH is related to a sysctl, > which i add to control the feature (enable/disable). > > Regards > Robert > > On Montag, 27. Juli 2009, Javier Sánchez wrote: >> Hi Robert, >> >> Are u sure on this? >> >> Packets for monitor device comes from ieee80211_output.c -> >> ieee80211_monitor_encap() >> >> on this function the channel value is not processed into >> ieee80211_phy_params ph, for example: >> >> rate is processed: >> >> case IEEE80211_RADIOTAP_RATE: >> ph->rate0 = *p; >> p++; >> break; >> >> >> channel is not processed: >> >> case IEEE80211_RADIOTAP_CHANNEL: >> /* 2 x 16-bit */ >> p = start + roundup(p - start, 2) + 4; >> break; >> >> Regards >> Javier >> >> >> On Mon, Jul 27, 2009 at 5:49 PM, Robert >> >> Sombrutzki<[email protected]> wrote: >> > Hi, >> > i think, it's not the best way to use a sysctl to set the channel, >> > because you can not control which packets are sent on which channel, >> > since you have several queues. Example: you have packet a and b , you >> > want to sent packet a on channel 1 and b on 2. How do you want to control >> > that the new channel is set between these two packets ? Of course, you >> > can delay packet b until the new channel is set, but that has no good >> > performance. I think it better to set the channel using an annotation on >> > the packet. You can extend the ath-header (use AthdescEncap) with an >> > extra field for the channel, which should used for the packet. In the >> > madwifi-driver (e.g. in >> > ieee80211_output.c), you check for the encap-type, the field in the >> > header and the channel and switch to the new channel ( struct >> > ieee80211com includes pointer to the channel-switch-function: >> > ic_set_channel). The problem here is, that you have to sent a packet to >> > switch the channel, but therefor it is precise. To switch the channel >> > without transmitting a packet, you can generate a packet which just >> > initiates the changing the channel, but which is discard by the driver >> > afterwards. According to the channel you can mark such kind of packets >> > using an extention to the ath-header. >> > I use this solution and it works well. >> > >> > Regards, >> > Robert >> > >> >>Hi, >> >> >> >>Can someone please advise me how to write something in /proc/sys in a >> >> click event? I need to change the channel in MadWifi upon reception of a >> >> control packet. I am planning on writing a sysctl handler in madwifi to >> >> change the channel upon request, and I need to trigger it using Click. >> >> If someone has a better suggestion to do this - I'll be glad to know! >> >> >> >>Thanks for your help and time. >> >> >> >>Ashish >> > >> > _______________________________________________ >> > click mailing list >> > [email protected] >> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
