> On 27 March 2017 at 17:02 Dan Williams <[email protected]> wrote: > > 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... >
The way Cinterion/Gemalto seem - who knows....! But hey, I'm working thru them - with you guys' help ;) > > I guess the "model" string would identify it? > > Is it serially connected? Or USB? > They're PCB-mounted modules, so is (and would be) typically serial. They do do an 'Eval Board' with USB connection, but I'd be surprised if anyone took that route except for development/evaluation. _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
