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->sc_ic; + struct ieee80211_node *ni = ic->ic_bss; struct ifnet *ifp = &ic->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->sc_ic; + struct ieee80211_node *ni = ic->ic_bss; struct ifnet *ifp = &ic->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): i