On 08.12.2016 17:11, Bjørn Mork wrote:
Petr Štetiar <yn...@true.cz> writes:
Matti Laakso <malaa...@elisanet.fi> [2016-12-08 15:39:57]:
Hi,
I don't like the autoconnect at all, it being so unpredictable across
various models.
This autoconnect feature should burn in hell :-) The funny thing about this
feature is, that the behaviour is network specific[1] also.
I still can't find some time to dig more into this, like read the QMI docs
etc., but I'm still wondering how this could be possible. Maybe this
autoconnect setting is somehow transfered towards to the other end in network
operator's infrastructure?
Bjørn, any idea? :-)
I don't think that the autoconnect setting is "transferred" to the
network, rather it could be tied to a specific call profile index, which
has the wrong APN. If your Slovakian SIM card has several predefined
profiles, this could be the case. If your modem exposes a virtual serial
port which accepts AT-commands, you could use AT+CGDCONT? to check.
Closed source firmware does all sort of weird and unexpected stuff.
That's why we use OpenWrt/LEDE on the routers, after all :)
I don't think we can trust the modem firmware with complex features like
autoconnect. There are too many things that can go wrong. And we don't
have any way to debug or fix any of those issues when they.happen inside
the modem firmware "black box". How do you tell the difference between
autoconnect failed due to wrong APN from autoconnect failed due to low
signal, for example?
IMHO, we should depend on as few as possible of the most basic modem
firmware features. Any complex features like autoconnect can and should
be implemented as services running on the host, using those basic
features as building blocks.
Bjørn
I agree fully. That's why I added the autoconnect option in my last
patch and defaulted it to disabled.
Matti
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
