Incompatibility between MM6108 versions (2.4.4 and 2.7.2)?

Software Linux
1

Is there some issue with compatibility between morse nodes running different versions of the morse driver and mm6108 firmware?

The observed behavior is that a station running the latest morse micro firmware is unable to connect to an EKH03 Access point running the firmware that the EVB was shipped with (2.4.4.

After setting up another access point on an EKH03 EVB and updating it to the latest openwrt version (2.7.2) that same station is able to connect to it.

Morse Micro Connection Issues
Morse Micro Connection Issues2998×1804 70 KB

The initial assumption was that the Station isn’t able to connect because the AP with SSID: MorseMicro is on 908MHz, but this experiment proved that this was not the case.

First Test to connect to MorseMicro

/etc/wpa_supplicant/wpa_supplicant_s1g.conf

ctrl_interface=DIR=/var/run/wpa_supplicant_s1g
country=US
sae_pwe=1

network={
    ssid="MorseMicro"
    scan_ssid=1
    key_mgmt=SAE
    psk="12345678"
    pairwise=CCMP
    proto=RSN
    ieee80211w=2
}

results in this error:

1745955391.839397: wlan0: 1: 0c:bf:74:00:0c:fc ssid='MorseMicro' wpa_ie_len=0 rsn_ie_len=0 caps=0x11 level=-44 chan=11 
1745955391.839403: wlan0:    skip - MFP Required but network not MFP Capable

Second Test to connect to MorseMicro

/etc/wpa_supplicant/wpa_supplicant_s1g.conf

ctrl_interface=DIR=/var/run/wpa_supplicant_s1g
country=US
sae_pwe=1

network={
    ssid="MorseMicro"
    scan_ssid=1
    key_mgmt=SAE
    psk="12345678"
    pairwise=CCMP
    proto=RSN
    ieee80211w=0
}

1745955856.689323: wlan0: 1: 0c:bf:74:00:0c:fc ssid='MorseMicro' wpa_ie_len=0 rsn_ie_len=0 caps=0x11 level=-45 chan=11 
1745955856.689329: wlan0:    skip - no WPA/RSN proto match

Final Test to connect to MorseMicroSecond

/etc/wpa_supplicant/wpa_supplicant_s1g.conf

ctrl_interface=DIR=/var/run/wpa_supplicant_s1g
country=US
sae_pwe=1

network={
    ssid="MorseMicroSecond"
    scan_ssid=1
    key_mgmt=SAE
    psk="12345678"
    pairwise=CCMP
    proto=RSN
    ieee80211w=2
}

successful connection:

1745956506.368218: wlan0: State: AUTHENTICATING -> ASSOCIATING
1745956506.368224: nl80211: Set wlan0 operstate 0->0 (DORMANT)
1745956506.368226: netlink: Operstate: ifindex=35 linkmode=-1 (no change), operstate=5 (IF_OPER_DORMANT)
1745956506.368243: WPA: set own WPA/RSN IE - hexdump(len=28): 30 1a 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 00 00 00 0f ac 06
1745956506.368250: RSN: set own RSNXE - hexdump(len=3): f4 01 20
1745956506.368255: nl80211: Associate (ifindex=35)
1745956506.368261:   * bssid=0c:bf:74:00:0c:db
1745956506.368264:   * mapped freq=5560
1745956506.368266:   * SSID=MorseMicroSecond
1745956506.368267:   * IEs - hexdump(len=48): 30 1a 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 00 00 00 0f ac 06 7f 08 00 00 40 00 00 00 00 40 3b 05 47 44 45 46 47 f4 01 20
1745956506.368276:   * WPA Versions 0x4
1745956506.368278:   * pairwise=0xfac04
1745956506.368280:   * group=0xfac04
1745956506.368282:   * akm[0]=0xfac08
1745956506.368324: nl80211: Association request send successfully
1745956506.471621: nl80211: Drv Event 38 (NL80211_CMD_ASSOCIATE) received for wlan0
1745956506.471657: nl80211: Associate event
1745956506.471773: nl80211: Associated on 5560 MHz (5 GHz mapped)
1745956506.471789: nl80211: Associated with 0c:bf:74:00:0c:db
1745956506.471817: nl80211: Set drv->ssid based on scan res info to 'MorseMicroSecond'
1745956506.471832: wlan0: Event ASSOC (0) received
1745956506.471903: wlan0: Association info event
1745956506.471919: req_ies - hexdump(len=127): 00 10 4d 6f 72 73 65 4d 69 63 72 6f 53 65 63 6f 6e 64 01 08 02 04 0b 0c 16 18 24 30 30 1a 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 00 00 00 0f ac 06 2d 1a 7e 09 03 ff 03 00 00 00 00 00 00 00 00 41 00 01 00 00 00 00 00 00 00 00 00 00 7f 08 00 00 40 00 00 00 00 40 bf 0c 66 00 80 03 fd ff 41 00 fd ff 00 00 3b 05 47 44 45 46 47 f4 01 20 dd 07 00 50 f2 02 00 01 00
1745956506.472018: resp_ies - hexdump(len=150): 01 08 02 04 0b 8c 16 98 24 b0 5a 03 24 01 00 7f 08 04 00 02 02 01 00 01 40 d3 05 01 00 00 00 00 dd 18 00 50 f2 02 01 01 81 00 03 a4 d5 01 27 a4 d5 01 42 43 d5 01 62 32 d5 01 dd 0e 0c bf 74 00 01 0e 01 00 06 03 00 00 06 08 f4 01 20 2d 1a 6e 00 01 ff 00 00 00 00 00 00 00 00 00 41 00 01 00 00 00 00 00 00 00 00 00 00 3d 16 70 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf 0c 66 00 80 03 fd ff 00 00 fd ff 00 00 c0 05 02 72 00 fd ff
1745956506.472105: wlan0: chan=27
1745956506.472116: WPA Got aid 1
1745956506.472125: WPA: set own WPA/RSN IE - hexdump(len=28): 30 1a 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 08 cc 00 00 00 00 0f ac 06
1745956506.472153: wlan0: RSN: PMKID from assoc IE not found from PMKSA cache
1745956506.472162: RSN: set own RSNXE - hexdump(len=3): f4 01 20
1745956506.472175: wlan0: State: ASSOCIATING -> ASSOCIATED

04292025_mm6108_wpa_supplicant_s1g.txt (460.1 KB)

2

I did some poking around here and found that there is a known bug when attempting to connect to 2.4.4 APs from newer clients, specifically if the AP is running on the MIPS architecture. (which includes the EKH03.

The general recommendation would be to upgrade the AP anyway, but if this is infeasible there are a couple of workarounds. They’re probably more annoying to implement than just upgrading, however.

Changing the primary channel index on the AP from 3 (default) to 2 will avoid the issue. You can also set a modparam: enable_1mhz_probes:N on the STA.

I’d recommend upgrading the AP if at all possible, as there have been quite a few fixes since 2.4.4 (1.10.2)

1 Like