[Click] MADWIFI TX feedback packets

[Javier Sánchez]

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 <szym at mit.edu>:
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>