[Click] MADWIFI TX feedback packets

Szymon Jakubczak szym at mit.edu
Mon Jul 27 10:43:53 EDT 2009


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 <javier.recacha at gmail.com>:
> 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 <szym at mit.edu>:
>> 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 <javier.recacha at gmail.com>:
>>> 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<szym at mit.edu> 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 <javier.recacha at gmail.com>:
>>>>> 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<sombrutz at informatik.hu-berlin.de> 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
>>>>> click at amsterdam.lcs.mit.edu
>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>
>>>>>
>>>>
>>>
>>
>



More information about the click mailing list