eyJhb changed the topic of #nixos-on-your-router to: NixOS on your Router || https://logs.nix.samueldr.com/nixos-on-your-router
rb2k has joined #nixos-on-your-router
rb2k has quit [Ping timeout: 264 seconds]
LilleCarl has quit [Ping timeout: 256 seconds]
rb2k has joined #nixos-on-your-router
disasm has quit [Quit: WeeChat 2.0]
disasm has joined #nixos-on-your-router
rb2k has quit [Ping timeout: 264 seconds]
LilleCarl has joined #nixos-on-your-router
<sphalerite> gchristensen: what I've been doing for that is creating a nixos-forward chain by running iptables -F nixos-forward || iptables -N nixos-forward
<sphalerite> (and likewise for IPv6)
<sphalerite> ferm or nftables is probably a better solution though
<sphalerite> oh, and attempting to clear and delete it in firewall.extraStopCommands
teto has joined #nixos-on-your-router
<andi-> At some point we should really replace that scripted firewall stuff or at least promote ferm / nftables more. Nftables has the already discussed issues with testing the syntax of the file without being root (and before deployment)...
<flokli> andi-: I'd like to see https://github.com/NixOS/nixpkgs/pull/81172 getting merged, which should move more stuff to ferm
<{^_^}> #81172 (by misuzu, 50 weeks ago, open): iptables: switch from iptables-legacy to iptables-nftables-compat
<flokli> but I'm a bit worried about the IPForward= stuff
<flokli> if someone wants to add this to a VM test ;-)
<hexa-> i'm more worried about the side effects of networkd NAT with nftables/ferm
rb2k has joined #nixos-on-your-router
<flokli> hexa-: can you elaborate?
<hexa-> flokli: if networkd injects firewall rules, what's to keep ferm from pruning them on reload?
rb2k has quit [Ping timeout: 240 seconds]
<hexa-> maybe I'm missing some crucial info on how networkd handles this :)
<flokli> how do other distros handle that?
<hexa-> they don't
<flokli> heh
<hexa-> I'll remind you of ferm/docker
<hexa-> also a great combination of sadness
<andi-> just run ufw :P
rb2k has joined #nixos-on-your-router
<hexa-> andi--
<NinjaTrappeur> I use a combination of networkd and nftables.
<NinjaTrappeur> It works resonably well as long as you stay far far far away from the IPMasquerade directive :P
<hexa-> obviously :P
<NinjaTrappeur> :)
<NinjaTrappeur> I like the declarative part of networkd.
<NinjaTrappeur> But I really dislike the fact it's trying to do everything. I'd prefer its scope to be constrained to create/configure the netdev and setting the static routes & routing policies.
<hexa-> agreed
rb2k has quit [Ping timeout: 246 seconds]
rb2k has joined #nixos-on-your-router
<andi-> Wasn't there an nftables PR to networkd lately?
rb2k has quit [Read error: Connection reset by peer]
rb2k has joined #nixos-on-your-router
rcorrear has quit [Quit: Idle for 30+ days]
rb2k has quit [Ping timeout: 246 seconds]
rb2k has joined #nixos-on-your-router
rb2k has quit [Ping timeout: 264 seconds]
rb2k has joined #nixos-on-your-router
cwslimy[m] has joined #nixos-on-your-router
rb2k has quit [Ping timeout: 240 seconds]
rb2k has joined #nixos-on-your-router
rb2k has quit [Ping timeout: 260 seconds]
<gchristensen> sometimes if I try to talk to an IP and the machine is down, my router remembers for a long time that the machine is dead, until I manually arping the IP. what is going on here?
rb2k has joined #nixos-on-your-router
<hexa-> that sounds odd, there is no negative arp cache :D
rb2k has quit [Ping timeout: 264 seconds]
<gchristensen> :)
<hexa-> is it wifi? :D
<gchristensen> no, from the router to the machine is over ethernet, and there is a switch between
<hexa-> a dumb switch?
<gchristensen> netgear unmanaged gs108
<hexa-> have you checked with tcpdump for arp requests before you arping?
<hexa-> maybe there is something to glean from the previous arp requests and the ones arping sends
<gchristensen> no, usually when I find out it has happened hydra is down or nearly down
<cransom> is it crossing a subnet?
<gchristensen> lol
<hexa-> uh, they said router, so I kinda expect routing
<gchristensen> cransom: when this is happening, yeah, I can't go from my laptop to the machine which crosses a subnet, and the router itself can't ping the device
<cransom> hexa-: just making sure.
<hexa-> cransom: no worries :)
<hexa-> so, is the subnet mask correct?
<hexa-> does the device have static addressing or dhcp?
<gchristensen> dhcp
<hexa-> is this limited to a single machine on a single subnet?
<hexa-> are other machines on the same subnet experiencing the same issue?
<hexa-> are other machines on other subnets experiencing the same issue?
<gchristensen> I've seen it happen on other subnets with other machines
<hexa-> what is the network setup on the router?
<hexa-> link aggregation? bridges? vlans? etc
<gchristensen> a bunch of vlans, no bridges or link aggregations
<hexa-> with an unmanaged switch?
<gchristensen> though the machine/switch most recently having this problem is not on a vlan
<hexa-> so basically what happens, please correct me is the following
<hexa-> setup is: A -> R -> B
<hexa-> and you try ping B from A
<hexa-> that doesn't work
<hexa-> then you ssh into R
<hexa-> and do arping B
<hexa-> and that works?
<gchristensen> yep
<gchristensen> however before I arping, I try to ping B from R and it doesn't work
<hexa-> or anything more fancy … like arping -i interface B
<gchristensen> just `arping 10.5.3.16`
<hexa-> make sure it picks the correct interface when things don't work
<hexa-> ip route get 10.5.3.16
<cransom> is B the only machine on that subnet? besides router, of course
<gchristensen> no, but close
<hexa-> anything odd in the dhcpd logs?
<gchristensen> not that I noticed though this it was a few days ago it stopped working
<hexa-> are you certain that arpinging it fixes it immediately?
<hexa-> like it instantly responds to the first arp request made by arping?
<gchristensen> I happened to luckily have it in scrollback
<hexa-> no timeout on arping
<hexa-> do you notice that the unicast reply originates from two different mac addresses?
<hexa-> Unicast reply from 10.5.3.16 [70:85:C2:FD:E3:32] 0.827ms
<hexa-> Unicast reply from 10.5.3.16 [70:85:C2:FD:CB:DD] 0.951ms
<gchristensen> oh boy
<gchristensen> that is almost certainly the NIC which is shared with the bmc if the other port isn't plugged in
<hexa-> does that do dhcp as well? :D
<gchristensen> yeah but I assign the IP based on MAC
<hexa-> good
<hexa-> only they both think they own that ip
<hexa-> you are advised to put the bmc functionality onto a vlan on a shared port :p
<gchristensen> can do =)
<gchristensen> thanks
<hexa-> yw
* gchristensen should not be trusted with a network
<hexa-> noted
<gchristensen> as if it wasn't obvious
<hexa-> its easy to miss
<hexa-> though I'm very interested how they both ended up thinking they have that IP address
<hexa-> check those dhcpd logs really careful
<hexa-> check the lease file to see what it thinks
rb2k has joined #nixos-on-your-router
rb2k_ has joined #nixos-on-your-router
rb2k has quit [Read error: Connection reset by peer]
rb2k_ has quit [Ping timeout: 264 seconds]
rb2k has joined #nixos-on-your-router
rb2k has quit [Read error: Connection reset by peer]
rb2k has joined #nixos-on-your-router
teto has quit [Quit: WeeChat 3.0.1]