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
