Hello Ulrich, I tried to apply this patch, it seems nearly all of what's contained is present in 1.8. I had some issues getting it to apply, would it be possible for you recreate this patch for me (perhaps with only the necessary elements)?
Ideally I would like to be using 1.12.x. I'm still having all sorts of trouble with TOBY L201, and Sara R410 when using Modem Manger. Thanks, *Cale CollinsField Applications EngineerGateworks Corporation* (805)781-2000 x37 3026 S. Higuera, San Luis Obispo, CA 93401 www.gateworks.com On Tue, Dec 10, 2019 at 3:08 AM Ulrich Mohr <u.m...@semex-engcon.com> wrote: > Hey, > > I tried to reconstruct what I did to work around the problem. > > 1. When dial in takes place, I check upfront whether there is an active > context that matches the requested one. If there is one, I use it, and > skip activating another one. This prevents creating a secondary context > when the default context is already active (which might fail as shown by > the recent bug report -- some providers do not allow a secondary > context, e.g. vodafone DE). > > 2. I seen cases where the default context does not match the APN at all. > In this case, the first step would not detect the active context as the > right one and create a second one. In case I've seen that, the creation > of the second context succeeded, but the context is not used by the > modem (because ublox does not set routes to the secondary context). > Therefore, I also adapt the routes in the modem to match the new context. > > I think that what I did is far from perfects, because theses two > measures will fail when only one context is allowed AND the default > context does not match the default one (although I never seen this so > far). Also, it is not the recommended way from the ublox manuals, since > they request to use set default eps bearer in case the network provided > one does not work. > > I attach the patch I use at the moment (based on version 1.7.999.) > Please be aware that this also includes (inactive) code from other > things I tried, e.g. setting the default bearer as requested by the > ublox manuals. > > That's unfortunately all I can provide at the moment, sorry for that. > > Best regards, > > Uli > > Am 10.12.2019 um 10:23 schrieb Aleksander Morgado: > > On Fri, Dec 6, 2019 at 9:11 AM Ulrich Mohr <u.m...@semex-engcon.com> > wrote: > >> Hi, > >> > >> I am not sure, but I think that this is a problem with the UBlox modems > I was facing before with a TOBY 210. > >> > >> The problem is that the modem does an automatic registration on the LTE > network using its default APN (that it gets from the network, when I > understand right). That is what you see (m2m.com.attz.mnc170.mcc310.gprs) > as context 4: (which is the default LTE bearer on TOBY). Unfortunately, > that does not match the one your have given manually, so ModemManager tries > to build up a connection using the secondary context with the APN settings > you have given -- which fails, because the service provider does not allow > a secondary connection while the first one is active. > >> > >> What I am not completely clear about is, under which circumstances you > get such a long default APN name (not matching the 'official' ones) from > the network. > >> > > The "long" name you get is when the bearer is already connected to > > that APN, so the name includes the MCCMNC of the operator. > > ModemManager already does a "loose" matching of the APNs and they > > should already match that one in context 4 if available: > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/blob/master/src/mm-modem-helpers.c#L1506 > > > > As you said, MM should have attempted to use context #4 instead of #1 > > as #4 was already connected. The problem is that the logic looking for > > which context to use stops as soon as it finds a matching one, and in > > this case it found #1 before #4. We could extend the logic to "prefer" > > an APN that is reported with MCCMNC if there are more than one > > matching, and I believe that should work. > > > >> @Aleksander: See > https://lists.freedesktop.org/archives/modemmanager-devel/2018-August/006633.html > >> > >> I heavily change the ublox plugin to work around that -- unfortunately > I never found the time to bring it to a deliverable state, and at the > moment, I can't even remember what exactly I did. But I can provide the > sources if needed.... > > Yes, please, can you do that? > > > > > -- > Best regards / Mit freundlichen Grüßen / Salutations distinguées > > Ulrich Mohr > > SEMEX-EngCon GmbH > Carl-Merz-Strass 26 > 76275 Ettlingen > Phone: +49 (0) 7243 5143596 > email: u.m...@semex-engcon.com > ___________________________________________ > Executive board: A. Stiegler, H.-J. Nitzpon > Commercial register: Mannheim, HRB 718881 > Company domicile: Ettlingen > > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
