02:04 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

09:00 <blocktrron> Anybody who has uses qmi with OpenWrt, faced "weird issues in the past and up for validating some fixes?

09:01 <blocktrron> I'm currently not sure if I am the one using it wrong or 50% of the options simply "did not work" in the past.

09:24 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 99.9% packages reproducible in our current test framework.)

10:26 <colo> blocktrron: are you referring to qmi, for LTE modems? via uqmi?

10:26 <blocktrron> Yes

11:09 <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

11:09 <colo> blocktrron: using it quite a bit for sensing SMS here - but I do not have ay weird qmi-related issues :)

11:15 <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

11:15 <blocktrron> also the PLMN selection does not seem to work, as the PLMN setting is reset before attaching

11:17 <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

11:18 <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

11:19 <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

11:19 <blocktrron> Onomondo however is really helpful for working on this, as they provide you with real-time signalling logs on their end.

12:38 <mrkiko> hauke: Mangix: my buffalo wmbr I guess used an atheros phy

12:38 <mrkiko> hauke: Mangix: I may be wrong but I have distant memories of it's dmesg

12:41 <mrkiko> blocktrron: autoconnect won't inform you also if some parameters change, I would switch to MM if possible

12:42 <mrkiko> blocktrron: and yes, I can understand MM is bigger in footprint ...

12:44 <mrkiko> blocktrron: and as you probably know very well, things may vary on per-modem firmware basis, maybe it's not uqmi fault

14:02 <blocktrron> mrkiko: pdp-type is not modem-firmware specific, we never supply this information in the beginning

14:02 <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)

14:03 <blocktrron> Currently, it implicitly attempts a dual-stacked connection.

14:04 <mrkiko> blocktrron: sorry - I may have been unclear. my consideration was general, not related to pdp in particular

14:05 <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

16:21 <mrkiko> blocktrron: seen your patches, great!! Thanks for your work

16:24 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (98.7% images and 100.0% packages reproducible in our current test framework.)

18:12 <Mangix> mrkiko: atheros phys are handled by the AT803X driver AFAIK

18:12 <Mangix> which poses the question why AR8216 is enabled on lantiq

18:14 <Mangix> blocktrron: your ath79 DSA commit updated: https://github.com/neheb/openwrt/commit/753461283d59c5a2dae9c63b19a14d3b4dba5c9c <-- completely untested

18:14 <Mangix> I only tested if it compiles

18:37 <schmars[m]> Ooh nice ath79 dsa

19:40 <philipp64> Do I need to do anything special to add a new project to the packages feed? Been so long since I did this last I can't remember...

19:48 <philipp64> I did everything in Contributing.md and https://openwrt.org/docs/guide-developer/packages ...

19:55 <hauke> mrkiko: thanks for the update

20:01 <Mangix> schmars[m]: not currently working with qca8k. dies after a while

20:01 <Mangix> hauke: for atheros phy, isn't the AT803X driver used?

20:02 <schmars[m]> but there's work happening, which i appreciate very much :-)

22:13 <blocktrron> Mangix: nixe seeing this been carried further

22:14 <blocktrron> i havent worked on this in years and just lost interested after i've passed packets through it :/

23:00 <Mangix> blocktrron: :). unfortunately I never got it to work with mine. Something about swapping phy probably.

23:07 <blocktrron> Mangix: fwiw, I've developed this on a Mi Router 4a

23:07 <blocktrron> QCA9561

23:07 <blocktrron> or 9563, not sure which one was the esw one

23:08 <Mangix> mine's on a prototype QCA9531 that never got sold :)

23:28 <blocktrron> not sure if I've ever tried it there

23:28 <blocktrron> from the code and datasheets the switch-ip should be identical from 9344 on

23:28 <blocktrron> hence the name