On Sat, 2017-03-25 at 13:29 +0000, Colin Helliwell wrote: > > On 25 March 2017 at 06:31 Dan Williams <[email protected]> wrote: > > > > On Fri, 2017-03-24 at 13:53 +0000, Colin Helliwell wrote: > > > > > > On 23 March 2017 at 19:43 Dan Williams <[email protected]> wrote: > > > > > > > > On Thu, 2017-03-23 at 18:26 +0000, [email protected] > > > > om > > > > wrote: > > > > > > > > > NetworkManager[1398]: [1490292215.0368] (ttyMux1): modem > > > > > state > > > > > changed, 'connected' --> 'registered' (reason: user- > > > > > requested) > > > > > NetworkManager[1398]: [1490292215.0371] device (ttyMux1): > > > > > state > > > > > change: activated -> failed (reason 'modem-no-carrier') [100 > > > > > 120 > > > > > 25] > > > > > NetworkManager[1398]: [1490292215.0390] > > > > > active-connection[0x1f38140]: set state deactivated (was > > > > > activated) > > > > > NetworkManager[1398]: [1490292215.0395] > > > > > > > > We'll need ModemManager logs here; MM is saying the modem state > > > > changed, possibly due to status changes on the secondary AT > > > > port. > > > > NM > > > > hears that and terminates the connection. > > > > > > Log including MM below. > > > > > > But I think I've spotted the cause - the AT+CGACT? is getting a > > > 'deactivated' response (@ 09:28:54). Hence MM seeing it as being > > > disconnected. > > > > > > As Aleksander commented before (https://lists.freedesktop.org/arc > > > hive > > > s/modemmanager-devel/2017-March/004042.html), it doesn't make > > > sense > > > to have different PDP's across multiple TTYs. And indeed their > > > EHS5 > > > appears to behave sensibly i.e. indicates the port 1 PDP as > > > active > > > even if queried over [Primary] port 2. > > > > > > However, on trawling through the BGS2 docs, I've found that that > > > "PDP > > > contexts can be defined on any [mux] channel, but are visible and > > > usable only on the channel on which they are defined". > > > And doing some manual tests seems to confirm that - they can > > > indeed > > > be set up independantly on different ports. Nice 'feature'.... :S > > > (I'm wondering if that's also behind some of the other weird sh^t > > > I've been grappling with). > > > > That is... interesting. And unlike anything I've ever encountered > > before :) If there's a way to detect that it's a BGS2, then we'll > > need > > to special-case that device and stop ModemManager from polling > > bearer/connection status. We might also need to somehow suppress > > the > > MM disconnect behavior of sending CGACT=x,0 on the secondary port > > while > > trying to ensure that PPP terminates and the data port returns to > > command mode. > > > > I wondered about altering the MM behaviour for it too - wasn't sure > if it would be sane/possible to mess with with its 'view of the > world' though. (Or, especially, worried about the likelihood of me > doing it badly ;) ). Would it and/or NM lose some of its consequent > abilities by no longer polling the connection status?
If the connection drops, but pppd is unable to figure that out (because the firmware doesn't send the LCP TermReq or something), then you'll have to have an external script manually do health checking and kill the connection when it times out. MM's connection polling is an attempt to see whether this has happened through actual modem commands (as opposed to an IP 'ping' or something) and handle termination. You don't get that if you're using PPP and can't reference the PDP context on a secondary port. > In part I'm tempted to drop the BGS2 as a 'bad job' and just use > EHS5. Trouble is that many of our applications don't need the 3G > capability of the latter, and there's quite a significant difference > in BOM cost between the two. Eh, it doesn't sound *that* bad, we can make it work. As long as there aren't too many more oddities... > I guess the "model" string would identify it? Is it serially connected? Or USB? Dan _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
