eyJhb changed the topic of #nixos-on-your-router to: NixOS on your Router || https://logs.nix.samueldr.com/nixos-on-your-router
<andi-> kiwiirc: try :) I guess nobody would complain if you brought it up
<kiwiirc> kool ty
nwspk has joined #nixos-on-your-router
teto has quit [Ping timeout: 265 seconds]
<q3k> i regularly talk about switches, so i guess we're past this point anyway :P
<kiwiirc> unfortunately i just learned linux also has a radical marxist CoC so i prolly won't switch to it
<kiwiirc> those things always end up ruining whatever they rule over
kiwiirc was banned on #nixos-on-your-router by gchristensen [*!68c88135@gateway/web/cgi-irc/kiwiirc.com/ip.]
kiwiirc has left #nixos-on-your-router [requested by gchristensen (kiwiirc)]
<mdlayher> please be mindful when making comments that state your own opinion as fact, thanks.
<mdlayher> flokli: thanks for the review, updated this again: https://github.com/NixOS/nixpkgs/pull/91372. no rush if you can't test until this weekend. you mentioned you were using QMI instead of MBIM?
<{^_^}> #91372 (by mdlayher, 18 hours ago, open): nixos/mbim-network: init
<gchristensen> that person was quite hateful, regardless of opinion / fact
<mdlayher> i need to figure out the rest of the automation story for this.
<mdlayher> gchristensen: oh are they already kicked? i have lots of notifications hidden
<gchristensen> yeah banned everywhere
<mdlayher> good to hear.
<mdlayher> huh, it does seem that whatever configuration mbim-network does is eventually removed, perhaps after some timeout. i'm using the working code from yesterday and my modem no longer accepts mbimcli commands
<mdlayher> i wonder if i need to configure an IP address immediately and start using it to keep it live
<mdlayher> part of me is tempted to write a silly "DHCP for MBIM" thing in Go but that'd mean implementing whatever parts of that protocol i need to query address information
<mdlayher> I have an idea for writing a little Go tool to consume the CLI output and apply it to an interface. I'm gonna prototype that.
<mdlayher> that's convenient
<mdlayher> it seems to require logging in to download. is this not something we could distribute?
<flokli> mdlayher: uh, I just googled from my phone
<flokli> No, that's stupid :-D
<flokli> mbimcli --help-basic-connect --query-ip-configuration seems to show that information
<flokli> I don't know why it doesn't configure the interface. or does it?
<mdlayher> flokli: looks like mbimcli just fetches the info. i built a Go program which can parse the output of 'mbimcli -d /dev/cdc-wdm0 --device-open-proxy --query-ip-configuration' and got up to configuring IP addresses on the interface.
<flokli> noooo! you need to link against libmbim, lol
<mdlayher> in my use case i'll be using some slightly unusual route configs
<flokli> just joking :-)
<mdlayher> lol, i was gonna say, i think i'd rather implement the pieces of libmbim i need myself
<flokli> uff
<flokli> maybe that's where modemmanager comes into play
<mdlayher> yeah. i honestly can't decide where to draw the line. i'm not using NM for any other interfaces and have no idea how it'd play
<flokli> You can tell NetworkManager to ignore all interfaces except the LTE one.
<flokli> But https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Simple.html reads quite nice TBH - I could imagine writing this in some bash scripts to be much more error-prone
<mdlayher> oh fun. maybe that's the play then.
<flokli> and it seems you don't need to distinguish between mbim and qmi at all anymore
<mdlayher> yeah.
<mdlayher> what's the current networking backend for networking.*? it's not systemd-networkd by default yeah?
<mdlayher> i wouldn't mind converging everything on one management system
<flokli> It's not yet the default, but I use networkd mostly everywhere
<mdlayher> i was considering going to networkd after seeing andi- 's config with DHCPv6 PD and such
<flokli> yeah
<flokli> I mean, of course it also has bugs and is missing some features
<flokli> but it's probably still better than the scripted networking
<flokli> and I'm not really motivated to put more scripts on top of them :-)
<mdlayher> yeah definitely. the more i think about it, the less i like cobbling things together that way
<flokli> my current "use internet from the neighbour by connecting to their wifi, do DHCPv6-PD" is like 2 .network files, a wpa-supplicant config
<flokli> and if I now add LTE failover, it'd be a very limited NetworkManager/ModemManager only managing that interface, and telling networkd to ignore it
<mdlayher> right.
<flokli> DHCPv6-PD via LTE properly isn't supported anyways
<mdlayher> i was curious how that would work with MBIM. it's unclear if you can just turn up other addresses in the /64 and if they'll just work
<flokli> usually, the links are really point to point links
<flokli> what you can then do is update the netmask on the lte interface to be /128, configure a fe80::x as gateway for that interface (or use a second IP+route) and put the whole /64 on the lan interface
<flokli> this of course does only work with one downstream interface
<mdlayher> yeah that's just fine. i was thinking about making a new "backup" VLAN with only a handful of devices that'd be allowed to egress via LTE anyway
<flokli> well, you could have the LTE link with a less preferred metric configured all the time
<mdlayher> yeah, the intent of the separate VLAN is to prevent devices like the PS4 from downloading 50GB updates in the event my internet is out
<flokli> heh
<mdlayher> but i would advertise it with router priority low via NDP RA
<flokli> banning the PS4 from the network would also be an option
<mdlayher> huh, so apparently i can't enable networkmanager on 20.03 due to some C compilation pkg-config shenanigans with gio-unix-2.0
<mdlayher> googling i found https://github.com/NixOS/nixpkgs/issues/36468 but no reference to networkmanager
<{^_^}> #36468 (by jtojnar, 2 years ago, open): Report undeclared gio-unix-2.0 upstream
<mdlayher> ooooooh i may have hit something weird because i have environment.noXlibs = true
<mdlayher> seems to work now that that's disabled
<andi-> the noXlibs flag is weird.. I am not sure we can really support that going forward.
<andi-> It feels like something that (almost) *every* single package has to keep in mind and implement.
<gchristensen> +1
<gchristensen> (and doesn't)
<andi-> I could envision a future version of nix where not all the build scrpts are written as bash-string-concat but instead combined from richer structure of configuration. I really like the syntax Guix has for setting e.g. environment variables for a build. It is explicitly an environment variable. They also have explict concat of options from the previous phase without needing weird
<andi-> `(old.foo or []) ++ [ bar ]` everywhere when overriding. I can't currently design such an API tho.. I just have hopes someone that is smarter than me introduces that :)