error running xcurl

[jwetzell]

built using go build ./examples/xcurl and ran as follows.

~/Projects/lneto (main) » sudo ./xcurl -i ens18 -host jwetzell.com
[sudo] password for jwetzell: 
softrand 1777056631
NIC hardware address: bc:24:11:c5:c7:85 bridgeHW: bc:24:11:c5:c7:85 mtu: 1500 addr: 10.0.0.87/24
OUT 334 [Ethernet len=14; destination=ff:ff:ff:ff:ff:ff; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=255.255.255.255 | UDP len=8; (Source port)=68; (Destination port)=67 | DHCPv4 len=240; op=1; Flags=0x0000; (Client Address)=us; (Offered Address)=us; (Server Next Address)=255.255.255.255; (Relay Agent Address)=us; (Client Hardware Address)=us]
IN  342 [Ethernet len=14; destination=us; source=f4:1e:57:c1:6a:34 | IPv4 len=20; (Type of Service)=0x00; flags=0x0000; source=10.0.0.1; destination=10.0.0.87 | UDP len=8; (Source port)=67; (Destination port)=68 | DHCPv4 len=240; op=2; Flags=0x0000; (Client Address)=us; (Offered Address)=10.0.0.87; (Server Next Address)=10.0.0.1; (Relay Agent Address)=us; (Client Hardware Address)=us]
OUT 326 [Ethernet len=14; destination=ff:ff:ff:ff:ff:ff; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=255.255.255.255 | UDP len=8; (Source port)=68; (Destination port)=67 | DHCPv4 len=240; op=1; Flags=0x0000; (Client Address)=us; (Offered Address)=10.0.0.87; (Server Next Address)=10.0.0.1; (Relay Agent Address)=us; (Client Hardware Address)=us]
IN  342 [Ethernet len=14; destination=us; source=f4:1e:57:c1:6a:34 | IPv4 len=20; (Type of Service)=0x00; flags=0x0000; source=10.0.0.1; destination=10.0.0.87 | UDP len=8; (Source port)=67; (Destination port)=68 | DHCPv4 len=240; op=2; Flags=0x0000; (Client Address)=us; (Offered Address)=10.0.0.87; (Server Next Address)=10.0.0.1; (Relay Agent Address)=us; (Client Hardware Address)=us]
[13ms] DHCP request completed
2026/04/24 13:50:31 INFO dhcp-complete assignedIP=10.0.0.87 routerIP=10.0.0.1 DNS=[10.0.0.10] subnet=10.0.0.0/24
OUT  60 [Ethernet len=14; destination=ff:ff:ff:ff:ff:ff; source=us | ARP len=28; op=1; (Sender hardware address)=us; (Sender protocol address)=us; (Target hardware address)=00:00:00:00:00:00; (Target protocol address)=10.0.0.1]
IN   60 [Ethernet len=14; destination=us; source=f4:1e:57:c1:6a:34 | ARP len=28; op=2; (Sender hardware address)=f4:1e:57:c1:6a:34; (Sender protocol address)=10.0.0.1; (Target hardware address)=us; (Target protocol address)=us]
[6ms] Router ARP resolution
OUT  83 [Ethernet len=14; destination=f4:1e:57:c1:6a:34; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=10.0.0.10 | UDP len=8; (Source port)=17125; (Destination port)=53 | DNS len=41]
IN   99 [Ethernet len=14; destination=us; source=bc:24:11:d5:7d:27 | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=10.0.0.10; destination=us | UDP len=8; (Source port)=53; (Destination port)=17125 | DNS len=57]
[73ms] resolve jwetzell.com
DNS resolution of "jwetzell.com" complete and resolved to [107.161.23.150]
[7µs] create HTTP GET request
OUT  60 [Ethernet len=14; destination=f4:1e:57:c1:6a:34; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=107.161.23.150 | TCP len=24; (Source port)=44919; (Destination port)=80; flags=SYN]
IN   60 [Ethernet len=14; destination=us; source=f4:1e:57:c1:6a:34 | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=107.161.23.150; destination=us | TCP len=24; (Source port)=80; (Destination port)=44919; flags=SYN,ACK]
OUT  60 [Ethernet len=14; destination=f4:1e:57:c1:6a:34; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=107.161.23.150 | TCP len=20; (Source port)=44919; (Destination port)=80; flags=ACK]
[63ms] TCP dial (handshake)
OUT 163 [Ethernet len=14; destination=f4:1e:57:c1:6a:34; source=us | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=us; destination=107.161.23.150 | TCP len=20; (Source port)=44919; (Destination port)=80; flags=PSH,ACK | HTTP len=109]
[2ms] send HTTP request
IN   60 [Ethernet len=14; destination=us; source=f4:1e:57:c1:6a:34 | IPv4 len=20; (Type of Service)=0x00; flags=0x4000; source=107.161.23.150; destination=us | TCP len=20; (Source port)=80; (Destination port)=44919; flags=RST]
use of closed network connection

[soypat]

So I added logging to better debug and according to claude the info below details the issue and how to fix it. Did not apply the fix since it required os/exec calls which seemed out of place. I'd like to try to find a way to solve this using syscalls or doing a DHCP from the httptap. Will take a look in a few days

Details

Plan: Fix xcurl DNS failure via httptap

Context

go run ./examples/xcurl -ihttp -host google.com fails with "DNS retries exceeded". The new debug logs confirm the root cause:

WARN gateway-rewrite-miss dstIP=134744072   (= 8.8.8.8)
WARN ethernet-self-loop   dstIP=134744072

rewriteEthernetDst in examples/httptap/dhcp.go receives a DNS frame destined for 8.8.8.8 with Ethernet dst = svMAC (the fake gateway). It tries arpCacheLookup(8.8.8.8) → miss (8.8.8.8 is never ARPed on LAN) → frame forwarded unchanged → self-loop → dropped by host kernel.

HTTP connections to google.com would fail the same way after DNS is fixed.

Two-part fix (single file: examples/httptap/dhcp.go)

Part 1 — Discover and advertise the real gateway IP as the DNS server

Currently newDHCPInterceptor hard-codes DNS: [4]byte{8, 8, 8, 8}.

Instead, advertise the real local gateway IP (e.g. 192.168.1.1) as the DNS server. The home router is its own resolver. This means:

• xcurl ARPs for 192.168.1.1 directly (it's in the same /24 subnet)
• isARPRequestForUs returns false (target ≠ svIP) → ARP passes through to the real wire
• Real router replies → snoopARP stores 192.168.1.1 → e8:4d:74:9f:61:4a in the cache
• xcurl's DNS frame has dst_mac = real router MAC → rewriteEthernetDst skips it (dst_mac ≠ svMAC) → DNS reaches the real resolver ✓

Part 2 — Fallback to real gateway MAC for non-local destinations

For HTTP and all other non-LAN traffic xcurl still routes via the fake gateway (svIP), so rewriteEthernetDst is still invoked. Add a subnet-aware fallback:

1. If dstIP is in the local subnet → existing direct ARP lookup (unchanged)
2. If dstIP is outside the subnet → look up gwIP in the ARP cache instead

By the time HTTP starts, Part 1's DNS ARP exchange has already seeded gwIP → real MAC into the cache via snoopARP. No timing issue.

Implementation

All changes are in examples/httptap/dhcp.go only.

1. New helper: getDefaultGateway() (netip.Addr, error)

func getDefaultGateway() (netip.Addr, error) {
    out, err := exec.Command("ip", "route", "show", "default").Output()
    // parse "default via <IP> ..."
    // return the IP, or error if not found
}

Import os/exec and strings.

2. dhcpInterceptor struct — add two fields

gwIP   [4]byte
subnet netip.Prefix

3. newDHCPInterceptor — store gateway + advertise it as DNS

gw, err := getDefaultGateway()
// log warning and keep 8.8.8.8 if discovery fails (graceful fallback)
d.gwIP = gw.As4()
d.subnet = subnet

// In ServerConfig:
DNS: d.gwIP,   // was hard-coded {8,8,8,8}

4. rewriteEthernetDst — subnet check + gateway fallback

dstIP := *(*[4]byte)(b[sizeEthernet+16 : sizeEthernet+20])
d.mu.Lock()
mac, ok := d.arpCacheLookup(dstIP)
if !ok && !d.subnet.Contains(netip.AddrFrom4(dstIP)) {
    mac, ok = d.arpCacheLookup(d.gwIP)
}
d.mu.Unlock()
if ok {
    copy(b[0:6], mac[:])
} else {
    internal.LogAttrs(slog.Default(), slog.LevelWarn, "gateway-rewrite-miss", ...)
}

Critical files

• examples/httptap/dhcp.go — all changes here
• examples/httptap/main.go — no changes needed

Verification

1. Run go run ./examples/httptap -i enp7s0 (or your bridge interface)
2. In another terminal: go run ./examples/xcurl -ihttp -host google.com
3. Expected: no gateway-rewrite-miss warning, DNS resolves, HTTP succeeds
4. Check httptap log: DNS frame should show destination=e8:4d:74:9f:61:4a (real router MAC), not the self-loop MAC
5. Also verify with tap interface: go run ./examples/httptap -i tap0 + xcurl

[jwetzell]

This isn't using httptap, although I do remember seeing some DNS issues with httptap

[soypat]

Is this still happening?

[jwetzell]

@soypat yes same error with the same command as in the first comment.

[jwetzell]

I'll add that this is on a fairly plain install of Ubuntu 24.04 Desktop

[MDr164]

I can actually reproduce it on my system as well an will also take a look

EDIT: I narrowed it down to Linux being overly smart and interfering with the tool. I suppose the proper fix might not be in lneto but rather making Linux not jump in. I'll continue testing.

EDIT2:
I added a bunch of debug logging to lneto and found the problem to be Linux sending its own outbound RST seq number. Here's roughly what happens on my Linux box:

1. server sends SYN-ACK to my-local-ip:2300
2. Linux kernel owns my-local-ip, has no socket for :2300
3. Linux sends an outbound RST with seq=1606374388 (in my case)
4. server closes
5. lneto sends HTTP anyway
6. server replies RST with seq=790280038

So @soypat mitigation 1 would be to use iptables/nftables/etc to drop outbound RSTs on the port lneto uses or mitigation 2 make an exception when running under an OS to be fine when the connection is already closed. I like neither tbh :D

[MDr164]

This works reliably without any code changes to lneto (ok I added a flag to set the port to not guess it when running xcurl), feel free to try:

iptables -I OUTPUT -p tcp --sport 2300 --tcp-flags RST RST -j DROP
./examples/xcurl/xcurl -i YOUR-INTF -port 2300 -host jwetzell.com
iptables -D OUTPUT -p tcp --sport 2300 --tcp-flags RST RST -j DROP