[Click] MADWIFI TX feedback packets

[Javier Sánchez]

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
>>
>>
>