{"id":2643,"date":"2026-04-06T17:51:46","date_gmt":"2026-04-06T21:51:46","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=2643"},"modified":"2026-04-06T17:51:46","modified_gmt":"2026-04-06T21:51:46","slug":"update-nixos-docker-macvlan","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2026\/update-nixos-docker-macvlan\/","title":{"rendered":"Update: NixOS + Docker + MacVLAN"},"content":{"rendered":"

\"\"<\/a><\/p>\n

This is an updated version of my previous article NixOS + Docker with MacVLAN (IPv4)<\/a> – which addresses ARP Flux which causing networking problems. Skip to the bottom summary<\/strong> if you want to just read the conclusion.<\/p>\n

Ever since, but very intermittently, my new server build out<\/a> – I had been having issues with my macbook (OSX<\/a>) randomly losing connection to the server, but only for a brief time. I noticed mostly when using mosh<\/a> and it would indicate that I’d lost connection, but self hosted web UIs like Grafana<\/a> also gave me problems.<\/p>\n

Ping<\/a> would also fail, but then it would start to work after a minute or so. What was weird is that while I could not ping my new server (192.168.1.79) I could have a stable mosh connection to another box (192.168.1.140), which could see the new server (192.168.1.79) just fine. This made it seem very much like it was something wrong with OSX. I was guilty of mostly ignoring this because it did impact me, but not frequently — it was still very annoying.<\/p>\n

This is also an exploration of using Google Gemini<\/a>, which you can use from an incognito tab with no login required. It didn’t immediately get me to the right answer, but we eventually got there.<\/p>\n

The first iteration didn’t really get me very far, only a suggestion to check the route<\/a> on my OSX machine when the problem was happening. This meant I had to wait around for it to break – and catch it in the act.<\/p>\n

% route -n get myserver.lan\r\n   route to: 192.168.1.79\r\ndestination: 192.168.1.79\r\n  interface: en0\r\n      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>\r\n recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire\r\n       0         0         0         0         0         0      1500      1167<\/pre>\n
Unfortunately the output from this didn’t change with broken networking vs. working. At this point I added the detail that this networking problem seemed to happen most often after waking the OSX machine from sleep. Gemini was then able to reason:<\/p>\n
In your route output, the flag LLINFO stands for Link Layer Information. This means macOS has a cached MAC address for 192.168.1.79.<\/p>\n
When a Mac sleeps, it often hands off its networking responsibilities to a “Sleep Proxy” (like an Apple TV or HomePod) or simply drops its ARP table. When it wakes up, it might be trying to use a stale hardware address, or the Linux machine (myserver.lan) might not be responding to the Mac’s “Who has 192.168.1.79?” request fast enough.<\/p><\/blockquote>\n
The next suggestion was to check the arp<\/a> information when networking was broken.<\/p>\n
arp -a | grep 192.168.1.79\r\n<\/pre>\n
\n