Cdc_ether ethertype Unknown (0x0808) on Huawei ME909u-521

Hi,

I'm using a Huawei ME909u-521 with cdc_ether in lede-17.01 on a Marvell Armada 385 device.
This is the (default) mode, where dailup / NDIS connection is done via AT commands, but user data arrives at a cdc_ether usb0 device.

Connection and DHCP work without problems, but the received traffic (except ARP) is garbage, this is my tcpdump.

22:29:17.047299 ARP, Request who-has 10.99.139.238 tell 10.99.139.237, length 28
22:29:17.048656 ARP, Reply 10.99.139.238 is-at 02:50:f3:00:00:00, length 28
22:29:18.427345 IP 10.99.139.237.35445 > 8.8.8.8.53: 59545+ A? 0.lede.pool.ntp.org. (37)
22:29:18.428611 IP 10.99.139.237.35445 > 8.8.4.4.53: 59545+ A? 0.lede.pool.ntp.org. (37)
22:29:18.429997 IP 10.99.139.237.35445 > 8.8.8.8.53: 60825+ AAAA? 0.lede.pool.ntp.org. (37)
22:29:18.431380 IP 10.99.139.237.35445 > 8.8.4.4.53: 60825+ AAAA? 0.lede.pool.ntp.org. (37)
22:29:18.522182 00:00:2c:11:29:76 > 45:00:00:81:be:96, ethertype Unknown (0x0808), length 129: 
        0x0000:  0808 0a63 8bed 0035 8a75 006d 9574 e899  ...c...5.u.m.t..
        0x0010:  8180 0001 0004 0000 0000 0130 046c 6564  ...........0.led
        0x0020:  6504 706f 6f6c 036e 7470 036f 7267 0000  e.pool.ntp.org..
        0x0030:  0100 01c0 0c00 0100 0100 0000 4500 0450  ............E..P
        0x0040:  5c7e 41c0 0c00 0100 0100 0000 4500 04b9  \~A.........E...
        0x0050:  90a1 aac0 0c00 0100 0100 0000 4500 0453  ............E..S
        0x0060:  4489 4cc0 0c00 0100 0100 0000 4500 0450  D.L.........E..P
        0x0070:  4088 25                                  @.%
22:29:18.523140 00:00:2c:11:98:c8 > 45:00:00:78:53:51, ethertype Unknown (0x0808), length 120: 
        0x0000:  0404 0a63 8bed 0035 8a75 0064 ecac ed99  ...c...5.u.d....
        0x0010:  8180 0001 0000 0001 0000 0130 046c 6564  ...........0.led
        0x0020:  6504 706f 6f6c 036e 7470 036f 7267 0000  e.pool.ntp.org..
        0x0030:  1c00 01c0 1300 0600 0100 0005 a700 2b01  ..............+.
        0x0040:  6205 6e74 706e 73c0 1c0a 686f 7374 6d61  b.ntpns...hostma
        0x0050:  7374 6572 c013 5983 1531 0000 1518 0000  ster..Y..1......
        0x0060:  1518 0012 7500 0000 0e10                 ....u.....

even ICMP replys are received this way:

22:30:58.840592 IP 10.99.139.237 > 8.8.8.8: ICMP echo request, id 44299, seq 0, length 64
22:30:58.902774 00:00:2c:01:e8:49 > 45:00:00:54:00:00, ethertype Unknown (0x0808), length 84: 
        0x0000:  0808 0a63 8bed 0000 a54c ad0b 0000 811e  ...c.....L......
        0x0010:  2c89 0000 0000 0000 0000 0000 0000 0000  ,...............
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000                           ......
22:30:59.842471 IP 10.99.139.237 > 8.8.8.8: ICMP echo request, id 44299, seq 1, length 64
22:30:59.888883 00:00:2c:01:e8:49 > 45:00:00:54:00:00, ethertype Unknown (0x0808), length 84: 
        0x0000:  0808 0a63 8bed 0000 f901 ad0b 0001 1e68  ...c...........h
        0x0010:  3b89 0000 0000 0000 0000 0000 0000 0000  ;...............
        0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0040:  0000 0000 0000                           ......

as said, this happens most of the time but not always, sometimes (after rebooting / resetting the modem several times) everything works, how it should be.
I've tried this with 2 different LTE SIMs from different networks, a UMTS-only SIM works tough.

Does anyone have an idea what might be going on here?

Buggy firmware. This is a well known problem with Qualcomm based LTE modems. You are receiving raw IP packets without any ethernet header. Notice the destination MAC address (i.e. the first 6 bytes of the frame). It starts with 45, which is typical for an IPv4 packet (20 bytes header).

The 0808 is actually part of the IP source address. You might want to ping other addresses and see the "ethertype" change accordingly...

You might be more successful forcing the qmi_wwan driver on this device instead. It has a workaround for this bug. See the comment and code at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/qmi_wwan.c#n447

Fun fact: Fixing this issue in the modem firmware is apparently so difficult that Sierra Wireless has borrowed the workaround (including my eplanatory comment!) for their GobiNet driver :slight_smile:

many thanks for your reply, I was suspecting something like this, but it strangely only seems to happen with LTE, I've never had such problems with 909s-120 modems.
I'll try qmi_wwan tomorrow.

The symptom "works on UMTS, but fails on LTE" is also typical for this firmware bug. Note that it doesn't depend directly on the SIM, but on the actual network connection. Which makes it even more interesting. I don't know of any other bug which has a similar dependency on time and place.