Disconnect on Data Transfer

[Reinhard Speyerer]

On Sun, Apr 21, 2019 at 07:16:10AM -0400, John Marrett wrote:
> 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.
>

Hi John,

given the ModemManager version you use Raw IP mode should automatically
be used if supported by the kernel. You can also crosscheck this by
looking at /sys/class/net/<ifname>/qmi/raw_ip and/or qmicli
--wda-get-data-format output.

> 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.

Using a MTU size of 1280 was meant as a "super safe" value to rule out
potential problems with larger MTU values for testing purposes. It was
not meant as a general recommendation for production use.

Regards,
Reinhard