digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #openwrt-devel
Tapper has joined #openwrt-devel
torv is now known as Guest403
torv has joined #openwrt-devel
Guest403 has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
aleksander has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
indy has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
robimarko has joined #openwrt-devel
indy has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
gladiac has joined #openwrt-devel
Lynx- has joined #openwrt-devel
<Lynx->
mrkiko as you can see from the ModemManager mailing list the updated ModemManager from master indeed not informs netifd of the disconnect, but the 'ModemManager' protocol of netifd just sits there doing nothing following the interface/link having gone down. I think there should be an option in netifd 'ModemManager' that is called 'autoconnect', which would then immediately bring the interface back up. Does this make sense?
<Lynx->
*now informs
<Lynx->
this would complete the circle I think
<Lynx->
In fact aleksander just imagined that netifd would bring it back up, but from my testing it doesn't. Unless I'm missing an undocumented option in /etc/config/network, then I think this functionality still needs to be implemented.
<stintel>
there is a fi in master but it went in after some version bumps that aren't in 22.03 ... backport and fi conflict or backport all version bumps too and have clean backports?
<stintel>
grr damn laptop keyboard
indy has joined #openwrt-devel
<jow>
stintel: minor version bumps?
robimarko has joined #openwrt-devel
<Lynx->
Hey jow any chance of getting ModeManager updating in 22.03 to include aleksander's patch that updates netifd of connection loss, and is there a way to tell netifd in 'ModemManager' protocol that it should autoconnect? At the moment users seem to be all implementing their own DIY hacks to deal with this disconnect/reconnect issue for wireless wan connections, which are on the up.
<jow>
Lynx-: I have no experience in this area, no use-case and no hardware to test on. Someone else has to take the initiative
<Lynx->
Ah, sorry. Could you suggest an individual?
<Lynx->
I thought you were the netifd guy
<Lynx->
It was apparently a chat with you that led to the patch in question
<jow>
no, I just happen to be the guy that makes the mistake to answer questions :)
goliath has joined #openwrt-devel
<jow>
yeah I suggested a potential implementation. But I have no means to test or verify it
<Lynx->
I have evidence of said chat here :https://lists.freedesktop.org/archives/modemmanager-devel/2022-January/009075.html
<Lynx->
Well jow I tested it and it works
<stintel>
jow: 5.16 to 5.18
<jow>
stintel: then backport
<stintel>
jow: thanks
<jow>
stintel: 5.x -> 6.x would be bad
<jow>
also strace is a leaf package, so slightly more wiggle room for updates
<Lynx->
What I did was to install the new ModemManager from master in my 22.03 install and it worked in that now netifd sees the disconnect and the interface is brought down so ifstatus is correct. But this cool solution only shifted the problem to netifd. Now netifd is the problem, because it doesn't actually do anything.
<Lynx->
My guess is that netifd 'ModeManager' protocol should have an 'autoconnect' option to bring interface back up when it goes down
<jow>
does it state "Interface xxx has lost connection" ?
<stintel>
jow: makes sense, I'll just bring in sync with master then
<Lynx->
aleksander0m who authored the patch writes: "Unless I'm missing something, the reconnection would be done if the wwan configuration in /etc/config/network is set to automatically connect."
<Lynx->
but there is no such 'autoconnect' line
<Lynx->
or option
<jow>
well telling to netifd to shutdown an interface means it should shutdown it
<jow>
not shutdown and immediately bring back on
<jow>
otherwise we>'d eventually need a "really sutdown" event
<jow>
so wahtever instructs netifd to down an interface should also instruct it to bring it back on
<Lynx->
with ModemManager now supporting these dispatcher scripts would it just be a case of adding a new such script
<jow>
yes, I suppose you'd need to add a complementary 11-report-up script
<Lynx->
so I admit I'm confused
<Lynx->
I mean if I manually type ifup ... doesn't that mean netifd asks ModemManager to bring it back up
<Lynx->
which suggests to me netifd has the capability
<jow>
sure it has
<Lynx->
Isn't the connection sequence that netifd instructs ModemManager to bring it up, ModemManager connects, then passes netifd the connection specifics
<Lynx->
so logically if conneciton went down, shouldn't netifd then instruct ModemManager to bring it back up again
<jow>
and then mm eventually states to netifd "ok, interface is down now"
CN_SZTL has joined #openwrt-devel
<jow>
and does nothing anymore
CN_SZTL_ has joined #openwrt-devel
<jow>
so why should netifd bring it back up? it has been instructed by mm that the interface is down/gone now
<Lynx->
it's like I switch my computer on, and it then tell me it shut itself down but I really want it on all the time, then shouldn't I switch it back on
<jow>
no it's like typing "shutdown" and expecting it to immediately power back on
<Lynx->
because in netifd I tell it I want a connection with APN settings etc
<jow>
if you want to reboot it, then instruct it to reboot
<jow>
not to shut down
<Lynx->
in /etc/config/network when I put APN settings in I want a connection
<jow>
yeah sure
<Lynx->
I don't say I want a connection until disconnect
<jow>
then fix the mm integration
<jow>
because right now it says: "netifd, please mark the interface down and keep it this way"
CN_SZTL_ has quit []
<jow>
it does the user equivalent of "ifdown wwan"
<jow>
why should an "ifdown wwan" immediately invoke "ifup wwan"
<jow>
that wouldn't make sense at all
<Lynx->
autoconnect = 1
<jow>
so you say an "ifdown foo" on an interface setting "option autoconnect 1" should immediately invoke "ifup foo" ?
Bhuvanesh has left #openwrt-devel [#openwrt-devel]
<Lynx->
I don't like that solution because it uses polling
<Lynx->
but it's another attempt to fix this issue
<Lynx->
but the author of these patches also imagines netifd handling the reconnect
<Lynx->
(for ths QMI protocol)
<jow>
maybe. problem is that neither mm nor uqmi really fit into netifd's expected process model
<jow>
what netifd really needs is:
<jow>
a process it starts in order to create/configure/keep running a network device
<jow>
when the process dies, the network device dies along with it
<jow>
this holds true for pppd, openvpn and various other tunnel protocols
<jow>
there's also protocols using one-shot commands (ip link ... or ip tunnel ...) to set things up
bluew has quit [Ping timeout: 480 seconds]
<jow>
but those will usually not be reconnect-able, not link state aware
<jow>
it's basically fire and forget setups
<Lynx->
What I keep coming back to in my mind though is that in /etc/config/network I enter APN settings to tell netifd to bring connection up. I want it to keep it up! So if netifd knows it has gone down, then it seems to make sense to have it bring it up rather than do nothing.
<jow>
so what would be needed in the mm and uqmi case is a monitor process per interface
<jow>
this process needs to end on disconnect
<Lynx->
wwan is really a special case isn't it since disconnections occur regardless of the ISP
<jow>
when netifd notices the process termination, it will restart the process which in turn restarts the interface
<Lynx->
in my case Vodafone UK forcible disconnect at exactly 48 hours, and they are super generous. Other ISPs work with e.g. 6 hours
<jow>
(unless the process termination was due to a logical interface shutdown, ifdown foo, in this case it is stopped, the netdev remainders deconfigured if needed and kept down)
<jow>
if MM would work in a way that it brings up the wwan0 and exits if wwan0 disconnects due to a network event, then things would be way smoother
<jow>
but MM wants to be a long-running supervision process itself that outlives disconnecting device
<jow>
s
<Lynx->
why would the self-termination help?
<jow>
because then it could be changed from independently running to spawned-by-netifd
<jow>
and the auto-reconnect logic would just work
<Lynx->
ahh
<Lynx->
you know what I don't like modemmanager anyway it's super bloated
<Lynx->
it would be nicer to have qmi protocol handle this situation
<jow>
but iirc MM's operating model does not really allow for that as it could theoretically manage multiple devices
<jow>
and you'd need to spawn one MM instance per device
<jow>
I could imagine a theoretical "uqmi monitor" subcommand
<Lynx->
so what should happen is netifd creates its own monitoring process to wait for event from modem, and then on event from modem it reacts accordingly
<jow>
it will start a daemon process that subscribes to events from thje given device
<Lynx->
nobody likes ModemManager since it uses dbus and all these extra packages and it's really a big elephant
<jow>
and if it catches a disconnection event, it will exit(0) itself
<jow>
this "uqmi montor" daemon process could then be launched by netifd
<Lynx->
uqmi on its own works with netifd 'qmi' protocol, but for this disconnect/reconnect isue
<Lynx->
ah yes
<Lynx->
do you know if uqmi can work with proxy
<jow>
no idea
<Lynx->
since a problem is if deaemon monitors the modem then it may block commands
<Lynx->
as bmork wrote: "Polling is bad. Constantly closing and reopening the /dev/cdc-wdmX device because we start a new uqmi process for every poll session makes it even worse. Lots of work for both driver and modem firmware for absolutely no reason at all."
<Lynx->
also one wants immediate reconnect
<Lynx->
in my Huawei B81-263 it reconnected within a second
<jow>
then the only way forward is a monitor process
<Lynx->
indeed
<Lynx->
arg is there someone who would write this for money?
aiyion_ has quit [Ping timeout: 480 seconds]
<jow>
I mean uqmi oneshot commands could be redesigned in a way that they firs try to communicate through the monitor process if one is found active for the device it is attmepting to talk to
<jow>
and falling back to the old way of doing things
<jow>
as a stop-gap solution I suggest developing an mm-connect script
<jow>
to complement the disconnect one
<Lynx->
made sense to me and I could write that myself probably
<Lynx->
but I wouldn't know how to get ModemManager to auto reconnect
<schmars[m]>
i'm building package feeds using the sdk. are all targets' sdks basically the same, given the same underlying architecture? example: for the arm_cortex-a7_neon-vfpv4 feed, i can use the sdk of bcm27xx/bcm2709, ipq40xx/generic, and a few others
<jow>
then invoke one of the modemmanager_connected_method_*() methods on connection events
<Lynx->
could you or someone here by convinced to patch modemmanager in this way
<jow>
no need to patch MM
<Lynx->
the dispatcher scripts are enough?
<jow>
yes
<Lynx->
so at the end of the report down script there is a reconnect call, and there is a further report up script
<jow>
I think they should be independent
<Lynx->
report down, reconnect, report up scripts
<jow>
I would assume MM tries to reconnect, then invokes a connection.d script with STATE=connected
<Lynx->
sadly I don't think it does
<Lynx->
it just remains in state 'registered' but not 'connected'
<Lynx->
so then I think there is needed report up script and also patch to ModeManager to reconnect
<Lynx->
or if reconnect process can be called then reconnect script to catch disconnect and call the reconnect function
<Lynx->
if you think the latter might be possible
<jow>
why is patching needed for modemmanager? I thought it's entire purpose is keeping devices alive and dealing with network side disconnections
<Lynx->
I thought so too, but following event: "Mon Oct 31 17:37:46 2022 daemon.info [2719]: <info> [modem0/bearer1] verbose call end reason (6,36): [3gpp] regular-deactivation" it just remains in state 'connected'
<Lynx->
sorry in state 'registered'
<jow>
why is it even needed then?
<jow>
For harware support I presume
<Lynx->
yes I'd like to dispense with it it seems junk
<Lynx->
but at least it informs netifd that disconnection happened whereas with qmi netifd doesn't even know and ifstatus is wrong following disconnect
<Lynx->
it seems the way forward might be qmi protocol fix along the lines of the above like you suggested, but how to make this happen
<Lynx->
do you think someone would code it up for a few hundred euros or dollars
<Lynx->
jow seems like aleksander0m is the ModemManager developer,could you be convinced to respond to his post here: https://forum.openwrt.org/t/calling-on-all-4g-qmi-experts-wan-ip-refresh-issue/140893/18?u=lynx and correct this misunderstanding: "Unless I'm missing something, the reconnection would be done if the wwan configuration in /etc/config/network is set to automatically connect." since clearly the problem is the ModemManager dev expects netifd to
<Lynx->
reconnect but it seems this logic is wrong and ModemManager should rather reconnect?
<Lynx->
maybe that would move help move the needle
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Lynx- has quit [Remote host closed the connection]
Lynx- has joined #openwrt-devel
<Lynx->
jow just another question, the modem itself has an autoconnect feature and so I wonder if there is a way in OpenWrt to set up an LTE-ETHERNET IP passthrough / bridge mode?
hexa- has quit [Quit: WeeChat 3.5]
hexa- has joined #openwrt-devel
floof58 has quit [Quit: floof58]
floof58 has joined #openwrt-devel
<aleksander>
oh wow, I missed a long discussion
<aleksander>
MM doesn't automatically reconnect, MM does not have any logic for that, it's not a connection manager
<aleksander>
MM only acts on what the upper layer connection manager requests to do, be it connect or disconnect
<aleksander>
MM will monitor network initiated disconnections, and report the disconnection to the upper layers so that they decide what to do
<aleksander>
jow, not sure if I understood it correctly, but are you suggesting triggering the reconnection from within the MM dispatcher script when it reports a disconnection? that's a bit convoluted
<jow>
aleksander: problem is that netifd regards mm to be the connection manager as it is not supervised by netifd
<aleksander>
"nobody likes ModemManager since it uses dbus and all these extra packages and it's really a big elephant" MM was never targeting devices with estremely low amount of memory, but a lot of openwrt devices have tonds of memory available and MM is not such a big elephant there
<aleksander>
jow, there's no connection management done by MM itself though, it's all done at netifd and protocol handler level
<jow>
aleksander: I don't want to repeat all the discussion again
<jow>
but in essence, netifd only does reconnections for supervised proto handler processes
<aleksander>
jow, the dispatcher script called by MM on disconnect (.e.g when a network initiated disconnect happens) was supposed to notify netifd that the "underlying" connection is down, so that netifd can report the iface as down
<aleksander>
ah, wrongly assumed that then
<aleksander>
what needs to happen to have it a supervised proto handler process? is that something that can be developed in the proto handler implementation itself?
<jow>
maybe you can get away with a simple brute force approach of simply calling ubus call network.interface down '{ "interface": "$CFG" }' && sleep 1 && ubus call network.interface up '{ "interface": "$CFG" }'
<jow>
in that disconnect notify script
<jow>
aleksander: basically you need some sort of process that exits when the underlying device loses connection
<aleksander>
doing that breaks the purpose of the disconnect notify script though
<jow>
aleksander: netifd will then kill the netdev, restart that process and await proto updates
<aleksander>
we could have a watcher process launched on a connect, and have that process killed by the disconnect dispatcher script
<jow>
yep
<jow>
netifd will restart the watcher process
<aleksander>
that's doable and clean, because the watcher process would be launched within the protocol handler
<jow>
but it is also assumed that this "watcher process" is also the "setup process"
<aleksander>
that's fine
<jow>
so the watcher would also need to do all the necessary things to initiate a connection, fetch details, trigger a proto update notify
danitool has quit [Remote host closed the connection]
<aleksander>
yes, yes, that's doable I think
<jow>
you will also only need this watcher process for non-ppp connection types
<jow>
for ppp, the proto handler already does proto_run_command /usr/sbin/pppd ...
<hgl>
jow, would you be able to merge this? PR in openwrt/packages is already merged, hope uhttpd change could be in the same openwrt release: https://github.com/openwrt/openwrt/pull/11076
<SherlockDomes>
Hi all, I'm trying to understand how netifd wireless subsystem works so I'm walking through an example. I understand that wifi command essentially executes ubus call network.wireless up $dev. And that runs the script in /lib/netifd/wireless/$wirelessdriver.sh with configuration parameters. I'm studying the script, and I'm worndering what is the purpose of wireless_set_up which executes ubus call network.wireless
<SherlockDomes>
notify? Is the notify to explain setup is compelete is there anything else? Looking at netifd code it looks like it can track processes, I'm guessing something like hostapd
<SherlockDomes>
Sorry ignore that, I didn't realise there are multiple different commands to notify. Now I realise that set_up uses the "up" command which makes more sense. I'll proceed studying the code
Lynx- has quit [Quit: Going offline, see ya! (www.adiirc.com)]
gladiac has quit [Quit: k thx bye]
goliath has quit [Quit: SIGSEGV]
dansan has joined #openwrt-devel
<Mangix>
Ansuel: big brain idea: use a cfarm machine and run irssi or quassel on that.
<slh>
I haven't really followed the market, but a while ago there have been low-end (usually IPv6-only) vservers around for really cheap (as in less than a dollar per month), plenty for screen+irssi
<Lechu>
I recall mikr.us project, but not sure if they're still around
srslypascal is now known as Guest446
srslypascal has joined #openwrt-devel
Guest446 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
Borromini has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
floof58 has joined #openwrt-devel
Borromini has quit [Ping timeout: 480 seconds]
floof58 has quit [Remote host closed the connection]
<Ansuel>
softirq: huh, entered softirq 7 SCHED (ptrval) with preempt_count 00000100, exited with c1c5217c?
<Ansuel>
a so rare error even the kernel jokes about it as it's so wrong AHAHAH (me having fun with krait ant cache)
<slh>
:(
<Ansuel>
it's interesting tho.... the fact that if i hammer the cache mux results always in cache corruption
<Ansuel>
it's a good case to try to fix it
<Ansuel>
i mean this is the real problem of ipq806x...
<slh>
yeah. weird thing (perhaps not really), it mostly happens while no one is really using internet, so the router being mostly idle, with just some background traffic happening
<Ansuel>
and that is probably when the router scale the clk a lot
<slh>
probably, yes
<robimarko>
Hm, it could be a HW errata that if those muxes are configured often they may get corrupted or noisy
<robimarko>
There may be some required time between changes to settle
<Ansuel>
robimarko well a way to test that is to hammer cache to the hell and check when it brok and increment delay
<Ansuel>
an overkill idea would be have something tha validate data in the cache while scaling