Hi Stefan.

Thanks that worked.

> On 24 May 2020, at 16:46, Stefan Sperling <[email protected]> wrote:
> 
> On Sun, May 24, 2020 at 03:08:09PM +0200, Hendrik Meyburgh wrote:
>>> Synopsis:   ral interface is not working
>>> Category:   system
>>> Environment:
>>      System      : OpenBSD 6.7
>>      Details     : OpenBSD 6.7-current (GENERIC.MP) #207: Fri May 22 
>> 01:31:04 MDT 2020
>>                       
>> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> 
>>      Architecture: OpenBSD.amd64
>>      Machine     : amd64
>>> Description:
>>      IP not working on ral interface 
>>> How-To-Repeat:
>> I completed a sysupgrade on Tuesday the 19th, not sure what snapshot was 
>> running prior, I did not check. After the upgrade the laptop does not 
>> connect to any wireless network. The re0 interface is still working on DHCP. 
>> I looked at some recent posts but could not trace the problem
>> 
>> https://marc.info/?l=openbsd-misc&m=158861290011220&w=2
>> https://marc.info/?l=openbsd-bugs&m=158996211916426&w=2 
>> <https://marc.info/?l=openbsd-bugs&m=158996211916426&w=2> 
>> <https://marc.info/?l=openbsd-bugs&m=158996211916426&w=2 
>> <https://marc.info/?l=openbsd-bugs&m=158996211916426&w=2>>
>> 
>> I just tested the 6.7-release bsd.rd and it does work, please see info below 
>> and let me know if you need any additional information.
> 
> Thank you for the report!
> 
> I could reproduce the problem with this device:
> 
> ral0 at pci5 dev 0 function 0 "Ralink RT3090" rev 0x00: apic 5 int 16, 
> address xx:xx:xx:xx:xx:xx
> ral0: MAC/BBP RT3090 (rev 0x3213), RF RT3020 (MIMO 1T1R)
> 
> I had overlooked that ral(4) uses hardware encryption on some of its
> supported devices and accidentally broke decrytion on those devices
> when I fixed replay detection on Intel and Atheros hardware.
> 
> ral(4) devices provide fully decrypted frames with TKIP/CCMP headers already
> stripped. This means replay detection can only be done by hardware.
> My recent changes enforce a software replay check which cannot work on ral(4).
> 
> The following diff repairs the problem. The ne80211 stack will simply have
> to trust that hardware takes care of replay detection when it strips the IV.
> 
> diff 3247d7f3b53b75bbaf4356f06f34208638ba213d /usr/src
> blob - de44d5a0a957f497259735efd5cee2cc081d33bc
> file + sys/net80211/ieee80211_input.c
> --- sys/net80211/ieee80211_input.c
> +++ sys/net80211/ieee80211_input.c
> @@ -178,9 +178,12 @@ ieee80211_input_hwdecrypt(struct ieee80211com *ic, str
>       switch (k->k_cipher) {
>       case IEEE80211_CIPHER_CCMP:
>               if (!(wh->i_fc[1] & IEEE80211_FC1_PROTECTED)) {
> -                     /* drop unencrypted */
> -                     ic->ic_stats.is_rx_unencrypted++;
> -                     return NULL;
> +                     /*
> +                      * If the protected bit is clear then hardware has
> +                      * stripped the IV and we must trust that it handles
> +                      * replay detection correctly.
> +                      */
> +                     break;
>               }
>               if (ieee80211_ccmp_get_pn(&pn, &prsc, m, k) != 0)
>                       return NULL;
> @@ -200,9 +203,12 @@ ieee80211_input_hwdecrypt(struct ieee80211com *ic, str
>               break;
>        case IEEE80211_CIPHER_TKIP:
>               if (!(wh->i_fc[1] & IEEE80211_FC1_PROTECTED)) {
> -                     /* drop unencrypted */
> -                     ic->ic_stats.is_rx_unencrypted++;
> -                     return NULL;
> +                     /*
> +                      * If the protected bit is clear then hardware has
> +                      * stripped the IV and we must trust that it handles
> +                      * replay detection correctly.
> +                      */
> +                     break;
>               }
>               if (ieee80211_tkip_get_tsc(&pn, &prsc, m, k) != 0)
>                       return NULL;

Reply via email to