> Regarding the failing PPP: > Your enhancement probably to prevent a race is still a good idea in general. > However I've now experimented manually (with a terminal app), and I don't > think it is the Sig Quality which is breaking PPP. What I was actually doing > was waiting so long before starting PPP that the *modem* is timing out - > after the ATD it sends back 'hex' messages (presumably some sort of LCP > request) a number of times, and then eventually times out and sends 'NO > CARRIER'. This timeout also happens to be 30secs. > I haven't found any 'ETSI' spec which defines a timeout from data mode, and > nor is one mentioned in my modem's docs. However I did find a uBlox manual > which states different negotiation/timeout sequences for their different > modems > (https://www.u-blox.com/sites/default/files/u-blox-ATCommands_Manual_(UBX-13002752).pdf > , para 18.2). So maybe this behaviour is always manufacturer-specific. > It would though be better if MM caught the 'NO CARRIER' and set the state > back to disconnected?
MM should already be catching the NO CARRIER errors; could you gather debug logs while reproducing this to see why it didn't catch it? -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
