<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></head><body><div data-html-editor-font-wrapper="true" style="font-family: arial, sans-serif; font-size: 13px;">Hi John,<br><br>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.<br><br>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).<br><br>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.<br><br><signature>Greetings,<br><br>Karoly<br>___________________________________________________________________</signature><br><br>April 14, 2019 10:24 PM, "John Marrett" <<a target="_blank" tabindex="-1" href="mailto:johnf@zioncluster.ca?to=%22John%20Marrett%22%20<johnf@zioncluster.ca>">johnf@zioncluster.ca</a>> wrote:<br> <blockquote><div><div><div dir="ltr"><div dir="ltr"> <div>Reinhard,</div> <div></div> <div>Thanks for getting back to me so quickly, much appreciated.</div> <div> <blockquote style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex"><span>without Qualcomm diag logs on the MC7354 when the problem occurs it might<br>be very hard to find the root cause. In order to obtain them you would<br>probably have to define a custom udev rule to make ModemManager ignore<br>the diag port and also ask Sierra Wireless to provide you with their<br>Qualcomm logging frontend.</span></blockquote> <div></div> <div>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?</div> <div></div> <blockquote style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex"> <br><span>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.</span><br> </blockquote> <div></div> <div>I'll see if I can get access to a release with a newer kernel.</div> <div></div> <blockquote style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex"> <span>2. Apply commit 245d21190aec547c0de64f70c0e6de871c185a24<br>("qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect")<br>if not already present in the qmi_wwan version you use.<br><br>3. Reduce the MTU size to 1280 for testing.</span><br> </blockquote> <div></div> <div>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?</div> <div></div> <div>Thanks again,</div> <div></div> <div>-JohnF</div> </div> </div></div></div></div></blockquote> </div></body></html>