<div dir="ltr"><div dir="ltr"><div dir="ltr">Reinhard,<br></div><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
yes "DM capture"/dmrecord is the name of the corresponding Sierra Wireless<br>
tool. The created log files usually require commercial tools from Qualcomm<br>
or tools from UE vendors like Sierra Wireless for decoding.<br></blockquote><div><br></div><div>We're working to capture the behaviour and have Sierra Wireless analyse the resulting logs.</div><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > Alternatively you could also check whether one of the following makes the<br>
> > problem go away:<br>
> ><br>
> > 1. Switch to Linux kernel 4.5 or newer for testing so that ModemManager<br>
> >    uses Raw IP mode for QMI.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > 3. Reduce the MTU size to 1280 for testing.<br>
> ><br>
> ><br>
> AT&T also spoke about reducing MTU when we were experiencing issues; I<br>
> wasn't able to get an reason for why they thought it would help. Why do you<br>
> suggest lowering the MTU to 1280?<br>
> <br>
<br>
In order to avoid potential problems with IP fragmentation in the core<br>
network the MTU size should not exceed<br>
  MTUcn - sizeof(IP-header) - sizeof(UDP-header) - sizeof(GTP-header).<br>
A typical value returned by Qualcomm devices is 1430.<br>
<br>
The minimum IPv6 MTU is 1280, therefore it should be a safe value to<br>
assume for it to be supported on the mobile device.<br>
<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks very much for everyone's help, I'll update the list when there are new findings if no questions or suggestions are forthcoming.<br></div><div><br></div><div>-JohnF<br></div></div></div></div>