<colo>
blocktrron: are you referring to qmi, for LTE modems? via uqmi?
<blocktrron>
Yes
<f00b4r0>
curious why do we freeze feeds in the release SDK instead of tracking branch? Net result is when building a package with the sdk, the built version can be older than whatever is installable from opkg. Which leads to all sorts of headaches
<colo>
blocktrron: using it quite a bit for sensing SMS here - but I do not have ay weird qmi-related issues :)
<blocktrron>
i was using it with IoT roaming SIM cards. You can trigger a network-reattach and boy did the uqmi proto explode when doing so
<blocktrron>
also the PLMN selection does not seem to work, as the PLMN setting is reset before attaching
<blocktrron>
One thing special with the SIM card provide is also the fact it rejects PDP connection with v4v6 type (only supports v4) and the setting of pdptype in uqmi is never taken into account when creating the context
<blocktrron>
It worked well for me in the past, but the autoconnect feature openwrt employs recovers the data connection but in case you get detached from the network it just dies
<blocktrron>
I was wondering whether it is specific to the provider we use (1nce) but tried wit with an onomondo sim card and same story there
<blocktrron>
Onomondo however is really helpful for working on this, as they provide you with real-time signalling logs on their end.
Tapper has joined #openwrt-devel
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #openwrt-devel
<mrkiko>
hauke: Mangix: my buffalo wmbr I guess used an atheros phy
<mrkiko>
hauke: Mangix: I may be wrong but I have distant memories of it's dmesg
<mrkiko>
blocktrron: autoconnect won't inform you also if some parameters change, I would switch to MM if possible
<mrkiko>
blocktrron: and yes, I can understand MM is bigger in footprint ...
<mrkiko>
blocktrron: and as you probably know very well, things may vary on per-modem firmware basis, maybe it's not uqmi fault
valku has joined #openwrt-devel
<blocktrron>
mrkiko: pdp-type is not modem-firmware specific, we never supply this information in the beginning
<blocktrron>
It just connects a ipv4 handle and a ipv6 handle subsequently, however the PDN connection type is never well-defined (e.g. has to be set before creating the first handle)
<blocktrron>
Currently, it implicitly attempts a dual-stacked connection.
<mrkiko>
blocktrron: sorry - I may have been unclear. my consideration was general, not related to pdp in particular
<blocktrron>
the issue with the plmn connection is also pretty clear why it does not work, as normally it should be supplied with the connection request. If not set, it is reset
Daanct12 has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
xavifr has quit [Ping timeout: 480 seconds]
Kevinjil has quit [Remote host closed the connection]
<mrkiko>
blocktrron: seen your patches, great!! Thanks for your work