(In reply to Andrew Macks from comment #0)
> My apologies in advance for abusing this Bugzilla for a bug which is
> essentially related to hardware and kernel drivers more likely than
> ModemManager itself.
> 
> Continuing on from #92725 which had a post mentioning this.
> 
> [ 1476.029536] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1479.027367] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1482.027657] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1485.017431] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1488.017558] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1491.027529] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1494.027230] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1497.027453] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1500.027338] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1503.027646] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> [ 1506.037279] cdc_ncm_rx_verify_nth16: cdc_mbim 2-1:2.0 wwan0: invalid
> NTH16 signature <0x686d636e>
> 
> I am getting this reliably on multiple systems here with Huawei E3372 modems
> purchased in Estonia.
> 
> I do get IP configuration via MBIM and modem appears to be online otherwise,
> but there are no successful RX packets.  After applying the debugging info
> from the previous bug, I found these in my dmegs which fit with the count
> increments.
> 
> Please let me know how I can help :)

Which kernel version are you using? You need at least v4.4-rc6, or an older version which has backported the following commit:

commit f8c0cfa5eca902d388c0b57c7ca29a1ff2e6d8c6
Author: Bjørn Mork <bjorn@mork.no>
Date:   Sat Dec 5 13:01:50 2015 +0100

    net: cdc_mbim: add "NDP to end" quirk for Huawei E3372
    
    The Huawei E3372 (12d1:157d) needs this quirk in MBIM mode
    as well. Allow this by forcing the NTB to contain only a
    single NDP, and add a device specific entry for this ID.
    
    Due to the way Huawei use device IDs, this might be applied
    to other modems as well.  It is assumed that those modems
    will be based on the same firmware and will need this quirk
    too.  If not, it will still not harm normal usage, although
    multiplexing performance could be impacted.
    
    Cc: Enrico Mioso <mrkiko.rs@gmail.com>
    Reported-by: Sami Farin <hvtaifwkbgefbaei@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Acked-By: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Hi, yes.  We have backported this patch into our kernel.

It appears to be being used aswell according to dmesg:

[   16.464435] cdc_mbim 2-1:2.0: setting rx_max = 16384
[   16.464637] cdc_mbim 2-1:2.0: NDP will be placed at end of frame for this device.
[   16.464810] cdc_mbim 2-1:2.0: cdc-wdm0: USB WDM device
[   16.465305] cdc_mbim 2-1:2.0 wwan0: register 'cdc_mbim' at usb-tegra-ehci.2-1, CDC MBIM, da:1e:a5:53:13:9b

And you still get the same "invalid NTH16 signature" error messages with the "NDP at end of frame" quirk enabled?  Does anything change if you play with the different  /sys/class/net/wwan0/cdc_ncm/* attributes?

Yes, the same errors.  Have not tried without the quirk enabled on these machines.  Do you think it is worth a try?

Any particular settings you can recommend fiddling with in cdc_ncm?  And can I fiddle with them on the fly, or should try before I activate the connection (to avoid alignment issues messing it all up?)

rx_max is the one most likely to make a difference, because we set it much lower than the firmware maximum.  But it cannot be set to the firmware maxium because that requires 32bit headers, which we do not support. So you can unfortunately not test the most interesting value..

min_tx_pkt might make a difference by either forcing padding of all frames or completely disable padding.

tx_max could make a difference if ZLPs are part of the equation.  Although I don't see how that could be...

See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-cdc_ncm for the documentation of these attributes

Sorry, forgot to answer the last qustion: You are supposed to be able to fiddle with all these on the fly, with the netdev being up and running.  Don't know if anyone but me ever tested that, though.  So don't be surprised if it crashes something :)

I believe this patch fixes the remaining issues with the E3372:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/usb/cdc_ncm.c?id=48906f62c96cc2cd35753e59310cb70eb08cc6a5

This patch is going into v4.5 and the currently maintained stable releases, so if you are reading this in a few weeks time then  you should not apply it yourself.  Upgrade your kernel instead.

For the record/history:  The patch above is applied unconditionally to all NCM and MBIM modems.  It is believed to fix the same problem with other Huawei MBIM modems, without the "NDP to end" quirk. This is confirmed on a Vodaphone K5160.

The E3372h-153 (using MBIM device ID 12d1:157d) still needs the "NDP to end" quirk in addition to the patch above, but is so far the only modem where this is quirk is known to be necessary in MBIM mode. This is handled by a device specific entry in the cdc_mbim driver, so none of the sysfs tweaks referred to in this bug are necessary.


Let me know if any of this is incorrect.