I added some debugging code to __ieee80211_rx() and I noticed in this loop:
list_for_each_entry(sdata, &local->sub_if_list, list) {
that my adapter has two interfaces, not one like I expected. I have
the adapter in monitor mode. In the loop the first interface is
IEEE80211_IF_TYPE_AP and the second is IEEE80211_IF_TYPE_MNTR.
iwconfig only shows the monitor mode interface like I expected.
--
Jon Smirl
[email protected]
On 7/7/07, Ivo van Doorn <[email protected]> wrote:
> On Friday 06 July 2007, Jon Smirl wrote:
> > On 7/6/07, Ivo van Doorn <[email protected]> wrote:
> > > On Friday 06 July 2007, Jon Smirl wrote:
> > > > On 7/6/07, Johannes Berg <[email protected]> wrote:
> > > > > On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
> > > > >
> > > > > > Yes, only interface is monitor.
> > > > > >
> > > > > > Here is something else that is odd.
> > > > > >
> > > > > > Beacons are reporting channel 1...
> > > > > >
> > > > > > But I am tuned to channel 10.
> > > > >
> > > > > That's fishy. What hardware?
> > > >
> > > > Ralink rt2x00usb
> > >
> > > Thats odd, are only beacons reported to be on channel 1?
> > > Because the channel for rx frames is automatically set when
> > > the channel is configured by mac80211.
> >
> > The channel field appears to be uninitialized for beacon frames. When
> > I booted this time it is displaying channel 9 and I am on channel 10.
> >
> > Other frames show channel 10 as expected.
>
> Which is quite weird since the beacon frames use the same rx_status structure
> as the regular frames. No distinction is made within rt2x00 between rx frames...
>
> Ivo
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I'm not sure if this is relevant but:
It is normal to hear beacons for adjacent channel on 2.4 spectrum as
channel overlaps. One must read DS information element from the beacon
to determine on which channel the beacon was really sent.
On Fri, 2007-07-06 at 09:00 -0400, Jon Smirl wrote:
> > That's fishy. What hardware?
>
> Ralink rt2x00usb
Oh. I never had good experience with that. Talk to Ivo?
johannes
On Sat, 2007-07-07 at 11:46 +0200, Ivo van Doorn wrote:
> Well that wouldn't explain why the bug that Jon experiences occurs since that
> would mean that beacons from from example coming from channel 9 are reported
> to come from channel 10.
Sometimes you see across two channels, but never 10 :)
> But if it should be read from the beacon itself,
No, the radiotap info definitely should not be read from the beacon. The
MLME must adhere to what the beacon says, but for monitoring/radiotap
you're absolutely right: just specify what the card was tuned to.
johannes
On 7/6/07, Michael Wu <[email protected]> wrote:
> On Thursday 05 July 2007 06:32, Jon Smirl wrote:
> > I'm debugging this because I've been trying for two days without
> > success to get monitor mode to work. I have the adapter in promisc
> > mode and the interface in monitor mode. I can see directed and
> > broadcast traffic with tcpdump, but not directed traffic for other
> > nodes.
> >
> Outgoing packets from the wireless adapter are not reported unless you have
> Johannes' radiotap patches. Is that what you're talking about?
No, At the interface I am only seeing incoming packets that are to my
mac address or a multicast address. It is like the interface is not in
promiscous mode, but ifconfig shows PROMISC set.
Packets to other mac addresses are arriving at the receiver and I can
trace them up to ieee80211_rx_monitor and onto netif_rx. Something in
the higher level networking code is filtering out these promiscuous
packets; but I don't know what was is doing it. It's not iptables
which it isn't loaded.
My ethernet adapters work fine in promiscuous mode. I have the same
wireless PROMISC problem on both ralink and zd1211 adapters.
Using the wireless-dev tree and wireless_tools.29. Wireless interface
is in monitor mode.I'm using tcpdump -i wlan0 -v to to look for the
packets.
wlan0 Link encap:UNSPEC HWaddr
00-15-E9-2D-76-57-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:135 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:11610 (11.3 KiB) TX bytes:0 (0.0 b)
wlan0 IEEE 802.11g Mode:Monitor Frequency:2.457 GHz
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
--
Jon Smirl
[email protected]
On Wednesday 04 July 2007 17:23, Jon Smirl wrote:
> I added some debugging code to __ieee80211_rx() and I noticed in this loop:
> list_for_each_entry(sdata, &local->sub_if_list, list) {
>
sub_if_list includes the master interface.
-Michael Wu
On 7/6/07, Johannes Berg <[email protected]> wrote:
> On Fri, 2007-07-06 at 08:33 -0400, Jon Smirl wrote:
>
> > Packets to other mac addresses are arriving at the receiver and I can
> > trace them up to ieee80211_rx_monitor and onto netif_rx. Something in
> > the higher level networking code is filtering out these promiscuous
> > packets; but I don't know what was is doing it. It's not iptables
> > which it isn't loaded.
>
> That's odd because it works for everybody else. Have you tried with
> *only* a monitor interface?
Yes, only interface is monitor.
Here is something else that is odd.
Beacons are reporting channel 1...
08:52:41.922526 1.0 Mb/s 2457 MHz (0x0480) 36dB signal 0us Beacon
(Smirl) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 1, PRIVACY
08:52:42.024888 1.0 Mb/s 2457 MHz (0x0480) 35dB signal 0us Beacon
(Smirl) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 1, PRIVACY
08:52:42.127247 1.0 Mb/s 2457 MHz (0x0480) 36dB signal 0us Beacon
(Smirl) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 1, PRIVACY
08:52:42.229737 1.0 Mb/s 2457 MHz (0x0480) 36dB signal 0us Beacon
(Smirl) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 1, PRIVACY
But I am tuned to channel 10.
wlan0 IEEE 802.11g Mode:Monitor Frequency:2.457 GHz
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> johannes
>
>
--
Jon Smirl
[email protected]
On Thu, 2007-07-05 at 09:57 -0400, John W. Linville wrote:
> Actually, the new multiqueue stuff should enable us to get rid of the
> master interface. The queueing currently associated with the master
> interface should look like hardware queueing to the networking core.
> The fact that it is implemented in software is just an implementation
> detail.
I don't think so, it will allow us to have multiple queues per device
but not allow having a single qdisc see *all* traffic from all virtual
interfaces. But if you can make it work I'm all ears :)
johannes
On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
> Yes, only interface is monitor.
>
> Here is something else that is odd.
>
> Beacons are reporting channel 1...
>
> But I am tuned to channel 10.
That's fishy. What hardware?
johannes
On Thu, Jul 05, 2007 at 02:34:05PM +0200, Johannes Berg wrote:
> On Thu, 2007-07-05 at 15:30 +0300, Tomas Winkler wrote:
> > Does anybody have/ think of a patch that removes the master interface
> > from the sub_if_list. It slows down the receive path.
>
> Actually, we want to get rid of it completely. The missing piece to that
> is decoupling qdiscs from netdevs.
Actually, the new multiqueue stuff should enable us to get rid of the
master interface. The queueing currently associated with the master
interface should look like hardware queueing to the networking core.
The fact that it is implemented in software is just an implementation
detail.
John
--
John W. Linville
[email protected]
On Fri, 2007-07-06 at 09:22 -0400, Jon Smirl wrote:
> On 7/6/07, Johannes Berg <[email protected]> wrote:
> > On Fri, 2007-07-06 at 09:00 -0400, Jon Smirl wrote:
> >
> > > > That's fishy. What hardware?
> > >
> > > Ralink rt2x00usb
> >
> > Oh. I never had good experience with that. Talk to Ivo?
>
> What is the most reliable hardware for monitor mode? I have PCI and
> USB on my desktop. I need something that I know works so that I can
> debug these other adapters that aren't working quite right.
I find that bcm43xx (I have a bcm4306) works quite reliably in monitor
mode and even gives you control packets and can also pass up frames with
broken CRC if required
johannes
Does anybody have/ think of a patch that removes the master interface
from the sub_if_list. It slows down the receive path. Second problem
with this is that the code becomes incorrect when opening receive path
for control packets. Meanwhile as a workaround I've changed iw_mode
of the master interface to invalid value instead of default
IEEE80211_IF_TYPE_AP.
On 7/5/07, Michael Wu <[email protected]> wrote:
> On Wednesday 04 July 2007 17:23, Jon Smirl wrote:
> > I added some debugging code to __ieee80211_rx() and I noticed in this loop:
> > list_for_each_entry(sdata, &local->sub_if_list, list) {
> >
> sub_if_list includes the master interface.
>
> -Michael Wu
>
>
On Friday 06 July 2007, Jon Smirl wrote:
> On 7/6/07, Johannes Berg <[email protected]> wrote:
> > On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
> >
> > > Yes, only interface is monitor.
> > >
> > > Here is something else that is odd.
> > >
> > > Beacons are reporting channel 1...
> > >
> > > But I am tuned to channel 10.
> >
> > That's fishy. What hardware?
>
> Ralink rt2x00usb
Thats odd, are only beacons reported to be on channel 1?
Because the channel for rx frames is automatically set when
the channel is configured by mac80211.
Directly after rt2x00lib has send the channel switch event to the
driver the rt2x00dev->rx_status.channel value is updated...
Ivo
On Thursday 05 July 2007 06:32, Jon Smirl wrote:
> I'm debugging this because I've been trying for two days without
> success to get monitor mode to work. I have the adapter in promisc
> mode and the interface in monitor mode. I can see directed and
> broadcast traffic with tcpdump, but not directed traffic for other
> nodes.
>
Outgoing packets from the wireless adapter are not reported unless you have
Johannes' radiotap patches. Is that what you're talking about?
-Michael Wu
On 7/6/07, Ivo van Doorn <[email protected]> wrote:
> On Friday 06 July 2007, Jon Smirl wrote:
> > On 7/6/07, Johannes Berg <[email protected]> wrote:
> > > On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
> > >
> > > > Yes, only interface is monitor.
> > > >
> > > > Here is something else that is odd.
> > > >
> > > > Beacons are reporting channel 1...
> > > >
> > > > But I am tuned to channel 10.
> > >
> > > That's fishy. What hardware?
> >
> > Ralink rt2x00usb
>
> Thats odd, are only beacons reported to be on channel 1?
> Because the channel for rx frames is automatically set when
> the channel is configured by mac80211.
The channel field appears to be uninitialized for beacon frames. When
I booted this time it is displaying channel 9 and I am on channel 10.
Other frames show channel 10 as expected.
>
> Directly after rt2x00lib has send the channel switch event to the
> driver the rt2x00dev->rx_status.channel value is updated...
>
> Ivo
>
--
Jon Smirl
[email protected]
On 7/6/07, Johannes Berg <[email protected]> wrote:
> On Fri, 2007-07-06 at 09:00 -0400, Jon Smirl wrote:
>
> > > That's fishy. What hardware?
> >
> > Ralink rt2x00usb
>
> Oh. I never had good experience with that. Talk to Ivo?
What is the most reliable hardware for monitor mode? I have PCI and
USB on my desktop. I need something that I know works so that I can
debug these other adapters that aren't working quite right.
>
> johannes
>
>
--
Jon Smirl
[email protected]
On Thu, 2007-07-05 at 15:30 +0300, Tomas Winkler wrote:
> Does anybody have/ think of a patch that removes the master interface
> from the sub_if_list. It slows down the receive path.
Actually, we want to get rid of it completely. The missing piece to that
is decoupling qdiscs from netdevs.
johannes
On Friday 06 July 2007, Jon Smirl wrote:
> On 7/6/07, Ivo van Doorn <[email protected]> wrote:
> > On Friday 06 July 2007, Jon Smirl wrote:
> > > On 7/6/07, Johannes Berg <[email protected]> wrote:
> > > > On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
> > > >
> > > > > Yes, only interface is monitor.
> > > > >
> > > > > Here is something else that is odd.
> > > > >
> > > > > Beacons are reporting channel 1...
> > > > >
> > > > > But I am tuned to channel 10.
> > > >
> > > > That's fishy. What hardware?
> > >
> > > Ralink rt2x00usb
> >
> > Thats odd, are only beacons reported to be on channel 1?
> > Because the channel for rx frames is automatically set when
> > the channel is configured by mac80211.
>
> The channel field appears to be uninitialized for beacon frames. When
> I booted this time it is displaying channel 9 and I am on channel 10.
>
> Other frames show channel 10 as expected.
Which is quite weird since the beacon frames use the same rx_status structure
as the regular frames. No distinction is made within rt2x00 between rx frames...
Ivo
On Fri, 2007-07-06 at 08:33 -0400, Jon Smirl wrote:
> Packets to other mac addresses are arriving at the receiver and I can
> trace them up to ieee80211_rx_monitor and onto netif_rx. Something in
> the higher level networking code is filtering out these promiscuous
> packets; but I don't know what was is doing it. It's not iptables
> which it isn't loaded.
That's odd because it works for everybody else. Have you tried with
*only* a monitor interface?
johannes
On 7/6/07, Johannes Berg <[email protected]> wrote:
> On Fri, 2007-07-06 at 08:55 -0400, Jon Smirl wrote:
>
> > Yes, only interface is monitor.
> >
> > Here is something else that is odd.
> >
> > Beacons are reporting channel 1...
> >
> > But I am tuned to channel 10.
>
> That's fishy. What hardware?
Ralink rt2x00usb
>
> johannes
>
>
--
Jon Smirl
[email protected]
On 7/5/07, Tomas Winkler <[email protected]> wrote:
> Does anybody have/ think of a patch that removes the master interface
> from the sub_if_list. It slows down the receive path. Second problem
> with this is that the code becomes incorrect when opening receive path
> for control packets. Meanwhile as a workaround I've changed iw_mode
> of the master interface to invalid value instead of default
> IEEE80211_IF_TYPE_AP.
I'm debugging this because I've been trying for two days without
success to get monitor mode to work. I have the adapter in promisc
mode and the interface in monitor mode. I can see directed and
broadcast traffic with tcpdump, but not directed traffic for other
nodes.
I've added debug printk to mac80211 and the non-directed packets are
making it to
ieee80211_rx_monitor and onto netif_rx. But they don't come out the
tcpdump interface. I don't have iptables loaded. What's eating these
packets in the higher layers?
>
>
> On 7/5/07, Michael Wu <[email protected]> wrote:
> > On Wednesday 04 July 2007 17:23, Jon Smirl wrote:
> > > I added some debugging code to __ieee80211_rx() and I noticed in this loop:
> > > list_for_each_entry(sdata, &local->sub_if_list, list) {
> > >
> > sub_if_list includes the master interface.
> >
> > -Michael Wu
> >
> >
>
--
Jon Smirl
[email protected]
Hi,
> > > The channel field appears to be uninitialized for beacon frames. When
> > > I booted this time it is displaying channel 9 and I am on channel 10.
> > >
> > > Other frames show channel 10 as expected.
> >
> > Which is quite weird since the beacon frames use the same rx_status structure
> > as the regular frames. No distinction is made within rt2x00 between rx frames...
> >
> > Ivo
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> I'm not sure if this is relevant but:
> It is normal to hear beacons for adjacent channel on 2.4 spectrum as
> channel overlaps. One must read DS information element from the beacon
> to determine on which channel the beacon was really sent.
Well that wouldn't explain why the bug that Jon experiences occurs since that
would mean that beacons from from example coming from channel 9 are reported
to come from channel 10.
But if it should be read from the beacon itself, then it would be the work for mac80211
to do that. Since the drivers will have to do as little as possible with the frame contents.
Ivo