lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8665E2433BC68541A24DFFCA87B70F5B3641E339@DFRE01.ent.ti.com>
Date:   Mon, 7 Aug 2017 07:46:34 +0000
From:   "Reizer, Eyal" <eyalr@...com>
To:     Tony Lindgren <tony@...mide.com>
CC:     Kalle Valo <kvalo@...eaurora.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "sebastian.reichel@...labora.co.uk" 
        <sebastian.reichel@...labora.co.uk>,
        Julian Calaby <julian.calaby@...il.com>
Subject: RE: [v5] wlcore: add missing nvs file name info for wilink8

Hi Tony,
> 
> * Reizer, Eyal <eyalr@...com> [170807 00:32]:
> > The following commits:
> > c815fde wlcore: spi: Populate config firmware data
> > d776fc8 wlcore: sdio: Populate config firmware data
> >
> > Populated the nvs entry for wilink6 and wilink7 only while it is
> > still needed for wilink8 as well.
> > This broke user space backward compatibility when upgrading from older
> > kernels, as the alternate mac address would not be read from the nvs that
> is
> > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> > causing mac address change of the wlan interface.
> >
> > This patch fix this and update the structure field with the same default
> > nvs file name that has been used before.
> >
> > In addition, some distros hold a default wl1271-nvs.bin in the file
> > system with a bogus mac address (deadbeef...) that for a wl18xx device
> > also overrides the mac address that is stored inside the device.
> > Warn users about this bogus mac address and use a random mac instead
> 
> Hmm looks pretty good to me except for one more thing I just noticed.
> 
> Why don't you just use the hardware mac address instead of a random
> mac address on wl18xx device when you see a bogus nvs file?
> 

I agree that this would have been better but the problem is that hardware 
mac address is available for wilink8 onlyWilink6/7 don't have one stored.
The wlcore code responsible for handling mac address is common code 
and there is method for detecting between them in this module.

Best Regards,
Eyal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ