Re: WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
On Wed, 29 Mar 2017, Stefan Sperling wrote: On Wed, Mar 29, 2017 at 04:10:15PM +0200, Stefan Sperling wrote: New diff which fixes another problem where the iwi(4) firmware won't receive data frames which are protected with RTS frames. This diff makes iwi(4) work against WPA2 11n athn(4) hostap. Committed. This fix will be in 6.1. Thanks for reporting the problem! Confirmed fixed for both WPA2 PSK and WPA2 Enterprise. Thank you.
Re: WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
On Wed, Mar 29, 2017 at 04:10:15PM +0200, Stefan Sperling wrote: > New diff which fixes another problem where the iwi(4) firmware won't > receive data frames which are protected with RTS frames. This diff > makes iwi(4) work against WPA2 11n athn(4) hostap. Committed. This fix will be in 6.1. Thanks for reporting the problem!
Re: WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
On Wed, Mar 29, 2017 at 12:22:32PM +0200, Stefan Sperling wrote:
> On Wed, Mar 29, 2017 at 10:50:07AM +0200, Stefan Sperling wrote:
> > iwi(4) is being stupid and does not forward state changes to the
> > net80211 stack. It is a wonder this driver even works at all.
>
> Please ignore the previous diff. I misunderstood how iwi(4) implements
> state transitions. It is a bit different than other drivers.
>
> The problem is that iwi(4) firmware does not pass auth and assoc
> response frames to the driver. So the net80211 layer never gets to
> see them and won't adjust its idea of the curren WPA negotiation state.
>
> So unfortunately, this driver needs a hack to keep WPA working.
> This is the best fix I can come up with, for now. And it works.
New diff which fixes another problem where the iwi(4) firmware won't
receive data frames which are protected with RTS frames. This diff
makes iwi(4) work against WPA2 11n athn(4) hostap.
Index: if_iwi.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwi.c,v
retrieving revision 1.135
diff -u -p -r1.135 if_iwi.c
--- if_iwi.c8 Mar 2017 12:02:41 - 1.135
+++ if_iwi.c29 Mar 2017 14:04:40 -
@@ -965,6 +965,7 @@ iwi_notification_intr(struct iwi_softc *
struct iwi_notif *notif)
{
struct ieee80211com *ic = >sc_ic;
+ struct ieee80211_node *ni = ic->ic_bss;
struct ifnet *ifp = >ic_if;
switch (notif->type) {
@@ -1028,6 +1029,8 @@ iwi_notification_intr(struct iwi_softc *
break;
case IWI_ASSOCIATED:
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ni->ni_rsn_supp_state = RSNA_SUPP_PTKSTART;
ieee80211_new_state(ic, IEEE80211_S_RUN, -1);
break;
@@ -2038,6 +2041,7 @@ iwi_auth_and_assoc(struct iwi_softc *sc)
config.disable_multicast_decryption = 1;
config.silence_threshold = 30;
config.report_noise = 1;
+ config.allow_mgt = 1;
config.answer_pbreq =
#ifndef IEEE80211_STA_ONLY
(ic->ic_opmode == IEEE80211_M_IBSS) ? 1 :
Re: WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
On Wed, Mar 29, 2017 at 10:50:07AM +0200, Stefan Sperling wrote:
> iwi(4) is being stupid and does not forward state changes to the
> net80211 stack. It is a wonder this driver even works at all.
Please ignore the previous diff. I misunderstood how iwi(4) implements
state transitions. It is a bit different than other drivers.
The problem is that iwi(4) firmware does not pass auth and assoc
response frames to the driver. So the net80211 layer never gets to
see them and won't adjust its idea of the curren WPA negotiation state.
So unfortunately, this driver needs a hack to keep WPA working.
This is the best fix I can come up with, for now. And it works.
Index: if_iwi.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwi.c,v
retrieving revision 1.135
diff -u -p -r1.135 if_iwi.c
--- if_iwi.c8 Mar 2017 12:02:41 - 1.135
+++ if_iwi.c29 Mar 2017 10:15:39 -
@@ -965,6 +965,7 @@ iwi_notification_intr(struct iwi_softc *
struct iwi_notif *notif)
{
struct ieee80211com *ic = >sc_ic;
+ struct ieee80211_node *ni = ic->ic_bss;
struct ifnet *ifp = >ic_if;
switch (notif->type) {
@@ -1028,6 +1029,8 @@ iwi_notification_intr(struct iwi_softc *
break;
case IWI_ASSOCIATED:
+ if (ic->ic_flags & IEEE80211_F_RSNON)
+ ni->ni_rsn_supp_state = RSNA_SUPP_PTKSTART;
ieee80211_new_state(ic, IEEE80211_S_RUN, -1);
break;
Re: WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
On Tue, Mar 28, 2017 at 11:22:17PM -0500, bg2...@jamesjerkinscomputer.com wrote:
> I follow i386 stable and after applying the WPA1/WPA2 MITM fix to 6.0 (#018)
> I can no longer obtain an IP address via dhclient when WPA2 is in use. This
> happens with both PSK and enterprise modes (via wpa_supplicant). Wireless
> (iwi0) connections without encryption work fine.
>
> I tried the 03/25/17 snapshot and that does not resolve the issue.
>
> I reversed patch #018 and and built a stable kernel and that does resolve the
> issue.
>
> With the iwi debug flag enabled I see the expected rssi lines and then the 4
> handshake messages without patch #018. These messages are then followed by
> normal dhclient success.
>
> Mar 28 22:14:51 /bsd: iwi0: begin active scan
> Mar 28 22:14:51 /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi
> 66 mode auto
> Mar 28 22:14:51 /bsd: iwi0: received beacon from 00:0f:66:b0:d9:dc rssi 60
> mode auto
> Mar 28 22:14:51 /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi
> 63 mode auto
> Mar 28 22:14:51 /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 44
> mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi
> 56 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 2c:59:e5:f4:57:e3 rssi
> 47 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 47
> mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi
> 54 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi
> 37 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi
> 38 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi
> 37 mode auto
> Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi
> 38 mode auto
> Mar 28 22:14:52 /bsd: iwi0: end active scan
> Mar 28 22:14:52 /bsd: iwi0: received msg 1/4 of the 4-way handshake from
> 00:0f:66:b0:d9:dc
> Mar 28 22:14:52 /bsd: iwi0: sending msg 2/4 of the 4-way handshake to
> 00:0f:66:b0:d9:dc
> Mar 28 22:14:52 /bsd: iwi0: received msg 3/4 of the 4-way handshake from
> 00:0f:66:b0:d9:dc
> Mar 28 22:14:52 /bsd: iwi0: sending msg 4/4 of the 4-way handshake to
> 00:0f:66:b0:d9:dc
>
> With patch #018 applied or with 3/25 snapshot, active scanning occurs and
> ends, but no RSNA handshake happens. Therefore, dhclient does not succeed.
iwi(4) is being stupid and does not forward state changes to the
net80211 stack. It is a wonder this driver even works at all.
This diff is untested. I have a iwi(4) minipci card but will need to
make some rearrangements to plug it.
Can you please test this ASAP? The 6.1 release deadline is very close.
Index: if_iwi.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwi.c,v
retrieving revision 1.135
diff -u -p -r1.135 if_iwi.c
--- if_iwi.c8 Mar 2017 12:02:41 - 1.135
+++ if_iwi.c29 Mar 2017 08:47:03 -
@@ -733,7 +733,8 @@ iwi_newstate(struct ieee80211com *ic, en
switch (nstate) {
case IEEE80211_S_SCAN:
iwi_scan(sc);
- break;
+ ic->ic_state = nstate;
+ return 0;
case IEEE80211_S_AUTH:
iwi_auth_and_assoc(sc);
@@ -767,8 +768,7 @@ iwi_newstate(struct ieee80211com *ic, en
break;
}
- ic->ic_state = nstate;
- return 0;
+ return sc->sc_newstate(ic, nstate, arg);
}
/*
WPA2 dhcp fails on iwi after 3/1/17 security fix (#018)
I follow i386 stable and after applying the WPA1/WPA2 MITM fix to 6.0 (#018) I
can no longer obtain an IP address via dhclient when WPA2 is in use. This
happens with both PSK and enterprise modes (via wpa_supplicant). Wireless
(iwi0) connections without encryption work fine.
I tried the 03/25/17 snapshot and that does not resolve the issue.
I reversed patch #018 and and built a stable kernel and that does resolve the
issue.
With the iwi debug flag enabled I see the expected rssi lines and then the 4
handshake messages without patch #018. These messages are then followed by
normal dhclient success.
Mar 28 22:14:51 /bsd: iwi0: begin active scan
Mar 28 22:14:51 /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi 66
mode auto
Mar 28 22:14:51 /bsd: iwi0: received beacon from 00:0f:66:b0:d9:dc rssi 60
mode auto
Mar 28 22:14:51 /bsd: iwi0: received probe_resp from 00:0f:66:b0:d9:dc rssi 63
mode auto
Mar 28 22:14:51 /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 44
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi 56
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 2c:59:e5:f4:57:e3 rssi 47
mode auto
Mar 28 22:14:52 /bsd: iwi0: received beacon from 2c:59:e5:f4:57:e3 rssi 47
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 44:94:fc:78:a4:40 rssi 54
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 37
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 38
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 37
mode auto
Mar 28 22:14:52 /bsd: iwi0: received probe_resp from 7c:bf:b1:77:40:30 rssi 38
mode auto
Mar 28 22:14:52 /bsd: iwi0: end active scan
Mar 28 22:14:52 /bsd: iwi0: received msg 1/4 of the 4-way handshake from
00:0f:66:b0:d9:dc
Mar 28 22:14:52 /bsd: iwi0: sending msg 2/4 of the 4-way handshake to
00:0f:66:b0:d9:dc
Mar 28 22:14:52 /bsd: iwi0: received msg 3/4 of the 4-way handshake from
00:0f:66:b0:d9:dc
Mar 28 22:14:52 /bsd: iwi0: sending msg 4/4 of the 4-way handshake to
00:0f:66:b0:d9:dc
With patch #018 applied or with 3/25 snapshot, active scanning occurs and ends,
but no RSNA handshake happens. Therefore, dhclient does not succeed.
OpenBSD 6.0 (GENERIC) #5: Thu Mar 23 11:13:03 CDT 2017
r...@slartibartfast.jamesjerkinscomputer.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) M processor 1500MHz ("GenuineIntel" 686-class) 1.50
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF
real mem = 536027136 (511MB)
avail mem = 513101824 (489MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/29/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @
0xf8cb0 (61 entries)
bios0: vendor Dell Computer Corporation version "A17" date 06/29/2005
bios0: Dell Computer Corporation Inspiron 600m
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S1) USB1(S1) USB2(S1)
USB3(S1) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (PCIE)
acpicpu0 at acpi0
C1: unknown FFH class 0: !C3(100@185 io@0x816), !C3(250@85 io@0x815), !C2(500@1
io@0x814), C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 89 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0F13" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0401" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
bios0: ROM list: 0xc/0x1
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: Enhanced SpeedStep 1496 MHz: speeds: 1500, 1500, 1500, 1400, 1200, 1000,
800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe000, size 0x800
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M9" rev 0x02
drm0 at radeondrm0
radeondrm0: irq 11
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 "Broadcom BCM5705M" rev 0x01, BCM5705 A1
(0x3001):
