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: <d6d0da01-9314-2e00-e82b-d2d42276bbf4@microchip.com>
Date:   Thu, 9 Feb 2023 19:09:39 +0000
From:   <Ajay.Kathat@...rochip.com>
To:     <heiko.thiery@...il.com>
CC:     <Claudiu.Beznea@...rochip.com>, <kvalo@...nel.org>,
        <linux-wireless@...r.kernel.org>, <michael@...le.cc>,
        <netdev@...r.kernel.org>, <Amisha.Patel@...rochip.com>
Subject: Re: wilc1000 MAC address is 00:00:00:00:00:00

On 2/9/23 11:40, Heiko Thiery wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,
> 
> Am Do., 9. Feb. 2023 um 18:15 Uhr schrieb <Ajay.Kathat@...rochip.com>:
>>
>> Hi Heiko,
>>
>> On 2/8/23 07:24, Heiko Thiery wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Hi,
>>>
>>> I'm using the WILC1000 wifi and with NetworkManager [1] I see issues
>>> in certain situations I see problems.
>>>
>>> I was able to reduce the problem and have now found out that the cause
>>> is that the interface has the HW MAC address is 00:00:00:00:00 after
>>> startup. Only when the interface is startup (ip link set dev wlan0
>>> up), the driver sets a "valid" address.
>>>
>>
>> IIUC network manager(NM) is trying to read the MAC address and write the
>> same back to wilc1000 module without making the wlan0 interface up. right?
> 
> As far as I understand, network-manager will read the "real" HW
> address. Then it sets a random
> generated HW for scanning and after that switches back to the "real" HW address.
> 
> There seems to be circumstances where the wrong HW address
> (00:00:00:00:00:00) is read and stored for
> later reset after the scanning.
> 

Actually, the scan operation is allowed only after the interface is up.
Probably the address was stored before any wlan operation.


>> Not sure about the requirement but if NM has a valid MAC address to
>> assign to the wlan0 interface, it can be configured without making
>> interface up("wlan0 up"). "ip link set dev wlan0 address XX:XX:XX:XX:XX"
>> command should allow to set the mac address without making the interface
>> up.
>> Once the mac address is set, the wilc1000 will use that mac address [1]
>> instead of the one from wilc1000 NV memory until reboot. However, after
>> a reboot, if no MAC address is configured from application then wilc1000
>> will use the address from its NV memory.
>>
>>> Is this a valid behavior and shouldn't the address already be set
>>> after loading the driver?
>>>
>>
>> Only when the interface is up(ifconfig wlan0 up), driver loads the
>> firmware to wilc1000 module and after that the WID commands which allows
>> to set/get the mac address from the wilc1000 works.
> 
> Is there a hard technical reason not to load the firmware and set the
> HW address when
> the driver is initialized and not only when its opened.
> 

AFAIK, wilc1000 flow is designed that way to load the firmware start
when the interface is up (before wlan operation are performed).
Similarly when the interface is down it will not execute to save power.

Regards,
Ajay

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ