I'm definitely able to pass full frame packets:
[device ~]$ ping -c 1 helium-ca.z-c.ca -s 1472 -M do
PING helium-ca.z-c.ca (159.203.35.89) 1472(1500) bytes of data.
1480 bytes from helium-ca.zioncluster.ca (159.203.35.89): icmp_seq=1 ttl=52
time=212 ms
--- helium-ca.z-c.ca ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 212.869/212.869/212.869/0.000 ms
I set the MTU to 1280 and I was able to recreate the issue, it doesn't
appear to help.
I'll have a newer kernel release ready to test soon but updating the kernel
in the field on these devices may be challenging.
-JohnF
On Sun, Apr 14, 2019 at 5:23 PM Karoly Pados <k...@tec4data.at> wrote:
> Hi John,
>
> I strongly advise you to lower your MTU to 1280. We used to have similar
> problems as yours, where normal operational traffic worked fine, but
> whenever there were larger transfers, packets wouldn't arrive anymore. It
> turned out our problem was the MTU. When data chunks were smaller than the
> recommended MTU value (most of the time since our application involves
> transferring mostly sensor data), things worked fine, but everything else
> got dropped. As soon as we limited our MTU, all our problems were solved.
>
> Unlike your case, I don't think we had disconnections like you mention,
> only serious packet loss. But from your mails it seems your MTU is not
> limited to 1280, so this is going to be another problem in your setup for
> sure. So I just wanted to chip in to help you eliminate at least one of
> your troubles. And who knows, maybe your disconnections are related after
> all (only one way to find out).
>
> So why limit your MTU to 1280? Because AT&T for some stupid reason set up
> their network to drop packets larger than that, and by experience I can
> tell you they are enforcing this rule.
>
> Greetings,
>
> Karoly
> ___________________________________________________________________
>
> April 14, 2019 10:24 PM, "John Marrett" <jo...@zioncluster.ca
> <jo...@zioncluster.ca?to=%22john%20marrett%22%20%3cjo...@zioncluster.ca%3E>>
> wrote:
>
> Reinhard,
> Thanks for getting back to me so quickly, much appreciated.
>
> without Qualcomm diag logs on the MC7354 when the problem occurs it might
> be very hard to find the root cause. In order to obtain them you would
> probably have to define a custom udev rule to make ModemManager ignore
> the diag port and also ask Sierra Wireless to provide you with their
> Qualcomm logging frontend.
>
> Sierra Wireless has previously made reference to a "DM capture" tool that
> will collect logs from the modem, this tool creates swi files that need to
> be decoded by Qualcomm support. Is this what you are referring to? Are
> there open tools I could use to decode these files?
>
>
> Alternatively you could also check whether one of the following makes the
> problem go away:
>
> 1. Switch to Linux kernel 4.5 or newer for testing so that ModemManager
> uses Raw IP mode for QMI.
>
> I'll see if I can get access to a release with a newer kernel.
>
> 2. Apply commit 245d21190aec547c0de64f70c0e6de871c185a24
> ("qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect")
> if not already present in the qmi_wwan version you use.
>
> 3. Reduce the MTU size to 1280 for testing.
>
> AT&T also spoke about reducing MTU when we were experiencing issues; I
> wasn't able to get an reason for why they thought it would help. Why do you
> suggest lowering the MTU to 1280?
> Thanks again,
> -JohnF
>
>
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
