Hi Denis,
On Mon, Sep 24, 2018 at 10:50 PM Denis Kenzior <[email protected]> wrote:
> Hi Giacinto,
>
> > So until the GPRS_AUTH_METHOD_NONE is actually introduced, you might
> > want to just get this upstream with the existing enumeration. E.g.
> > just
> > assume that if username & password is empty, the auth method is none.
> >
> >
> > I have pushed the new method NONE again, and I prefer to wait until it
> > is taken.
> >
> > The current solution is really a non-documented hack.
> > Checking whether user&password are empty to change the type of
> > authentication goes against the caller settings.
> > It is better to give an error so that there is a chance to have good
> > settings.
> >
>
> The issue is that you haven't properly addressed all the points that
> arise from adding a new enumeration. You're touching something that
> essentially affects every driver and not updating these properly. So
> take your pick, but nothing is going upstream until either this patch
> fits into the old framework, or the new framework is ready...
>
Actually I have. But I am gong to re-send the relevant patches I have
already sent all together again, with some more verbose explanation.
Admittedly, I have looked into atmodem, mbimmodem, qmimodem, and a few
others, but I will check all of them before re-submitting.
qmi is already defaulting to AUTH_NONE internally if not PAP and not CHAP.
for mbim I have a similar patch, atmodem checks that it is one of {PAP,
CHAP} and does an error if not. So it doesn't need update. Also for PPP the
specification clearly says that it only takes the two methods (even if it
doesn't mention that if user or pwd are empty it goes to NONE).
> > Fundamentally, your context activation has succeeded or it didn't.
> The
> > DHCP operation is purely local between the modem and the host. No
> > other
> > vendor in the world has this weird setup that you do. So I don't
> > really
> > know what to tell you here as this ^SWWAN interaction is
> fundamentally
> > broken and it can't go upstream in this form.
> >
> > Can ^SWWAN support static ip reporting instead of DHCP? That would
> be
> > preferred anyway as DHCP is slow and unneeded.
> >
> >
> > This is a discussion about how Gemalto products work.
> >
> > Admittedly, there are a few models, in the high-volume low-price range
> > (already deployed),
> > that won't return from AT^SWWAN until a DHCP exchange is performed, as
> > per Sebastian's comment above.
> >
>
> Can firmware be fixed / upgraded on these?
No, too many on the field, and nobody is willing to change A change needs
re-certifications around the world,
for both Gemalto and the customers, with the risk of new certification
rules that will require even more changes.
Unfortunately it is for these low-end models that the customers expect to
have a ready-made framework,
in order to have also limited costs on software development.
> The rest (which are the large majority) of the modules would allow a
>
> 'standard' treatment, but also work with the code above.
>
> So why don't we enable sane ones for now and deal with the insane ones
> later?
>
I can do this, but I need to know what options I have in the code.
If there is no way out, it means we have to maintain an out-of-tree branch.
> >
> > As per DHCP vs static, we have both, depending on the module.
> >
> > Just for information, I have stepped upon networks *requiring* DHCP:
> > in this kind of networks, an MBIM module that would normally return a
> > static settings,
> > returns 0x00 in the "IPv4 configuration Available" field in of the
> > IP_CONFIGURATION answer,
> > instead of the usual 0x0F (address, gateway, dns, mtu).
> > So, it looks like that DHCP has to be considered as a valid alternative
> > also in this case.
>
> This is fine. You just set the IP configuration method accordingly. We
> already have a few examples where the gprs_context driver might choose
> one or the other depending on whether support for a given command
> exists. This can be extended to support cases where the network
> requires DHCP. Which by the way is completely weird for cases such as
> PPP where no concept of DHCP really exists and your address has to be
> obtained by the time the context is activated. So I wouldn't mind some
> extra details on what is *actually* going on here under the hood.
>
> >
> > We cannot change every module and every network to fit our wishes.
> >
> > Back to the code, I don't see a solution at the moment other than that
> one.
> > I can add an 'if' to filter only the models that need it, but cannot
> > remove it completely.
> > And this code would be specific for the driver, I don't see why it
> > couldn't go upstream.
>
> So I would filter these models out from this driver. Or see if they can
> work with PPP based driver and we can deal with these later.
>
I have tried PPP on these models, it is accepted but fails. So no PPP
either.
Regards,
> -Denis
>
_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono
