2013-01-28 09:33:53

by Erwin Van de Velde

[permalink] [raw]
Subject: ath9k has buggy promiscuous mode

Dear all,

When using promiscuous mode on a ath9k chipset, it does not capture
packets from the access point to other stations.

e.g. a ping from S to T over AP results in:
echo request S -> AP
echo reply AP -> S

Where echo request AP -> T is missing.

System:
Linux openWRT 3.3.8
driver: ath9k

Best regards,
Erwin



2013-01-30 15:43:49

by Kalle Valo

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

Erwin Van de Velde <[email protected]> writes:

> On Wednesday 30 January 2013 16:17:25 Kalle Valo wrote:
>> I don't understand, what do you mean software configuration?
>>
>> A quick grep show that at least ath9k checks for the promisc filter:
>>
>> ath9k/htc_drv_main.c: (FIF_PROMISC_IN_BSS | \
>> ath9k/htc_drv_txrx.c: * Set promiscuous mode when
> FIF_PROMISC_IN_BSS
>> is enabled for station
>> ath9k/htc_drv_txrx.c: (priv->rxfilter & FIF_PROMISC_IN_BSS)) ||
>> ath9k/main.c: (FIF_PROMISC_IN_BSS | \
>> ath9k/recv.c: * Set promiscuous mode when FIF_PROMISC_IN_BSS is
>> enabled for station
>
> I tried understanding the code, but it is hard without decent study of
> course. FIF_PROMISC IN BSS I saw there in comment, but not in the code
> :-) For monitor mode there is something like:
>
> if (sc->sc_ah->is_monitoring)
> rfilt |= ATH9K_RX_FILTER_PROM;

To be honest I don't know ath9k at all and I don't have time to look at
it either. I think we need to hope that either Shafi or Sujith notices
this thread and jump in.

Or you could try to debug it yourself. Sprinkle printks everywhere and
see what's happening inside the driver :)

--
Kalle Valo

2013-01-28 14:20:52

by Kalle Valo

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

Erwin Van de Velde <[email protected]> writes:

> When using promiscuous mode on a ath9k chipset, it does not capture
> packets from the access point to other stations.
>
> e.g. a ping from S to T over AP results in:
> echo request S -> AP
> echo reply AP -> S
>
> Where echo request AP -> T is missing.

How did you test this exactly? If you just do 'tcpdump -i wlan0' in
managed mode which is expected. If you use monitor mode (iw wlan0 set
type monitor) when you would see all frames in the air.

--
Kalle Valo

2013-01-30 14:10:31

by Kalle Valo

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

Erwin Van de Velde <[email protected]> writes:

> On Monday 28 January 2013 16:20:50 Kalle Valo wrote:
>> How did you test this exactly? If you just do 'tcpdump -i wlan0' in
>> managed mode which is expected. If you use monitor mode (iw wlan0
> set
>> type monitor) when you would see all frames in the air.
>
> I am using tcpdump with the interface in promiscuous mode (not monitor).
> Tested with another driver, data frames from the access point to another
> station are captured as is expected in promiscuous mode. Only ath9k fails
> to do this (other drivers: ralink2800 and iwlwifi).

Heh, I didn't even know we support that. Thanks for educating me :)

--
Kalle Valo

2013-01-30 14:17:26

by Kalle Valo

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

Erwin Van de Velde <[email protected]> writes:

> I have had a look at the source code of the driver and as far as I can see,
> the driver just never looks at the software configuration when enabling
> promiscuous mode and thus does not pass this information to the
> system, which explains why packets are never captured in promiscuous
> mode, even when the user configures the interface that way.

I don't understand, what do you mean software configuration?

A quick grep show that at least ath9k checks for the promisc filter:

ath9k/htc_drv_main.c: (FIF_PROMISC_IN_BSS | \
ath9k/htc_drv_txrx.c: * Set promiscuous mode when FIF_PROMISC_IN_BSS
is enabled for station
ath9k/htc_drv_txrx.c: (priv->rxfilter & FIF_PROMISC_IN_BSS)) ||
ath9k/main.c: (FIF_PROMISC_IN_BSS | \
ath9k/recv.c: * Set promiscuous mode when FIF_PROMISC_IN_BSS is
enabled for station

--
Kalle Valo

2013-01-30 10:09:36

by Erwin Van de Velde

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

Hi,

I have had a look at the source code of the driver and as far as I can see,
the driver just never looks at the software configuration when enabling
promiscuous mode and thus does not pass this information to the
system, which explains why packets are never captured in promiscuous
mode, even when the user configures the interface that way.

After that I got a bit lost, so is there anyone who can help me fixing this
bug?

Best regards,
Erwin


2013-01-30 14:56:39

by Erwin Van de Velde

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

On Wednesday 30 January 2013 16:17:25 Kalle Valo wrote:
> I don't understand, what do you mean software configuration?
>
> A quick grep show that at least ath9k checks for the promisc filter:
>
> ath9k/htc_drv_main.c: (FIF_PROMISC_IN_BSS | \
> ath9k/htc_drv_txrx.c: * Set promiscuous mode when
FIF_PROMISC_IN_BSS
> is enabled for station
> ath9k/htc_drv_txrx.c: (priv->rxfilter & FIF_PROMISC_IN_BSS)) ||
> ath9k/main.c: (FIF_PROMISC_IN_BSS | \
> ath9k/recv.c: * Set promiscuous mode when FIF_PROMISC_IN_BSS is
> enabled for station

I tried understanding the code, but it is hard without decent study of
course. FIF_PROMISC IN BSS I saw there in comment, but not in the code
:-) For monitor mode there is something like:

if (sc->sc_ah->is_monitoring)
rfilt |= ATH9K_RX_FILTER_PROM;

Best regards,
Erwin



2013-01-28 14:35:25

by Erwin Van de Velde

[permalink] [raw]
Subject: Re: ath9k has buggy promiscuous mode

On Monday 28 January 2013 16:20:50 Kalle Valo wrote:
> How did you test this exactly? If you just do 'tcpdump -i wlan0' in
> managed mode which is expected. If you use monitor mode (iw wlan0
set
> type monitor) when you would see all frames in the air.

I am using tcpdump with the interface in promiscuous mode (not monitor).
Tested with another driver, data frames from the access point to another
station are captured as is expected in promiscuous mode. Only ath9k fails
to do this (other drivers: ralink2800 and iwlwifi).

Best regards,
Erwin