Problem with modem in ZTE MF286R

@bmork I need your help.

Router: ZTE MF286R with modem - Marvell based PXA1826, see https://github.com/openwrt/openwrt/pull/9274

Modem:

OK
ati
Marvell

OK
at+cgmr
BD_ENAUTMF286RMODULEV1.0.0B07
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1489 Rev=ff.ff
S:  Manufacturer=ZTE
S:  Product=ZTE
S:  SerialNumber=123456789ABCD
C:* #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=  2mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
A:  FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I:* If#= 0 Alt= 0 #EPs= 1 Cls=e0(wlcon) Sub=01 Prot=03 Driver=rndis_host
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=1ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=cdc_acm
E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=(none)
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Problem - connection is not working. I use these commands (discovered by sniffing original firmware):
(SIM is pinless, APN is internet - Polish ISP Play)

AT+ZGDCONT=5,"IP","internet",0
AT+ZGPCOAUTH=5,"","",0
AT+ZGACT=1,5

In terminal:

OK
AT+CFUN=1
OK
AT+ZGDCONT=5,"IP","internet",0
OK
AT+ZGPCOAUTH=5,"","",0
OK
AT+ZGACT=1,5
OK

+ZCONSTAT: 1,5

+ZGIPDNS: 5,"IP","10.155.212.195","10.155.212.195","185.89.185.2","89.108.202.21","","","",""
at+cpin?
+CPIN: READY

Terminating...
Skipping tty reset...
Thanks for using picocom

Now, I can use dhcp on interface usb0:

root@OpenWrt:~# ifconfig usb0 up
root@OpenWrt:~# udhcpc -i usb0
udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending select for 10.155.212.195
udhcpc: lease of 10.155.212.195 obtained, lease time 7200
udhcpc: ip addr add 10.155.212.195/255.255.255.0 broadcast 10.155.212.255 dev usb0
udhcpc: setting default routers: 10.155.212.60
root@OpenWrt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.155.212.60   0.0.0.0         UG    0      0        0 usb0
10.155.212.0    0.0.0.0         255.255.255.0   U     0      0        0 usb0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan

root@OpenWrt:~# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr C2:EF:11:DB:06:BF  
          inet addr:10.155.212.195  Bcast:10.155.212.255  Mask:255.255.255.0
          inet6 addr: fe80::c0ef:11ff:fedb:6bf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2122 (2.0 KiB)  TX bytes:2504 (2.4 KiB)

It looks similar to Mikrotik R11e-LTE6. But there's no transmission, you can only ping the gateway, nothing else.

root@OpenWrt:~# ping 10.155.212.60
PING 10.155.212.60 (10.155.212.60): 56 data bytes
64 bytes from 10.155.212.60: seq=0 ttl=64 time=19.796 ms
64 bytes from 10.155.212.60: seq=1 ttl=64 time=0.823 ms
64 bytes from 10.155.212.60: seq=2 ttl=64 time=1.244 ms
^C
--- 10.155.212.60 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.823/7.287/19.796 ms

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

Do you have experience with a similar modem? What else can be done?
For more information and original connection log see thread on out forum: https://eko.one.pl/forum/viewtopic.php?id=21859 (in Polish, use google translator).

Try this: Wwan dhcp always get a subnet why? - #2 by bmork

1 Like

I'm afraid I don't have much to offer. That looks very good to me so far. You get a reasonable dhcp reply, and can ping the gateway. So we know the modem answers arp and that we can transmit ip packets both ways over the USB link. There should not be more to it.

You are sure you don't have any iptable rules messing up?

No, the firewall file is not touched, all system is in default state.

AndrewZ: still nothing, it also doesn't work.

AT+CFUN=1
OK
AT+ZGDCONT=5,"IP","internet",0
OK
AT+ZGPCOAUTH=5,"","",0
OK
AT+ZGACT=1,5
OK

+ZCONSTAT: 1,5

+ZGIPDNS: 5,"IP","10.146.118.141","10.146.118.141","185.89.185.2","89.108.202.21","","","",""

Terminating...
Skipping tty reset...
Thanks for using picocom
root@OpenWrt:~# ifconfig usb0 10.146.118.141 netmask 255.255.255.255
root@OpenWrt:~# ifconfig usb0 -arp
root@OpenWrt:~# ip route add default dev usb0
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 usb0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 br-lan
root@OpenWrt:~# ifconfig usb0
usb0      Link encap:Ethernet  HWaddr 66:0D:19:E7:62:16  
          inet addr:10.146.118.141  Bcast:10.255.255.255  Mask:255.255.255.255
          inet6 addr: fe80::640d:19ff:fee7:6216/64 Scope:Link
          UP BROADCAST RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:31 errors:0 dropped:0 overruns:0 frame:0
          TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2712 (2.6 KiB)  TX bytes:28498 (27.8 KiB)

Have you tried pinging provider's DNS and/or their web-site IP?
Could you run tcpdump on usb0 in another shell and show the output?

Yes, no reply to ping from dns, google, my site etc.

+ZCONSTAT: 1,5

+ZGIPDNS: 5,"IP","10.104.202.32","10.104.202.32","185.89.185.2","89.108.202.21","","","",""


Thanks for using picocom
root@OpenWrt:~# ifconfig usb0 up
root@OpenWrt:~# udhcpc -i usb0
udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending select for 10.104.202.32
udhcpc: lease of 10.104.202.32 obtained, lease time 7200
udhcpc: ip addr add 10.104.202.32/255.255.255.0 broadcast 10.104.202.255 dev usb0
udhcpc: setting default routers: 10.104.202.223
root@OpenWrt:~# 

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
31 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# 


listening on usb0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:11:12.560004 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 0, length 64
20:11:13.546861 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 0, length 64
20:11:13.565933 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 1, length 64
20:11:13.604592 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 1, length 64
20:11:14.566147 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 2, length 64
20:11:14.614601 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 2, length 64
20:11:15.566370 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 3, length 64
20:11:15.632842 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 3, length 64
20:11:16.566592 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 4, length 64
20:11:16.614716 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 4, length 64
20:11:17.566826 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 5, length 64
20:11:17.572570 ARP, Request who-has 10.104.202.223 tell 10.104.202.32, length 28
20:11:17.573245 ARP, Reply 10.104.202.223 is-at 12:30:81:e8:c6:01 (oui Unknown), length 28
20:11:17.600734 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 5, length 64
20:11:18.567058 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 6, length 64
20:11:18.598607 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 6, length 64
20:11:19.567298 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 7, length 64
20:11:19.614606 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 7, length 64
20:11:20.567539 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 8, length 64
20:11:20.596736 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 8, length 64
20:11:21.567782 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 9, length 64
20:11:21.602605 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 9, length 64
20:11:22.568023 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 10, length 64
20:11:22.618730 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 10, length 64
20:11:23.568265 IP 10.104.202.32 > 8.8.8.8: ICMP echo request, id 4968, seq 11, length 64
20:11:23.620730 IP 8.8.8.8 > 10.104.202.32: ICMP echo reply, id 4968, seq 11, length 64
^C
26 packets captured
26 packets received by filter
0 packets dropped by kernel

please repeat tcpdump with -v added

tcpdump: listening on usb0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:24:43.490940 IP (tos 0x0, ttl 64, id 22694, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 4, length 64
20:24:44.491181 IP (tos 0x0, ttl 64, id 22894, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 5, length 64
20:24:44.740562 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.104.202.223 tell 10.104.202.32, length 28
20:24:44.741223 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.104.202.223 is-at 12:30:81:e8:c6:01 (oui Unknown), length 28
20:24:45.491399 IP (tos 0x0, ttl 64, id 23097, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 6, length 64
20:24:46.491625 IP (tos 0x0, ttl 64, id 23300, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 7, length 64
20:24:47.491838 IP (tos 0x0, ttl 64, id 23492, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 8, length 64
20:24:48.492046 IP (tos 0x0, ttl 64, id 23581, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 9, length 64
20:24:49.492264 IP (tos 0x0, ttl 64, id 23603, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 10, length 64
20:24:50.492507 IP (tos 0x0, ttl 64, id 23803, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 11, length 64
20:24:51.494046 IP (tos 0x0, ttl 64, id 24050, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 12, length 64
20:24:52.494937 IP (tos 0x0, ttl 64, id 24180, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 13, length 64
20:24:53.495838 IP (tos 0x0, ttl 64, id 24241, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 14, length 64
20:24:54.496078 IP (tos 0x0, ttl 64, id 24290, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 15, length 64
20:24:55.496321 IP (tos 0x0, ttl 64, id 24377, offset 0, flags [DF], proto ICMP (1), length 84)
    10.104.202.32 > 8.8.8.8: ICMP echo request, id 5850, seq 16, length 64

Very confused now. This shows that you do get replies. So why doesn't ping report them? Is there something wrong with those icmp echo reply packets?

Very confused too... You had replies on the 1st run but they are not visible on the 2nd with -v.
Can you run tcpdump -i usb0 -w /tmp/somename.cap and share the output file?

Output of:

root@OpenWrt:~# udhcpc -i usb0
udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 10.165.183.51
udhcpc: lease of 10.165.183.51 obtained, lease time 7200
udhcpc: ip addr add 10.165.183.51/255.255.255.0 broadcast 10.165.183.255 dev usb0
udhcpc: setting default routers: 10.165.183.204
root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
12 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# ping google.com
ping: bad address 'google.com'
root@OpenWrt:~# wget -O /dev/null 8.8.8.8
Downloading '8.8.8.8'
Failed to allocate uclient context
root@OpenWrt:~# wget -O /dev/null http://8.8.8.8
Downloading 'http://8.8.8.8'
^CFailed to send request: Operation not permitted
root@OpenWrt:~# wget -O /dev/null http://google.com
Downloading 'http://google.com'
Failed to send request: Operation not permitted
root@OpenWrt:~#

I see that destination MAC for the ping replies from Google differs, for some reason from destination MAC of the modem/gateway. It differs from the host MAC, so no surprise the replies get dropped by Linux.
Request:

Frame 10: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 10, 2022 20:10:54.837785000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1644520254.837785000 seconds
    [Time delta from previous captured frame: 0.935916000 seconds]
    [Time delta from previous displayed frame: 0.935916000 seconds]
    [Time since reference or first frame: 5.001317000 seconds]
    Frame Number: 10
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: a6:d3:2b:53:d7:81 (a6:d3:2b:53:d7:81), Dst: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb)
    Destination: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb)
        Address: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: a6:d3:2b:53:d7:81 (a6:d3:2b:53:d7:81)
        Address: a6:d3:2b:53:d7:81 (a6:d3:2b:53:d7:81)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.165.183.51, Dst: 8.8.8.8
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 84
    Identification: 0xa4b5 (42165)
    Flags: 0x40, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 64
    Protocol: ICMP (1)
    Header Checksum: 0xc40b [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 10.165.183.51
    Destination Address: 8.8.8.8
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x1c1c [correct]
    [Checksum Status: Good]
    Identifier (BE): 3845 (0x0f05)
    Identifier (LE): 1295 (0x050f)
    Sequence Number (BE): 5 (0x0005)
    Sequence Number (LE): 1280 (0x0500)
    [Response frame: 13]
    Data (56 bytes)
        Data: 0880c4590000000000000000000000000000000000000000000000000000000000000000…
        [Length: 56]

Response:

Frame 13: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 10, 2022 20:10:55.032865000 CET
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1644520255.032865000 seconds
    [Time delta from previous captured frame: 0.035124000 seconds]
    [Time delta from previous displayed frame: 0.035124000 seconds]
    [Time since reference or first frame: 5.196397000 seconds]
    Frame Number: 13
    Frame Length: 98 bytes (784 bits)
    Capture Length: 98 bytes (784 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:data]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb), Dst: 16:a0:02:28:ba:1f (16:a0:02:28:ba:1f)
    Destination: 16:a0:02:28:ba:1f (16:a0:02:28:ba:1f)
        Address: 16:a0:02:28:ba:1f (16:a0:02:28:ba:1f)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb)
        Address: ea:b2:01:e0:71:bb (ea:b2:01:e0:71:bb)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 8.8.8.8, Dst: 10.165.183.51
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 84
    Identification: 0x0000 (0)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 114
    Protocol: ICMP (1)
    Header Checksum: 0x76c1 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 8.8.8.8
    Destination Address: 10.165.183.51
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0
    Checksum: 0x241c [correct]
    [Checksum Status: Good]
    Identifier (BE): 3845 (0x0f05)
    Identifier (LE): 1295 (0x050f)
    Sequence Number (BE): 5 (0x0005)
    Sequence Number (LE): 1280 (0x0500)
    [Request frame: 10]
    [Response time: 195,080 ms]
    Data (56 bytes)
        Data: 0880c4590000000000000000000000000000000000000000000000000000000000000000…
        [Length: 56]

Nice catch! The rndis_host driver will try to query the device for the address and then fall back to using a random one. Which it obviously has done here. But it doesn't look like the device is prepared for that. So I wonder if the device expects the host driver to query some other OID? I seem to recall having seen a device like that, but can't remember the details.

The current rndis_host code is:

/* Get designated host ethernet address */
	reply_len = ETH_ALEN;
	retval = rndis_query(dev, intf, u.buf,
			     RNDIS_OID_802_3_PERMANENT_ADDRESS,
			     48, (void **) &bp, &reply_len);
	if (unlikely(retval< 0)) {
		dev_err(&intf->dev, "rndis get ethaddr, %d\n", retval);
		goto halt_fail_and_release;
	}

	if (bp[0] & 0x02)
		eth_hw_addr_random(net);
	else
		eth_hw_addr_set(net, bp);

Maybe we should try querying RNDIS_OID_802_3_CURRENT_ADDRESS there as well?

EDIT: found out why that code seemed so familiar: https://lkml.org/lkml/2016/7/13/970

And immediately started worrying that I might have screwed up this. Maybe the modem does return its wanted host mac address, but it is a generated one with the local bit properly set? Then we'd ignore the adress and set a random one instead. Probably not good.

@cezary are you able to build the rndis_host driver with some additional printk's to figure out what's happening here? Interesting questions: Does the modem reply to the "perm addr" request? And if so, what is the address it returns? If not, does it reply to a "current addr" request?

Changing RNDIS_OID_802_3_PERMANENT_ADDRESS to RNDIS_OID_802_3_CURRENT_ADDRESS do nothing, no transmission.

Sure, I can compile. Can you make some patch on what you want to see?

Mabye something like this:

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index 1505fe3f87ed..268b2bc25c32 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -418,8 +418,10 @@ generic_rndis_bind(struct usbnet *dev, struct usb_interface *intf, int flags)
 		goto halt_fail_and_release;
 	}
 
-	if (bp[0] & 0x02)
+	if (bp[0] & 0x02) {
+		dev_err(&intf->dev, "ignoring macaddr: %pM\n", bp);
 		eth_hw_addr_random(net);
+	}
 	else
 		ether_addr_copy(net->dev_addr, bp);
 

or maybe even better: Just try without that test and see of it works?

I fear we must go back in time and fix that bugfix...

Ha!

^C

root@MiFi:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=115 time=182.780 ms
64 bytes from 8.8.8.8: seq=1 ttl=115 time=45.490 ms
64 bytes from 8.8.8.8: seq=2 ttl=115 time=83.045 ms
64 bytes from 8.8.8.8: seq=3 ttl=115 time=44.068 ms
64 bytes from 8.8.8.8: seq=4 ttl=115 time=81.746 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 5 packets received, 16% packet loss
round-trip min/avg/max = 44.068/87.425/182.780 ms
root@MiFi:~# ping onet.pl
PING onet.pl (99.83.207.202): 56 data bytes
64 bytes from 99.83.207.202: seq=0 ttl=119 time=45.581 ms
64 bytes from 99.83.207.202: seq=1 ttl=119 time=81.575 ms
^C
--- onet.pl ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 45.581/63.578/81.575 ms
root@MiFi:~# ping google.com
PING google.com (142.250.203.142): 56 data bytes
64 bytes from 142.250.203.142: seq=0 ttl=115 time=75.028 ms
64 bytes from 142.250.203.142: seq=1 ttl=115 time=26.928 ms
64 bytes from 142.250.203.142: seq=2 ttl=115 time=75.706 ms
64 bytes from 142.250.203.142: seq=3 ttl=115 time=105.463 ms
64 bytes from 142.250.203.142: seq=4 ttl=115 time=21.232 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 21.232/60.871/105.463 ms

Without testing

-	if (bp[0] & 0x02)
-		eth_hw_addr_random(net);
-	else
               eth_hw_addr_set(net, bp);
1 Like

Should I whip up a patch to fix that, since I opened PR for supporting the device? At least I could include a backport for it.
cc'ing in @chunkeey :wink:

That would be great. But it must fix the original problem Kristian had back in 2016. Can't just delete the fallback. Maybe go back to his fix, from before I messed up this with my simplified ideas...

oh god no. That's the local bit.