2008-03-23 11:34:25

by Bas Hulsken

[permalink] [raw]
Subject: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous

Hi List,

I'm trying to get my rt2500pci running as an accesspoint. So far with
only very limited success. I'm running the most recent stuff from
git.wireless-testing (mac80211-v2.6.25_rc5_2623_g7556b76_080322-1). I've
applied these patches from Johannes Berg:
006-mac80211-sparse-check-endianness-by-default.patch
008-allow-ap-vlan-modes.patch
009-mac80211-allow-wds.patch

I've tried running hostapd-0.6.2 (patched for nl80211) up to 0.6.4, all
with the same results.

This is the problem, as far as I understand it:

hostapd doesn't receive the EAPOL key from the laptop that is trying to
connect (thinkpad x61s, 00:1b:77:a4:db:26. I've tried connecting from
both fedora8, and windows Vista). While ethereal shows that EAPOL keys
are being sent by the thinkpad. This is what hostapd lists:
wlan1: STA 00:1b:77:a4:db:26 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
wlan1: STA 00:1b:77:a4:db:26 WPA: EAPOL-Key timeout
WPA: 00:1b:77:a4:db:26 WPA_PTK entering state PTKSTART
wlan1: STA 00:1b:77:a4:db:26 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
wlan1: STA 00:1b:77:a4:db:26 WPA: EAPOL-Key timeout

repeated quite a few times, before the thinkpad gives up trying to
associate.

However, if I switch mon.wlan1 on the hostapd accesspoint to
promiscuous, by issuing tethereal -i mon.wlan1, then suddenly hostapd
does receive the EAPOL key from the think pad, and this happens (hostapd
output):

wlan1: STA 00:1b:77:a4:db:26 WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=1 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 123 bytes from 00:1b:77:a4:db:26
IEEE 802.1X: version=1 type=3 length=119
wlan1: STA 00:1b:77:a4:db:26 WPA: received EAPOL-Key frame (2/4
Pairwise)
WPA: 00:1b:77:a4:db:26 WPA_PTK entering state PTKCALCNEGOTIATING
WPA: PTK derivation - A1=00:0c:f6:14:05:19 A2=00:1b:77:a4:db:26
WPA: PMK - hexdump(len=32): [REMOVED]
WPA: PTK - hexdump(len=64): [REMOVED]
WPA: 00:1b:77:a4:db:26 WPA_PTK entering state PTKCALCNEGOTIATING2
WPA: 00:1b:77:a4:db:26 WPA_PTK entering state PTKINITNEGOTIATING

so, now hostapd does receive a keyframe from the thinkpad. Unfortunately
hostapd hangs after "WPA_PTK entering state PTKINITNEGOTIATING", and can
only be terminated with a ctrl-c. In the past (one month ago, hostapd
would continue, and it was actually possible to connect the thinkpad to
hostapd, however I could never connect without making either mon.wlan1
or wlan1 promiscuous by running ethereal on it, and even then I'd get
some kernel OOPSES on heavy traffic). This is the tethereal -i mon.wlan1
output (thinkpad=IntelCor_a4:db:26, hostapd=SitecomE_14:05:19):

17.034743 SitecomE_14:05:19 -> IntelCor_a4:db:26 EAPOL Key
17.034747 SitecomE_14:05:19 -> IntelCor_a4:db:26 EAPOL Key
17.051720 IntelCor_a4:db:26 -> SitecomE_14:05:19 EAPOL Key
27.050899 IntelCor_a4:db:26 -> SitecomE_14:05:19 IEEE 802.11
Disassociate, SN=3012, FN=0, Flags=........
27.051921 IntelCor_a4:db:26 -> SitecomE_14:05:19 IEEE 802.11
Disassociate, SN=3012, FN=0, Flags=....R...
27.080414 IntelCor_a4:db:26 -> SitecomE_14:05:19 IEEE 802.11 Null
function (No data), SN=3013, FN=0, Flags=...P...T
27.264342 IntelCor_a4:db:26 -> SitecomE_14:05:19 IEEE 802.11 Null
function (No data), SN=3014, FN=0, Flags=.......T
27.265133 IntelCor_a4:db:26 -> SitecomE_14:05:19 IEEE 802.11 QoS Null
function (No data), SN=3014, FN=0, Flags=....R..T

The QoS and Null function stuff continues more or less forever.

Ok, to summarize: hostapd doesn't seem to work at the moment with
rt2500pci and lates git.wireless-testing. The cause seems to be that
EOPOL key send from the client does not arrive at hostapd. This can be
'fixed' by running tethereal on the monitor interface. Any thoughts on
what might cause this?

thanks for your time!
best regards,
Bas Hulsken

some additional info:
--------------------------------------------------------------
hostapd.conf:
--------------------------------------------------------------
interface=wlan1
driver=nl80211
logger_syslog=-1
logger_syslog_level=0
logger_stdout=-1
logger_stdout_level=0
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=steadydecline
country_code=NL
hw_mode=g
channel=1
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=2347
fragm_threshold=2346
macaddr_acl=0
accept_mac_file=/etc/hostapd.accept
deny_mac_file=/etc/hostapd.deny
auth_algs=3
ignore_broadcast_ssid=0
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
#ieee8021x=0
eapol_version=1
eap_message=hello
eapol_key_index_workaround=0
own_ip_addr=127.0.0.1
wpa=1
wpa_passphrase=***********
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
supported_rates=10 20 55 110
wpa_group_rekey=600
wpa_strict_rekey=1
wpa_gmk_rekey=86400
--------------------------------------------------------------
ifcfg-wlan1
--------------------------------------------------------------
# RaLink RT2500 802.11g Cardbus/mini-PCI
DEVICE=wlan1
ONBOOT=no
HWADDR=00:0c:f6:14:05:19
BROADCAST=192.168.3.255
IPADDR=192.168.3.1
NETMASK=255.255.255.0
NETWORK=192.168.3.0
IPV6INIT=no
MODE=Master
BOOTPROTO=none
TYPE=Wireless
ESSID=steadydecline
#WIRELESS_RTS=on
RATE=AUTO
MODE=AUTO
CHANNEL=1
--------------------------------------------------------------
iwconfig
--------------------------------------------------------------
wmaster0 no wireless extensions.

wlan1 IEEE 802.11 ESSID:"steadydecline"
Mode:Master Frequency:2.412 GHz Tx-Power=23 dBm
Retry min limit:7 RTS thr=2347 B 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

mon.wlan1 IEEE 802.11 Mode:Monitor Frequency:2.412 GHz Tx-Power=23
dBm
Retry min limit:7 RTS thr=2347 B 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
--------------------------------------------------------------




2008-03-26 18:54:39

by Bas Hulsken

[permalink] [raw]
Subject: Re: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous

Hi Johannes,

don't mean to push you or anything, but I was wondering if you
overlooked my last mail. You asked me to add some printk's to the
rt2500pci driver to debug hostapd authentication failure. I did this,
and these are the results:

upon ifupping the interface:
------------------------------------------------
phy0: Selected rate control algorithm 'pid'
Registered led device: rt2500pci-phy0:radio
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2
ADDRCONF(NETDEV_UP): wlan1: link is not ready
------------------------------------------------
when I run hostapd, this is in dmesg:
------------------------------------------------
rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2
rt2500pci filter_flags: 0
rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2
------------------------------------------------
this is immediately on startup of hostapd, after that filter and MAC
remain unchanged (at least if my printk catches everything).

does this look ok to you? Does it explain why I can only receive EOPOL
keys when in promiscuous mode?

thanks for your help,
Bas



On Sun, 2008-03-23 at 15:14 +0100, Bas Hulsken wrote:
> Hi Johannes,
>
> On Sun, 2008-03-23 at 14:00 +0100, Bas Hulsken wrote:
>
> > before I blow up the system, I guess this should do the trick?
> > (remember, I'm not a kernel hacker ;-):
>
> ok.. so I decided to just give it a try.. seems to work, this is dmesg
> upon ifupping the interface:
>
> phy0: Selected rate control algorithm 'pid'
> Registered led device: rt2500pci-phy0:radio
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2
> ADDRCONF(NETDEV_UP): wlan1: link is not ready
>
> when I run hostapd, this is in dmesg:
>
> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2
> rt2500pci filter_flags: 0
> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2
>
> this is immediately on startup of hostapd, after that filter and MAC
> remain unchanged (at least if my printk catches everything).
>
> thanks,
> Bas
>
>
> --
> 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


2008-03-23 13:04:08

by Bas Hulsken

[permalink] [raw]
Subject: Re: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous

Hi Johannes,

On Sun, 2008-03-23 at 13:12 +0100, Johannes Berg wrote:
> > Ok, to summarize: hostapd doesn't seem to work at the moment with
> > rt2500pci and lates git.wireless-testing. The cause seems to be that
> > EOPOL key send from the client does not arrive at hostapd. This can be
> > 'fixed' by running tethereal on the monitor interface. Any thoughts on
> > what might cause this?
>
> Can you stick a printk into the driver to print out
> * the configured MAC address
> * the filter flags configuration?
>
> Whenever either changes.
before I blow up the system, I guess this should do the trick?
(remember, I'm not a kernel hacker ;-):

--- compat-wireless-2.6/drivers/net/wireless/rt2x00/rt2500pci.c 2008-03-12 09:49:21.000000000 +0100
+++ ./rt2500pci.c 2008-03-23 13:52:55.000000000 +0100
@@ -300,10 +300,11 @@
rt2x00pci_register_write(rt2x00dev, CSR14, reg);
}

- if (flags & CONFIG_UPDATE_MAC)
+ if (flags & CONFIG_UPDATE_MAC) {
rt2x00pci_register_multiwrite(rt2x00dev, CSR3,
conf->mac, sizeof(conf->mac));
-
+ printk(KERN_INFO "rt2500pci MAC changed: %s\n", mac2str(conf->mac));
+ }
if (flags & CONFIG_UPDATE_BSSID)
rt2x00pci_register_multiwrite(rt2x00dev, CSR5,
conf->bssid, sizeof(conf->bssid));
@@ -1767,6 +1768,7 @@
return;
rt2x00dev->packet_filter = *total_flags;

+ printk(KERN_INFO "rt2500pci filter_flags: %d\n", rt2x00dev->packet_filter);
/*
* Start configuration steps.
* Note that the version error will always be dropped


> johannes

oh.. btw, I also had to patch hostapd a bit.. it seemed trivial, but
perhaps I'm just stupid. It seems that the NL80211_STA_STAT_* stuff in
current wireless-testing has been renamed to NL80211_STA_INFO_*, so I
renamed all occurrences of that in driver_nl80211.c. Was that ok? This
is the patch I applied:
--- hostap/hostapd/driver_nl80211.c 2008-03-18 13:53:20.000000000 +0100
+++ ./driver_nl80211.c 2008-03-22 17:28:39.000000000 +0100
@@ -598,11 +598,11 @@
struct nlattr *tb[NL80211_ATTR_MAX + 1];
struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
struct hostap_sta_driver_data *data = arg;
- struct nlattr *stats[NL80211_STA_STAT_MAX + 1];
- static struct nla_policy stats_policy[NL80211_STA_STAT_MAX + 1] = {
- [NL80211_STA_STAT_INACTIVE_TIME] = { .type = NLA_U32 },
- [NL80211_STA_STAT_RX_BYTES] = { .type = NLA_U32 },
- [NL80211_STA_STAT_TX_BYTES] = { .type = NLA_U32 },
+ struct nlattr *stats[NL80211_STA_INFO_MAX + 1];
+ static struct nla_policy stats_policy[NL80211_STA_INFO_MAX + 1] = {
+ [NL80211_STA_INFO_INACTIVE_TIME] = { .type = NLA_U32 },
+ [NL80211_STA_INFO_RX_BYTES] = { .type = NLA_U32 },
+ [NL80211_STA_INFO_TX_BYTES] = { .type = NLA_U32 },
};

nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
@@ -614,24 +614,24 @@
* the kernel starts sending station notifications.
*/

- if (!tb[NL80211_ATTR_STA_STATS]) {
+ if (!tb[NL80211_ATTR_STA_INFO]) {
wpa_printf(MSG_DEBUG, "sta stats missing!");
return NL_SKIP;
}
- if (nla_parse_nested(stats, NL80211_STA_STAT_MAX,
- tb[NL80211_ATTR_STA_STATS],
+ if (nla_parse_nested(stats, NL80211_STA_INFO_MAX,
+ tb[NL80211_ATTR_STA_INFO],
stats_policy)) {
wpa_printf(MSG_DEBUG, "failed to parse nested attributes!");
return NL_SKIP;
}

- if (stats[NL80211_STA_STAT_INACTIVE_TIME])
+ if (stats[NL80211_STA_INFO_INACTIVE_TIME])
data->inactive_msec =
- nla_get_u32(stats[NL80211_STA_STAT_INACTIVE_TIME]);
- if (stats[NL80211_STA_STAT_RX_BYTES])
- data->rx_bytes = nla_get_u32(stats[NL80211_STA_STAT_RX_BYTES]);
- if (stats[NL80211_STA_STAT_TX_BYTES])
- data->rx_bytes = nla_get_u32(stats[NL80211_STA_STAT_TX_BYTES]);
+ nla_get_u32(stats[NL80211_STA_INFO_INACTIVE_TIME]);
+ if (stats[NL80211_STA_INFO_RX_BYTES])
+ data->rx_bytes = nla_get_u32(stats[NL80211_STA_INFO_RX_BYTES]);
+ if (stats[NL80211_STA_INFO_TX_BYTES])
+ data->rx_bytes = nla_get_u32(stats[NL80211_STA_INFO_TX_BYTES]);

return NL_SKIP;
}


cheers,
Bas



2008-03-23 14:25:01

by Bas Hulsken

[permalink] [raw]
Subject: Re: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous

Hi Johannes,

On Sun, 2008-03-23 at 14:00 +0100, Bas Hulsken wrote:

> before I blow up the system, I guess this should do the trick?
> (remember, I'm not a kernel hacker ;-):

ok.. so I decided to just give it a try.. seems to work, this is dmesg
upon ifupping the interface:

phy0: Selected rate control algorithm 'pid'
Registered led device: rt2500pci-phy0:radio
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2
ADDRCONF(NETDEV_UP): wlan1: link is not ready

when I run hostapd, this is in dmesg:

rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2
rt2500pci filter_flags: 0
rt2500pci MAC changed: 00:00:00:00:00:00
rt2500pci MAC changed: 00:0c:f6:14:05:19
rt2500pci filter_flags: 2

this is immediately on startup of hostapd, after that filter and MAC
remain unchanged (at least if my printk catches everything).

thanks,
Bas



2008-03-27 12:59:49

by Johannes Berg

[permalink] [raw]
Subject: Re: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous

Hi Bas,

> don't mean to push you or anything, but I was wondering if you
> overlooked my last mail. You asked me to add some printk's to the
> rt2500pci driver to debug hostapd authentication failure. I did this,
> and these are the results:

Sorry. I'm sure I read it but I must have forgotten, thanks for the
note.

> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2

> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2
> rt2500pci filter_flags: 0
> rt2500pci MAC changed: 00:00:00:00:00:00
> rt2500pci MAC changed: 00:0c:f6:14:05:19
> rt2500pci filter_flags: 2
> ------------------------------------------------
> this is immediately on startup of hostapd, after that filter and MAC
> remain unchanged (at least if my printk catches everything).

That looks pretty much expected.

> does this look ok to you? Does it explain why I can only receive EOPOL
> keys when in promiscuous mode?

Unfortunately not, it's a bit weird. I think I'll probably have to run
it myself to figure it out and do captures on the various interfaces.

johannes


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part

2008-03-23 12:12:50

by Johannes Berg

[permalink] [raw]
Subject: Re: hostapd with mac80211 and rt2500pci: hostapd doesn't receive clients EAPOL keys unless mon.wlan1 is promiscuous


> Ok, to summarize: hostapd doesn't seem to work at the moment with
> rt2500pci and lates git.wireless-testing. The cause seems to be that
> EOPOL key send from the client does not arrive at hostapd. This can be
> 'fixed' by running tethereal on the monitor interface. Any thoughts on
> what might cause this?

Can you stick a printk into the driver to print out
* the configured MAC address
* the filter flags configuration?

Whenever either changes.

johannes


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part