Graham Inggs <graham.in...@uct.ac.za> writes: >> I think we should add this device ID to qmi_wwan then, which also is >> likely to fix the mac address problem. > > Agreed, switching to qmi_wwan worked perfectly. For reference, the commands > were: > > modprobe qmi_wwan > echo 2-5:1.1 >/sys/bus/usb/drivers/cdc_ether/unbind > echo 12d1 14ac >/sys/bus/usb/drivers/qmi_wwan/new_id > > 'usb-devices' then showed: > > T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=12d1 ProdID=14ac Rev=00.00 > S: Manufacturer=Huawei Technologies > S: Product=HUAWEI Mobile > C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 1 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=ff Driver=qmi_wwan > I: If#= 2 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=qmi_wwan > I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > 'mmcli -L' showed: > Found 1 modems: > /org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] 8 > > mmcli -m 0 --simple-connect="apn=internet" > ifconfig wwan0 up > dhclient wwan0 > > 'ifconfig wwan0' showed: > wwan0 Link encap:Ethernet HWaddr 02:50:f3:00:00:00 > inet addr:197.107.110.16 Bcast:197.107.110.31 Mask:255.255.255.224 > inet6 addr: fe80::50:f3ff:fe00:0/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:17 errors:0 dropped:0 overruns:0 frame:0 > TX packets:109 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:1834 (1.8 KB) TX bytes:17308 (17.3 KB) > > And the connection was working!
Nice! Unexpected, but very good to know. So this particular MAC address firmware issue is related to the AT^NDISDUP implementation. That's a big part of the firmware implementation which is never used on Windows and therefore hardly ever tested. So it's not too surprising that it is buggy. Another indication that we should ignore the NDISDUP command whenever we can, and use the same management protocols the Windows driver uses. Still don't know what that could be on the E3276 though. You have a nice project there if you want something harder to work on :) Although I believe the NDISDUP implementation on that device is much better. At least it seems to work most of the time. >> Thanks. If it's only this address working, then the current workaround >> in qmi_wwan isn't enough. > > I powered everything off and tested again. When using cdc_ether and > NDISDUP to make the connection, it only worked with the 0/1/2/3/4/5 > MAC address. When using qmi_wwan and mmcli to make the connection, it > worked with the 02:50:f3:00:00:00 MAC address. OK. That clearly shows that I have missed a big part of the picture here. I have absolutely no idea why this works. And that probably means that the workaround I put into qmi_wwan is pointless. Well, the good news is that the workaround still should be harmless. Hopefully... >> Do you have a recent version of the qmi_wwan driver? It's easy to find >> out with your device: If the wwan0 address is a random one, then the >> driver has applied the workaround. It would be interesting to know if >> this works. You can connect the same way you do with cdc_ether if you >> want to test it. > > The MAC address wasn't random, it was always 02:50:f3:00:00:00. Because your qmi_wwan version hasn't got the recent firmware bug workaround series. But your tests shows that these don't make any difference in your case anyway. The MAC address will probably change once you upgrade to a driver version with that particular workaound, but I don't think that should cause any problems. By all means let me know if it does! Thanks for all your excellent testing. This was most useful. I'll submit the necessary patches now. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
