No, is some type of broken packet, no contents , header content to 0, incorrect length... i don't know what is it. But is ugly to see on tcpdump.
Anyway, doesn't matter, the problem is minor and the packet is easy filtered (custom filter or FilterTX element). Tomorrow i will look at it. Thx for this TX feedback simpler solution, Robert is reporting that it works well !! Regards, Javier 2009/7/27 Szymon Jakubczak <[email protected]>: > 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
