Re: [Madwifi-devel] turn off "local echo"?

[Dennis B. <den...@go...>]

Hi Frank, dear list,

that exactly does the job! Thanks a lot!

Dennis

Frank A. Zdarsky schrieb:
> Hi Dennis,
>
> I assume you're using a raw socket to inject/read frames to/from the
> device in monitor mode? All frames that you transmit on this socket and
> that get looped back to it should have their packet type set to
> PACKET_OUTGOING (see the man page for PF_PACKET).
>
> As the MadWifi driver implements this behavior (see
> net80211/ieee80211_monitor.c), you could simply filter out all frames
> for which "ssl_pkttype == PACKET_OUTGOING" in the "struct sockaddr*"
> returned by recvfrom().
>
> Good luck!
>
> -- Frank
>
>
> On Tue, 21 Aug 2007 10:52:54 +0200, Dennis Borgmann wrote:
>   
>> Hello Steve,
>>
>> just to confirm your hint: you want me to #ifdef the whole body of the
>> function
>>
>> static void ath_tx_capture(struct net_device *dev, struct ath_desc *ds,
>> struct sk_buff *skb)
>>
>> inside ath/if_ath.c except the last call of
>>
>> dev_kfree_skb(skb);
>>
>> Is that right? So if the function is called, only the call
>>
>> dev_kfree_skb(skb)
>>
>> is performed?
>>
>> Kind greetings from Germany,
>> Dennis
>>
>> Steve Glass schrieb:
>>     
>>> Hi Dennis
>>>
>>> I had *exactly* the same problem as you. The tx capture breaks the
>>> semantics of the linux packet socket and the default behaviour is
>>> totally wrong. The problem is that the packet socket is intended to
>>> let developers test new protocols in user mode and normally we never
>>> see what we've written appear on the input.
>>>
>>> The reason for the tx capture is that you can see injected packets in
>>> a sniffer. BSD has an ioctl to enable this behaviour but here madwifi
>>> does the wrong thing by default. A side effect is that sniffing seems
>>> to show negative timestamps because transmitted frames are read with
>>> the timestamp when they were queued. Anyway... enough of my whinge I
>>> have some help for you...
>>>
>>> I think commenting out the call to ath_tx_capture will cause you to
>>> leak sk_buffs. You can #ifdef the body of the function except the
>>> final skb_free call. That way the sk_buff that's been allocated is
>>> discarded properly.
>>>
>>> All the best
>>>
>>> Steve
>>>
>>> On 8/20/07, *Dennis Borgmann* <den...@go...
>>> <mailto:den...@go...>> wrote:
>>>
>>>     Hi Wenhua,
>>>
>>>     thank you for your answer. I will give it a try!
>>>
>>>     Dennis
>>>
>>>     Wenhua Zhao schrieb:
>>>     > Hi Dennis,
>>>     >
>>>     > On 8/17/07, Dennis Borgmann <den...@go...
>>>     <mailto:den...@go...>> wrote:
>>>     >
>>>     >> Hi list,
>>>     >>
>>>     >> I am injecting packets in monitor mode and I just recognized,
>>>     that I
>>>     >> receive packets, which I transmit on my own. So the frames,
>>>     that are
>>>     >> pumped out of the wireless-device reach the device as
>>>     well,meaning they
>>>     >> can be read off that device after being sent out into the air.
>>>     >>
>>>     >> Is there an option to switch this functionality off?
>>>     >>
>>>     >> Thanks in advance,
>>>     >>
>>>     >> Dennis
>>>     >>
>>>     >>
>>>     >
>>>     > Normally, if you have a monitor virtual interface on one physical
>>>     > device,  all packets send through this device will be fed back
>>>     to the
>>>     > monitor virtual interface.
>>>     >
>>>     > (If there are two physical devices but only one physical device
>>>     has a
>>>     > monitor interface, then packets send by another device should NOT be
>>>     > `heard' by the monitor.  Anyone can confirm this?)
>>>     >
>>>     > If you really don't want the monitor receive the transmitted packet,
>>>     > you can try to comment out the function calls `ath_tx_capture()' in
>>>     > `if_ath.c:ath_tx_processq()' .  Note that if you have ATH_SUPERG_FF
>>>     > defined, which is true by default, you need to comment out that
>>>     block
>>>     > of code.
>>>     >
>>>     > Hope it works.
>>>     >
>>>     > Regards,
>>>     > Wenhua
>>>     >
>>>     >
>>>       
>
>
>