Dan Williams <d...@redhat.com> writes: > Is it likely the device requires 0/1/2/3/4/5, or does any MAC address > work as long as it's explicitly set?
Good question. I thought any address would work, and that the modem would pick it up from the DHCP and/or ARP requests from the host. But I may be wrong. Testing is needed to verify this. Or we can just use 0/1/2/3/4/5. > Also, force-setting the MAC will only work from userspace as long as the > device has unique USB descriptors for that model, and I don't really > trust Huawei to use a separate VID/PID here (since the other reference > to this behavior was the e173-u2, not the mentioned 1820). And I really > don't think we should be poking this sort of thing from ModemManager, > since it's really a hardware/firmware bug. udev rules would be most > appropriate I guess, if modifying cdc-ether is not likely, but like I > said that requires a unique USB descriptor we can rely on :( This problem is the same whether we do it in the kernel or in userspace, isn't it? In either case we should only change the address if the vendor ID is 12d1 and the current MAC address is 02:50:f3:00:00:00. I believe that is the best we can do. I don't think there is any point checking the product ID. It won't be unique anyway, and we don't know which product IDs are affected by this bug. From the random reports I've seen, it looks like Huawei has copied this bug into a number of very different devices. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
