Disconnect on Data Transfer

[John Marrett]

Reinhard,


> yes "DM capture"/dmrecord is the name of the corresponding Sierra Wireless
> tool. The created log files usually require commercial tools from Qualcomm
> or tools from UE vendors like Sierra Wireless for decoding.
>

We're working to capture the behaviour and have Sierra Wireless analyse the
resulting logs.

We're also working with AT&T and Jasper support to understand if the data
is being delivered to the modem. There's no guarantee that the issue we are
seeing is occurring within the OS stack though I believe it likely.


> > > 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 switched to 4.14.67, I can't confirm if Modem Manager was using Raw IP
mode while running on this version. I wasn't able to reproduce the issue on
4.14 however I also had a lot of trouble recreating it on an impacted
release. It took 27 attempts before recreating the failure. We're waiting
for AT&T/Jasper analysis of this incident.

Recent in field transfers showed some devices which experienced this
disconnect on every attempted transfer while other devices completed the
transfer on the first attempt.

> > 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?
> >
>
> In order to avoid potential problems with IP fragmentation in the core
> network the MTU size should not exceed
>   MTUcn - sizeof(IP-header) - sizeof(UDP-header) - sizeof(GTP-header).
> A typical value returned by Qualcomm devices is 1430.
>
> The minimum IPv6 MTU is 1280, therefore it should be a safe value to
> assume for it to be supported on the mobile device.
>
>
I recreated the failure with an MTU of 1280, I don't believe it's directly
related to fragmentation but I would like to better understand this
recommendation.

We have seen some issues with fragment handling for oversized UDP packets
(IKE) however we haven't seen any issues with full frame TCP traffic. These
packets were sent by the host fragmented and outright dropped by the AT&T
network. I've looked at some network level captures that show quite large
packets passing without fragmentation. I'm not very eager to make this
change without good reason as it will increase overhead in a data cost
sensitive environment.

I wouldn't expect MTU issues to create problems affecting the entire
devices inbound connectivity, rather a single TCP stream might be affected,
does anyone have experience to the contrary?

Thanks very much for everyone's help, I'll update the list when there are
new findings if no questions or suggestions are forthcoming.

-JohnF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20190421/93a4a8c4/attachment.html>