Ivo van Doorn <ivdoorn@...> writes:
> Could you enable debugfs and use the tools here:
> http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
>
> To create a dump of the frames as they are actually send out from the driver
> to the hardware including the status report. This will tell if rt2x00 is
> actually bringing the frame to the hardware correctly.
>
I think you've got that back to front - If I'm reading the
thread correctly the suspicion is the data is being transmitted
correctly by the remote end and is being lost somehere between
the rt2500pci antenna and user space.
The tools would still be helpful to see if a packet is being
received by the hardware and lost in the stack (maybe it doesn't
like something about the received packet) or if it is not even
getting as far as the rt2x00 driver.
> > this is the flag status when running hostapd; as printed with
> > printk(KERN_INFO "rt2500pci filter_flags: %d\n",
> > rt2x00dev->packet_filter);
> >
> > rt2500pci filter_flags: 2
> > rt2500pci MAC changed: 00:0c:f6:14:05:19
>
> Packet filter flags of 2 sounds a bit restrictive.
>
> Johannes, for Master mode shouldn't the following flags be set as well:
> FIF_PROMISC_IN_BSS
> FIF_CONTROL
>
Ivo,
Don't forget that there was no response to the request for someone to test
if broadcast packets were received in monitor mode on the older hardware
so if the filter flags don't select multicast traffic we could be losing
broadcast traffic too. I'm not sure if the stack will be reporting any
active multicast groups in AP mode. (For the benefit of others the only
reason normal broadcast traffic was working was because there was always a
multicast group present, Ivo's request is linked below.)
http://sourceforge.net/mailarchive/forum.php?thread_name=200803031921.41634.IvDoorn%40gmail.com&forum_name=rt2400-devel
On Sun, 2008-03-30 at 18:32 +0200, Bas Hulsken wrote:
> I've made the dumps you've asked for; at least I think so:
> '/debug/ieee80211/phy2/rt2500pci/frame/dump' as mentioned in the rt2wtap
> doc does not exist for me, so I've captured from:
> '/debug/ieee80211/phy1/rt2500pci/queue/dump' is that the new name or
> something?
Yes. I need to update the documentation :-)
Mattias
Hi Adam, Ivo,
On Sat, 2008-03-29 at 23:45 +0000, Adam Baker wrote:
> Ivo van Doorn <ivdoorn@...> writes:
>
>
> > Could you enable debugfs and use the tools here:
> > http://www-user.rhrk.uni-kl.de/~nissler/rt2x00/index.html
> >
> > To create a dump of the frames as they are actually send out from the driver
> > to the hardware including the status report. This will tell if rt2x00 is
> > actually bringing the frame to the hardware correctly.
> >
>
> I think you've got that back to front - If I'm reading the
> thread correctly the suspicion is the data is being transmitted
> correctly by the remote end and is being lost somehere between
> the rt2500pci antenna and user space.
>
> The tools would still be helpful to see if a packet is being
> received by the hardware and lost in the stack (maybe it doesn't
> like something about the received packet) or if it is not even
> getting as far as the rt2x00 driver.
>
you're right Adam, it's the receiving part where it goes wrong, anyway,
I've managed to enable debugfs, and the above mentioned tools, so I'll
do some captures today for both normal and promiscuous mode, to see if,
and why/how/where packets get lost.
> Ivo,
> Don't forget that there was no response to the request for someone to test
> if broadcast packets were received in monitor mode on the older hardware
> so if the filter flags don't select multicast traffic we could be losing
> broadcast traffic too. I'm not sure if the stack will be reporting any
> active multicast groups in AP mode. (For the benefit of others the only
> reason normal broadcast traffic was working was because there was always a
> multicast group present, Ivo's request is linked below.)
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=200803031921.41634.IvDoorn%40gmail.com&forum_name=rt2400-devel
>
I would like to test for this, but I'm not quite sure how, I've read
Ivo's original message, but I can't find the monitoring bug discussion
Ivo is referring to. Would the frame captures on debugfs, again with the
above mentioned tools test for this bug as well? Or is there something
else I have to do?
thanks,
Bas Hulsken
Hi,
> > Ivo,
> > Don't forget that there was no response to the request for someone to test
> > if broadcast packets were received in monitor mode on the older hardware
> > so if the filter flags don't select multicast traffic we could be losing
> > broadcast traffic too. I'm not sure if the stack will be reporting any
> > active multicast groups in AP mode. (For the benefit of others the only
> > reason normal broadcast traffic was working was because there was always a
> > multicast group present, Ivo's request is linked below.)
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_name=200803031921.41634.IvDoorn%40gmail.com&forum_name=rt2400-devel
> >
> I would like to test for this, but I'm not quite sure how, I've read
> Ivo's original message, but I can't find the monitoring bug discussion
> Ivo is referring to. Would the frame captures on debugfs, again with the
> above mentioned tools test for this bug as well? Or is there something
> else I have to do?
So far I have received 1 result for the above test request which indicated rt2500pci
wasn't harmed with this bug. However, latest rt2x00 has Adam's patch active for
all rt2x00 drivers (since the code is now handled in rt2x00mac.c).
So this means that that multicast bug should have no influence for this bug.
Ivo
Hi,
On Sun, 2008-03-30 at 15:27 +0200, Ivo van Doorn wrote:
> > > Don't forget that there was no response to the request for someone to test
> > > if broadcast packets were received in monitor mode on the older hardware
> > > so if the filter flags don't select multicast traffic we could be losing
> > > broadcast traffic too. I'm not sure if the stack will be reporting any
> > > active multicast groups in AP mode. (For the benefit of others the only
> > > reason normal broadcast traffic was working was because there was always a
> > > multicast group present, Ivo's request is linked below.)
> > >
> > > http://sourceforge.net/mailarchive/forum.php?thread_name=200803031921.41634.IvDoorn%40gmail.com&forum_name=rt2400-devel
> > >
> > I would like to test for this, but I'm not quite sure how, I've read
> > Ivo's original message, but I can't find the monitoring bug discussion
> > Ivo is referring to. Would the frame captures on debugfs, again with the
> > above mentioned tools test for this bug as well? Or is there something
> > else I have to do?
>
> So far I have received 1 result for the above test request which indicated rt2500pci
> wasn't harmed with this bug. However, latest rt2x00 has Adam's patch active for
> all rt2x00 drivers (since the code is now handled in rt2x00mac.c).
> So this means that that multicast bug should have no influence for this bug.
ok, understood.
I've made the dumps you've asked for; at least I think so:
'/debug/ieee80211/phy2/rt2500pci/frame/dump' as mentioned in the rt2wtap
doc does not exist for me, so I've captured from:
'/debug/ieee80211/phy1/rt2500pci/queue/dump' is that the new name or
something?
anyway, I've made 2 dumps, one of an association attempt with wlan1
_not_ promiscuous (which fails because eapol keys sent by laptop are not
received): hostapd_not_promisc_try2.tar.bz2
and one dump of an association attempt with wlan1 set to promiscuous
(which fails later on, because hostapd locks
up:hostapd_promisc_try1.tar.bz2. BTW, this lockup also seems to affect
the driver state, if I want to use the interface again, I have to
manually unload and reload the rt2500pci module).
the laptop has mac: 00:1b:77:a4:db:26, an the rt2500pci nic in the
server trying to be an accesspoint is 00:0c:f6:14:05:19. So a wireshark
filter like this wlan.da == 00:1b:77:a4:db:26 || wlan.sa ==
00:1b:77:a4:db:26 shows the laptops traffic on the interface.
>From a quick look at the dumps, I found that again EAPOL key response
from the laptop is only received if wlan1 is set to promiscuous. At that
point hostapd locks, and it sends out no more frames. The EAPOL key from
the laptop is at frame 420 and 421 in the dump in
hostapd_promisc_try1.tar.bz2.
well, I hope this can help you, but apparently the missing EAPOL key
packets from the laptop also don't show up in these dumps in the non
promiscuous case. So they apparently get lost before they are captured.
best regards, and many thanks,
Bas Hulsken