On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote:
> Stefan Sperling wrote:
> > > That means there is another bug. I will try to find it.
> > Could you show what 'netstat -W ipw0' looks like after an unsuccesful
> > attempt of connecting to a WEP access point?
> 
> ipw0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         lladdr 00:0c:f1:1f:b2:a0
>         index 1 priority 4 llprio 3
>         groups: wlan
>         media: IEEE802.11 autoselect (DS11 mode 11b)
>         status: active
>         ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm
> nwkey
> 
> 
> then I run dhclient
> 
> ieee80211 on ipw0:
>         0 input packets with bad version
>         0 input packets too short
>         0 input packets from wrong bssid
>         0 input packet duplicates discarded
>         0 input packets with wrong direction
>         0 input multicast echo packets discarded
>         0 input packets from unassociated station discarded
>         0 input encrypted packets without wep/wpa config discarded
>         0 input unencrypted packets with wep/wpa config discarded
>         0 input wep/wpa packets processing failed
>         0 input packet decapsulations failed
>         2 input management packets discarded
>         0 input control packets discarded
>         0 input packets with truncated rate set
>         0 input packets with missing elements
>         0 input packets with elements too big
>         0 input packets with elements too small
>         0 input packets with invalid channel
>         3 input packets with mismatched channel
>         0 node allocations failed
>         0 input packets with mismatched ssid
>         0 input packets with unsupported auth algorithm
>         0 input authentications failed
>         0 input associations from wrong bssid
>         0 input associations without authentication
>         0 input associations with mismatched capabilities
>         0 input associations without matching rates
>         0 input associations with bad rsn ie
>         0 input deauthentication packets
>         0 input disassociation packets
>         0 input packets with unknown subtype
>         0 input packets failed for lack of mbufs
>         0 input decryptions failed on crc
>         0 input ahdemo management packets discarded
>         0 input packets with bad auth request
>         0 input eapol-key packets
>         0 input eapol-key packets with bad mic
>         0 input eapol-key packets replayed
>         0 input packets with bad tkip mic
>         0 input tkip mic failure notifications
>         0 input packets on unauthenticated port
>         0 output packets failed for lack of mbufs
>         0 output packets failed for no nodes
>         0 output packets of unknown management type
>         0 output packets on unauthenticated port
>         1 active scan started
>         0 passive scans started
>         0 nodes timed out
>         0 failures with no memory for crypto ctx
>         0 ccmp decryption errors
>         0 ccmp replayed frames
>         0 cmac icv errors
>         0 cmac replayed frames
>         0 tkip icv errors
>         0 tkip replays
>         0 pbac errors
>         0 HT negotiation failures because peer does not support MCS 0-7
>         0 HT negotiation failures because we do not support basic MCS set
>         0 HT negotiation failures because peer uses bad crypto
>         0 HT protection changes
>         0 new input block ack agreements
>         0 new output block ack agreements
>         0 input frames below block ack window start
>         0 input frames above block ack window end
>         0 input block ack window slides
>         0 input block ack window jumps
>         0 duplicate input block ack frames
>         0 expected input block ack frames never arrived
>         0 input block ack window gaps timed out
>         0 input block ack agreements timed out
>         0 output block ack agreements timed out
> 
> 
> The two "suspect" values im my humble opinion are:
>         2 input management packets discarded
>         3 input packets with mismatched channel
> 
> Riccardo
> 

My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.

Does this fix it?

diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
 ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
 {
        struct ipw_softc *sc = ic->ic_softc;
+       struct ifnet *ifp = &ic->ic_if;
 
+       if (LINK_STATE_IS_UP(ifp->if_link_state))
+               ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
        switch (nstate) {
        case IEEE80211_S_SCAN:
                task_add(systq, &sc->sc_scantask);
@@ -690,6 +694,14 @@ ipw_newstate(struct ieee80211com *ic, enum ieee80211_s
                break;
 
        case IEEE80211_S_RUN:
+               if (!(ic->ic_flags & IEEE80211_F_RSNON)) {
+                       /*
+                        * NB: When RSN is enabled, we defer setting
+                        * the link up until the port is valid.
+                        */
+                       ieee80211_set_link_state(ic, LINK_STATE_UP);
+               }
+               break;
        case IEEE80211_S_INIT:
        case IEEE80211_S_ASSOC:
                /* nothing to do */

Reply via email to