[Click] How to write to /proc in a click element
Robert Sombrutzki
sombrutz at informatik.hu-berlin.de
Mon Jul 27 15:30:12 EDT 2009
Hi Javier,
i run some 3 experiments to check the behavior of the hardwarequeues.
1.
Using click i send packet with a size of 1432 byte at rate of 1MBit/s
(SetTXRate(2)) every 12 ms (Channel 6). A receiver gots:
OKPacket: 1248829193.716137: 1432 | 1Mb +18/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 748 [ ] EXTRA:
80880000 0000035d 0c000e02 10000000
OKPacket: 1248829193.728292: 1432 | 1Mb +17/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 749 [ ] EXTRA:
80880000 0000035e 0c000e02 10000000
OKPacket: 1248829193.740171: 1432 | 1Mb +18/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 750 [ ] EXTRA:
80880000 0000035f 0c000e02 10000000
The second field after "EXTRA" is the number of the packet: Here 861 to 836.
He receive a packet nearly every 12ms (number after "OKPacket:" is the time in
seconds). 1432Bytes / 12ms ~ 0,932 kBit/s.
2.
Now i switch the channel before sending a packet ( channel 6 and 11 is used).
The receiver stays on channel 6. He receives the following:
OKPacket: 1248830786.651634: 1432 | 1Mb +17/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 0 [ ] EXTRA:
80880000 00000023 0c000e02 10000000
OKPacket: 1248830786.709206: 1432 | 1Mb +18/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 0 [ ] EXTRA:
80880000 00000025 0c000e02 10000000
OKPacket: 1248830786.766691: 1432 | 1Mb +17/-99 | Type data nods
FF-FF-FF-FF-FF-FF 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 0 [ ] EXTRA:
80880000 00000027 0c000e02 10000000
Result: The time between receive is bigger. The reason is the delay on the
sender, because he has to change the channel. The receiver gots only every
second packet since the other is send on channel 11.
3. Now i send unicastpacket to one nonexisting macaddress ( with 8 retries).
And like before: packetsize 1432 bytes, rate 1MBit/s and every 12ms using
click-element like RatedSource.
With the first packet (A) set driver set channel 6 and start to transmit.
Since the packet A is send to a nonexisting address, it should stay in the
queue for more than 90ms, because one transmission of 1432 byte using a rate
of 1MBit/s takes more than 10 ms and the paket is retransmitted 8 times.
If the driver gets a new paket B from click after 12 ms and switches to the
new channel (annotation of the new packet B) and reset the hardware queue,
then the receiver should not see every retransmission. Correct ??
But the result is:
OKPacket: 1248831337.172936: 1432 | 1Mb + 5/-99 | Type data nods
00-0A-03-04-05-06 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 1 [ ] EXTRA:
80880000 00000001 0c000e02 10000000
OKPacket: 1248831337.184952: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.196922: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.208714: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.220901: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.233180: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.245511: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.257524: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.269871: 1432 [...] seq 1 [ retry ] EXTRA: 80880000
00000001 0c000e02 10000000
OKPacket: 1248831337.427403: 1432 | 1Mb +18/-99 | Type data nods
00-0A-03-04-05-06 06-0B-6B-09-F2-94 00-00-00-00-00-00 seq 0 [ ] EXTRA:
80880000 00000003 0c000e02 10000000
The receiver gets every retry. For me it looks like, that the hardware queue
is not used in monitormode (just for one packet) and that the driver fetches
the next packet from the upper layer after the one in the queue is
transmitted. Is that possible ?? Maybe the queue are only used for 802.11e,
WME or in PCF-mode. Or is that related to the click-element "ToDevice" ?
Any hints or ideas relating to the experiments ??
Regards,
Robert
On Montag, 27. Juli 2009, Javier Sánchez wrote:
> 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 <sombrutz at informatik.hu-berlin.de>:
> > 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<sombrutz at informatik.hu-berlin.de> 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
> >> > click at amsterdam.lcs.mit.edu
> >> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
More information about the click
mailing list