Javier, I'm not sure how you configured tcpdump for these traces, but these doubled packets in tcpdump might be: the first one is sent from click to the device, and the second one is the actual feedback sent from the device to click. --Szymon
2009/7/27 Javier Sánchez <[email protected]>: > Yes, you helped, > > I looked at FilterTX element (i was not using it) and probably this is > filtering the bad packet i am speaking. Thx. But if u look at tcpdump > u probably see 2 tx feedbacks packets x packet. > > I think that the extradecap element is not necesary anymore, if you > are not using madwifi stripped driver. This driver was using an > special header that the current madwifi is not using. RadiotapDecap > and FilterTX should do all the job. > > Regards > Javier > > 2009/7/27 Szymon Jakubczak <[email protected]>: >> Hmm, this is unusual. I have never experienced this before, but I >> haven't played with the recent madwifi. My regular wifi config is: >> >> FromDevice(... OUTBOUND true) >> -> ExtraDecap -> RadiotapDecap /* phy decap */ >> /* some classifiers */ >> -> txf :: FilterTX() >> -> ... >> >> txf[1] -> ... >> >> Anyway, glad I could help. >> --Szymon >> >> 2009/7/27 Javier Sánchez <[email protected]>: >>> Hi Szymon, >>> >>> I not tried, but i think u are right, i looked at code, and with >>> FromDevice(...OUTBOUND true) tx feedback packets should be received. >>> Thanks. >>> >>> There is another problem i have. For each packet i transmit, i receive >>> 2 tx feedback packets, one is correct and the other is incorrect, i >>> looked at tcpdump and certainly there are 2 tx feedback packets x >>> packet, so is not click fault, maybe madwifi fault ¿? anyway this >>> problem is minor because is easy to filter the bad packet. >>> >>> Regards >>> Javier >>> >>> On Mon, Jul 27, 2009 at 2:47 PM, Szymon Jakubczak<[email protected]> wrote: >>>> Hi guys, >>>> Is setting the OUTBOUND parameter to FromDevice to "true" out of the >>>> question for you? >>>> >>>> In practice, you don't expect the monitor device to receive packets >>>> from anyone else than click, so FromDevice(...OUTBOUND true) will only >>>> emit rx packets and tx feedback packets. Wouldn't that solve your >>>> problem? >>>> >>>> --Szymon >>>> >>>> >>>> 2009/7/26 Javier Sánchez <[email protected]>: >>>>> Hi Robert, >>>>> >>>>> I have something. I created a fromdevice2 element that pushes pkttype >>>>> == PACKET_OUTGOING packets, and a radiotapdecap2 element that process >>>>> radiotap tx feedbacks packets, these tx feedback packets are using a >>>>> radiotap tx header (is different from the typical radiotap rx header). >>>>> >>>>> Use: >>>>> >>>>> from_dev :: FromDevice2($DEVICE, PROMISC true) >>>>> from_dev[0] -> ... //process normal packets >>>>> from_dev[1] -> Discard; >>>>> from_dev[2] -> RadiotapDecap2(DEBUG true) -> Discard; //process tx >>>>> feedback packets >>>>> >>>>> >>>>> The RadiotapDecap2 is not finished because i am only interested in >>>>> retries. But if u look at the code it should be easy to complete. >>>>> >>>>> >>>>> >>>>> On Sun, Jul 26, 2009 at 12:56 AM, Robert >>>>> Sombrutzki<[email protected]> wrote: >>>>>> Hi Javier, >>>>>> did you solve the problem with txfeedback-packets ? I had the same >>>>>> problem >>>>>> with Madwifi and Click. My solution was to change the packettype in the >>>>>> madwifi-driver. I changed the packettype for feedback-packets to >>>>>> PACKET_OTHERHOST in the madwifi-driver and it works. But i think, that's >>>>>> not >>>>>> the right way. However, in early madwifi-versions ( e.g. 0.9.1.), the >>>>>> packettype for all received or feedbacked packets in monitormode is >>>>>> PACKET_OTHERHOST. >>>>>> Did you find any other solutions ?? >>>>>> >>>>>> Best regards, >>>>>> Robert >>>>>> >>>>>> Patch for packettype -> PACKET_OTHERHOST; >>>>>> >>>>>> diff --git a/net80211/ieee80211_monitor.c b/net80211/ieee80211_monitor.c >>>>>> index 3b3f65a..71dac5d 100644 >>>>>> --- a/net80211/ieee80211_monitor.c >>>>>> +++ b/net80211/ieee80211_monitor.c >>>>>> @@ -350,7 +353,8 @@ ieee80211_input_monitor(struct ieee80211com *ic, >>>>>> struct >>>>>> sk_buff *skb, >>>>>> * on the contents of the frame to set pkttype. >>>>>> */ >>>>>> if (tx) >>>>>> - pkttype = PACKET_OUTGOING; >>>>>> + //pkttype = PACKET_OUTGOING; >>>>>> + pkttype = PACKET_OTHERHOST; >>>>>> else if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { >>>>>> if (IEEE80211_ADDR_EQ(wh->i_addr1, >>>>>> dev->broadcast)) >>>>>> pkttype = PACKET_BROADCAST; >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>Madwifi driver is forwading a tx packet with some stats into monitor >>>>>>>device each time it transmits a packet (or fails). >>>>>>> >>>>>>>The problem is that this packet is pkttype == PACKET_OUTGOING and >>>>>>>fromdevice element is not processing it. It is possible that other >>>>>>>drivers have this behavior too. >>>>>>> >>>>>>>May be an optional output to fromdevice element may be useful for this >>>>>>>packets? >>>>>>> >>>>>>>Regards >>>>>>>Javier >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
