[Click] (Queue element BUG?!) Sending packets with a monitor mode interface
dfuste@ac.upc.edu
dfuste at ac.upc.edu
Wed Dec 13 07:10:07 EST 2006
Hello,
could my "persistent" problem be a BUG?
As Torquato said, I have corrected my click config files changing the encap and
decap elements to AthdescEncap and AthdescDecap as well as I have executed
"echo '804' > /proc/sys/net/ath0raw0/dev_type" to tell the driver that I am
working with Atheros encapsulation. However, the problem persists:
The config file of PC1 sends an echo request to PC2:
------------
AddressInfo(safe_addr 6.0.0.2/8 ath0);
winfo :: WirelessInfo(BSSID 00:00:00:00:00:00);
rates::AvailableRates(DEFAULT 2 4 11 22);
InfiniteSource(DATA \<"echo request">, LIMIT 1, STOP false)
-> encap :: WifiEncap(0x0, WIRELESS_INFO winfo)
-> set_rate :: SetTXRate(2)
-> rate::ProbeTXRate(OFFSET 4, THRESHOLD 0, WINDOW 10000, RT rates)
-> set_power :: SetTXPower(63)
//-> ExtraEncap()
-> AthdescEncap()
-> Print(ToDevicePC1)
-> ToDevice(ath0raw0);
FromDevice(ath0raw0)
-> AthdescDecap()
//-> ExtraDecap()
-> phyerr_filter :: FilterPhyErr()
-> tx_filter :: FilterTX()
-> dupe :: WifiDupeFilter()
-> wifi_cl :: Classifier(0/08%0c 1/00%03) //nods data
-> WifiDecap()
-> Print(ToHostPC1)
-> SetPacketType(HOST)
-> Discard;
tx_filter[1]-> [1]rate[1]-> Print(FilterTX)-> Discard;
------------
And PC2, which is running this config file:
------------
AddressInfo(safe_addr 6.0.0.1/8 ath0);
winfo :: WirelessInfo(BSSID 00:00:00:00:00:00);
rates::AvailableRates(DEFAULT 2 4 11 22);
FromHost(safe, safe_addr, ETHER safe_addr)
-> Print(FromHostPC2)
-> q :: Queue()
-> encap :: WifiEncap(0x0, WIRELESS_INFO winfo)
-> set_rate :: SetTXRate(2)
-> rate::ProbeTXRate(OFFSET 4, THRESHOLD 0, WINDOW 10000, RT rates)
-> set_power :: SetTXPower(63)
//-> ExtraEncap()
-> AthdescEncap()
-> Print(ToDevicePC2)
-> to_dev :: ToDevice(ath0raw0);
from_dev :: FromDevice(ath0raw0)
-> AthdescDecap()
//-> ExtraDecap()
-> phyerr_filter :: FilterPhyErr()
-> tx_filter :: FilterTX()
-> dupe :: WifiDupeFilter()
-> wifi_cl :: Classifier(0/08%0c 1/00%03) //nods data
-> WifiDecap()
-> SetPacketType(HOST)
-> Print(ToHostPC2)
-> ToHost(safe);
tx_filter[1]->[1]rate[1]->Print(FilterTX)->Discard();
------------
PC2 receives the echo request and prints the echo reply generated by the kernel
via "Print(FromHostPC2)" but never prints the echo reply via
"Print(ToDevicePC2)". So, the packet never leaves the queue and it is never
sent.
First, I thought that the ToDevice element using a monitor mode interface didn't
pull packets. However, it is not true because the ToDevice of PC1 works
perfectly (obviously). So, the only difference between the two config files
regarding the ToDevice element is that in PC2 there is a Queue element between
the source of the packet and the ToDevice element.
HAS THE QUEUE ELEMENT A BUG?
Then, I remembered that a few days ago I sent another mail with subject "[Click]
Queue segmentation fault":
>Hi,
>why does my click (both in user level and kernel mode) work perfectly with
>"InfiniteSource(DATA \< ..."a ping packet"...>, LIMIT 1, STOP
>true)->ToDevice(eth0);"
>and crashes (Segmentation fault) with
>"InfiniteSource(DATA \<>.."a ping packet"...>, LIMIT 1, STOP true)-> Queue ->
>ToDevice(eth0);"?
>...
I tried to run this "queue" config file in another PC in which I installed click
one year ago and surprisingly, it works fine! The only difference is that in my
old PC I have kernel-2.4.27 + click-1.4.3 while in PC1/2 I have kernel-2.4.28 +
click-1.5.0. So, could be that the queue element have a BUG if click-1.5.0 is
used with the kernel-2.4.28? I know that click-1.5.0 works in 2.6 kernels, but
I installed a 2.4 kernel because first I used madwifi-stripped. Thanks to
Torquato, I noticed that madwifi-stripped does not work with click-1.5.0 and I
changed to madwifi-ng, but I rested with the 2.4 kernel because I do not read
in anywhere that click-1.5.0 and madwifi-ng are incompatibles with 2.4.
Now, I am installing a 2.6 kernel to try if, definitely, my PC1/2 config files
work. However, if it is a BUG of the Queue element, I have thought that it is
important to be posted in the mailing list.
Which is your opinion?
Thanks a lot!!
Quoting Torquato Bertani <torquato at gmail.com>:
> There are some posts about madwifi-ng drivers and click, look for them
> with Google.
>
> For example:
> https://amsterdam.lcs.mit.edu/pipermail/click/2006-August/005111.html
>
> However, IMO, the problem is that you don't use AthdescEncap() and
> AthdescDecap(). I use them and it works perfectly.
>
> Bye
> Thor
>
> On 12/11/06, David Fuste <dfuste at ac.upc.edu> wrote:
> > Hello,
> > I have a basic doubt with click-1.5.0 and madwifi-ng/ath0raw0 interface.
> > I have a PC1 (with ath0=00:20:a6:58:55:b8) running this simple config
> file:
> >
> > ------------
> > AddressInfo(safe_addr 6.0.0.1/8 ath0);
> > winfo :: WirelessInfo(BSSID 00:00:00:00:00:00);
> >
> > InfiniteSource(DATA \<00 20 a6 58 56 40 00 20 a6 58 55 b8 0800
> > 45 00 00 54 00 00 40 00 40 01 2e a7 06 00 00 02
> > 06 00 00 01 08 00 97 97 03 09 00 01 60 7a 75 45
> > 98 9b 04 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
> > 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
> > 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
> > 34 35 36 37>, LIMIT 1, STOP true)
> > -> encap :: WifiEncap(0x0, WIRELESS_INFO winfo)
> > -> set_power :: SetTXPower(63)
> > -> set_rate :: SetTXRate(2)
> > -> radiotap_encap :: RadiotapEncap()
> > -> Print(ToDevicePC1)
> > -> ToDevice(ath0raw0);
> >
> > FromDevice(ath0raw0)
> > -> prism2_decap :: Prism2Decap()
> > -> extra_decap :: ExtraDecap()
> > -> radiotap_decap :: RadiotapDecap()
> > -> phyerr_filter :: FilterPhyErr()
> > -> tx_filter :: FilterTX()
> > -> dupe :: WifiDupeFilter()
> > -> wifi_cl :: Classifier(0/08%0c 1/00%03) //nods data
> > -> WifiDecap()
> > -> Print(ToHostPC1)
> > -> SetPacketType(HOST)
> > -> Discard;
> > ------------
> >
> > The InfiniteSource data is an echo request to another PC2
> > (with MAC=00:20:a6:58:56:40), which is running this other config file:
> >
> > ------------
> > AddressInfo(safe_addr 6.0.0.2/8 ath0);
> > winfo :: WirelessInfo(BSSID 00:00:00:00:00:00);
> >
> > FromHost(safe, safe_addr, ETHER safe_addr)
> > -> Print(FromHostPC2)
> > -> q :: Queue()
> > -> encap :: WifiEncap(0x0, WIRELESS_INFO winfo)
> > -> set_power :: SetTXPower(63)
> > -> set_rate :: SetTXRate(2)
> > -> radiotap_encap :: RadiotapEncap()
> > -> Print(ToDevicePC2)
> > -> to_dev :: ToDevice(ath0raw0);
> >
> >
> > from_dev :: FromDevice(ath0raw0)
> > -> prism2_decap :: Prism2Decap()
> > -> extra_decap :: ExtraDecap()
> > -> radiotap_decap :: RadiotapDecap()
> > -> phyerr_filter :: FilterPhyErr()
> > -> tx_filter :: FilterTX()
> > -> dupe :: WifiDupeFilter()
> > -> wifi_cl :: Classifier(0/08%0c 1/00%03) //nods data
> > -> WifiDecap()
> > -> SetPacketType(HOST)
> > -> Print(ToHostPC2)
> > -> ToHost(safe);
> > ------------
> >
> > PC2 has the corresponding MAC-IP translation of PC1 in its ARP Table
> (added
> > manually). So, when I run these click config files (in user-level mode),
> > PC1 sends the echo request to PC2 and PC2 prints the received echo
> > request (Print(ToHostPC2)). Moreover, PC2 generates the echo reply and
> > passes
> > it to click through the FromHost element. Then, click prints the echo
> > reply (Print(FromHostPC2)). But from here on, click does not print the
> echo
> > reply (Print(ToDevicePC2)) and so, does not send it.
> >
> > My question is, why does not the packet leave the queue? is it because the
> > ToDevice element does not pull packets? why?
> > I have created the ath0raw0 interface using these commands:
> > %>wlanconfig ath0raw create wlandev wifi0 wlanmode monitor
> > %>ifconfig ath0 up
> > %>Radiotap headers: echo '803' > /proc/sys/net/ath0/dev_type
> > and I read in the madwifi web page that this monitor mode interface can
> > both
> > receive and send packets. So, where is my mistake?
> > Is maybe a madwifi (and not click) issue?
> > Could anybody tell me a good solution to perform this simple operation
> > in click?
> >
> > I have tried a lot of configurations and I never get the correct
> > operation...
> > Thanks a lot!
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> >
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
More information about the click
mailing list