On Wed, Mar 15, 2023 at 01:36:47PM +0100, Stefan Sperling wrote:
> On Wed, Mar 15, 2023 at 09:18:25AM +1100, Jonathan Gray wrote:
> > On Tue, Mar 14, 2023 at 01:37:28PM +0100, Stefan Sperling wrote:
> > > On Tue, Mar 14, 2023 at 12:19:10PM +0000, Klemens Nanni wrote:
> > > > Here is an yet untested WEP removal diff based on 'grep WEP' in case we
> > > > go
> > > > this way rather than fixing WEP.
> > >
> > > Did you test wether adding the WEP capability flag to the driver is
> > > sufficient? If you have a hostap-capable interface like athn(4) and
> > > a bwfm(4) client it is trvial to create a test setup for this. Just
> > > use static IPs on AP and client and try get to a ping through.
> > >
> > > I would encourage you to at least try to fix WEP instead of axing
> > > things that would need to be reinstated once it's been fixed.
> > > Maybe one day you will be traveling and depend on bwfm(4) to connect
> > > to some WEP-only hotspot and then you will be happy to have fixed it ;)
> >
> > It isn't enough.
> >
> > panic'd without 'if (cmd->ni != NULL)'
>
> Yes, that is needed because intially net80211 sets all the WEP keys
> while passing NULL for the 'ni' argument.
>
> > I started on this, but didn't get to a point where it could
> > pass traffic to another machine running hostap.
>
> Huh. But your diff is in fact working for me...?!?
>
> Did you use athn(4) hostap to test this? I noticed mine comes up
> in 'mode 11n' by default even if WEP is configured, which is a
> misconfigured state because 11n requires WPA.
I think it was bwfm(4) on Raspberry Pi 3, hostap with rum(4).
It would associate but not pass traffic.
>
> With your diff I can ping an athn(4) WEP hostap in 11g (not n) mode using
> a USB bwfm device (vendor/product 0a5c:bd1e, Raspberry Pi 2 wifi dongle):
> bwfm0 at uhub1 port 1 configuration 1 interface 0 "Broadcom Remote Download
> Wireless Adapter" rev 2.00/0.01 addr 5
>
> > Perhaps it would be easier to do software WEP.
>
> Software crypto is impossible on this device because it expects
> Ethernet frames from the kernel, rather than 802.11 frames... :-/
>
> We should probably avoid asking the device to do wpa and wep at the
> same time. The old code was inherited from Linux as-is but not clearing
> the other crypto mode flags when we change the mode seems wrong to me.
> I have tweaked the driver accordingly, see below. Though this tweak doesn't
> make a difference during testing, even while flipping between WEP and WPA.
> Presumably the internal device state is always getting reset somehow before
> we read it out and change it.
>
> If WEP still doesn't work on your device then we may need to set
> the authmode to SHARED_KEY on some devices:
>
> bwfm_fwvar_var_set_int(sc, "auth", BWFM_AUTH_SHARED_KEY);
>From what I remember changing the authmode resulted in associate
failing.
>
> My device requires OPEN auth and does not work if SHARED_KEY is set.
> But maybe this differs between device/firmware versions as hinted at
> by the comments in my slightly tweaked diff below, based on yours.
>
> OK stsp@ for your diff if you want to commit it.
> I can layer my cosmetic tweaks on top.
It will be a day or two until I can set everything up again.
If this works for you I think you should commit it. ok jsg@
>
> diff d5650cee3563531d216bf9be18275aff4dec8349
> 9ed7f223411e76981d3f306085bf471975800ad3
> commit - d5650cee3563531d216bf9be18275aff4dec8349
> commit + 9ed7f223411e76981d3f306085bf471975800ad3
> blob - 56c8e2365b5aadb2f9f32bcc99a0a73f4b2ded0f
> blob + f3ab1d1bb3bdf51986512481edb5d274a61dd9d9
> --- sys/dev/ic/bwfm.c
> +++ sys/dev/ic/bwfm.c
> @@ -199,6 +199,7 @@ bwfm_attach(struct bwfm_softc *sc)
> ic->ic_state = IEEE80211_S_INIT;
>
> ic->ic_caps =
> + IEEE80211_C_WEP |
> #ifndef IEEE80211_STA_ONLY
> IEEE80211_C_HOSTAP | /* Access Point */
> #endif
> @@ -2001,8 +2002,7 @@ bwfm_connect(struct bwfm_softc *sc)
> uint8_t *frm;
>
> /*
> - * OPEN: Open or WPA/WPA2 on newer Chips/Firmware.
> - * SHARED KEY: WEP.
> + * OPEN: Open or WEP or WPA/WPA2 on newer Chips/Firmware.
> * AUTO: Automatic, probably for older Chips/Firmware.
> */
> if (ic->ic_flags & IEEE80211_F_RSNON) {
> @@ -2041,6 +2041,9 @@ bwfm_connect(struct bwfm_softc *sc)
>
> bwfm_fwvar_var_set_int(sc, "wpa_auth", wpa);
> bwfm_fwvar_var_set_int(sc, "wsec", wsec);
> + } else if (ic->ic_flags & IEEE80211_F_WEPON) {
> + bwfm_fwvar_var_set_int(sc, "wpa_auth", BWFM_WPA_AUTH_DISABLED);
> + bwfm_fwvar_var_set_int(sc, "wsec", BWFM_WSEC_WEP);
> } else {
> bwfm_fwvar_var_set_int(sc, "wpa_auth", BWFM_WPA_AUTH_DISABLED);
> bwfm_fwvar_var_set_int(sc, "wsec", BWFM_WSEC_NONE);
> @@ -2083,8 +2086,7 @@ bwfm_hostap(struct bwfm_softc *sc)
> struct bwfm_join_params join;
>
> /*
> - * OPEN: Open or WPA/WPA2 on newer Chips/Firmware.
> - * SHARED KEY: WEP.
> + * OPEN: Open or WEP or WPA/WPA2 on newer Chips/Firmware.
> * AUTO: Automatic, probably for older Chips/Firmware.
> */
> if (ic->ic_flags & IEEE80211_F_RSNON) {
> @@ -2883,10 +2885,12 @@ bwfm_set_key_cb(struct bwfm_softc *sc, void *arg)
>
> bwfm_fwvar_var_set_data(sc, "wsec_key", &key, sizeof(key));
> bwfm_fwvar_var_get_int(sc, "wsec", &wsec);
> + wsec &= ~(BWFM_WSEC_WEP | BWFM_WSEC_TKIP | BWFM_WSEC_AES);
> wsec |= wsec_enable;
> bwfm_fwvar_var_set_int(sc, "wsec", wsec);
>
> - if (sc->sc_key_tasks == 0) {
> + if (wsec_enable != BWFM_WSEC_WEP && cmd->ni != NULL &&
> + sc->sc_key_tasks == 0) {
> DPRINTF(("%s: marking port %s valid\n", DEVNAME(sc),
> ether_sprintf(cmd->ni->ni_macaddr)));
> cmd->ni->ni_port_valid = 1;
>
>
>
