Graham Inggs <graham.in...@uct.ac.za> writes: > So many questions! :) I'm going to try and answer them in one post. > >> Quick question, in Windows does the device have the 00/1/2/3/4/5 hardware >> address? > > No, in Windows the MAC address was 00:1E:10:1F:E9:48 > >> Can we get lsusb -v output for the device too though? > > I attach three lsusb -v outputs; one with usb_modeswitch disabled, the > default (Linux?) mode and the alternate mode obtained by sending: > $ sudo usb_modeswitch -v 12d1 -p 1446 -M > 55534243000000000000000000000011060000000100000000000000000000
Thanks. I note that the device ID is the same after switching (12d1:14ac) and that the number of endpoints and their layout is unchanged. This supports the theory that the exported functions are identical, and the only difference is a superficial interface layout change for the ethernet function: 1 => 2 interfaces, different class/subclass/protocol, CDC functional descriptor. This is really pointless because we could have just made the drivers recongnise the layout as used by Windows. The ethernet function endpoints do not change, and I would be very surprised if there are any changes in how the firmware handle them: bEndpointAddress 0x83 EP 3 IN bEndpointAddress 0x84 EP 4 IN bEndpointAddress 0x02 EP 2 OUT You could probably verify this by manually unbinding interface #1 in "Windows mode" from the option driver and bind it to qmi_wwan instead. >> Is this a Qualcomm based modem? > > As far as I know it is. Any way for me to tell for sure? Try QMI. Get libqmi with qmicli and temporarily bind the qmi_wwan driver to the ethernet function instead of cdc_ether. The 2-5:1.1 below could have changed since the logs you posted. Check it and adjust as necessary (this recipe will work for Windows mode as well, except that the already bound driver most likely is option): modprobe qmi_wwan echo 2-5:1.1 >/sys/bus/usb/drivers/cdc_ether/unbind echo 2-5:1.1 >/sys/bus/usb/drivers/qmi_wwan/bind qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer Just unplug and replug to go back to cdc_ether, or reverse the bind/unbind. If the qmicli command was successful then we should consider changing this permanently to have access to the QMI device management. >> 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? > > Only 0/1/2/3/4/5 seems to work. I tried 0/5/4/3/2/1 and the address > the device had in Windows and got no data. That is unexpected given that Windows use a different address. Maybe the device already was "locked" to the 0/1/2/3/4/5 address when you tried the other one? This is my guess on how these things work on the device side. Guaranteed to be incomplete because I've never seen the firmware code, most likely inaccurate, and possibly completely wrong: 1) The ethernet addresses are only relevant on the host<->modem link, so they do not really matter as long as the host and modem agrees. 2) The modem will use a hardcoded default address (02:50:f3:00:00:00) as source address. 3) The modem will learn the host adress either from ARP requests or DHCP requests, and use the first adress seen as destination "forever". The host/driver side implications of this are * 02:50:f3:00:00:00 cannot be used - the modem will never respond to packets from this source * only one address is possible - bridging will not work * the host address cannot be changed after sending the first ARP or DHCP request to the modem To complicate this a bit, we also have some firmware bugs in circulation where the firmware - advertise 02:50:f3:00:00:00 as default host address in the CDC Ethernet functional descriptor - use 00:a0:c6:00:00:00 instead of the address learned from the host - does't include any ethernet header at all Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list