[GH-ISSUE #201] Newt 1.7.0 seg faults on bad wireguard address #2046

Closed
opened 2026-05-03 05:44:23 -05:00 by GiteaMirror · 2 comments
Owner

Originally created by @sickmitch on GitHub (Dec 15, 2025).
Original GitHub issue: https://github.com/fosrl/newt/issues/201

Describe the Bug

After updating the whole stack to be compatible to pangolin 1.13.1 my newt istance can't stay up anymore. At first glance all connects fine but after half a second the program panic and restart the container, over and over.
Both pangolin and gerbil successfully add and connect to the newt istance for a moment, with normal logs.
Seems like the problem is in the PANGOLIN_ENDPOINT variable, tried to change to various syntax but the only reaching gerbil is like from the docs PANGOLIN_ENDPOINT=https://app.pangolin.xx, changing the value changes the error in the newt container logs but without reaching out.
Looked at #176 but segmentation violation codes looks different so I guess is another prob.

INFO: 2025/12/15 07:55:56 Starting metrics server on 127.0.0.1:2112
INFO: 2025/12/15 07:55:56 Newt version 1.7.0
INFO: 2025/12/15 07:55:56 Setting up clients with netstack2...
INFO: 2025/12/15 07:55:56 Created shared UDP socket on port 63093 (refcount: 2)
INFO: 2025/12/15 07:55:56 Server version: 1.13.1
INFO: 2025/12/15 07:55:56 Websocket connected
INFO: 2025/12/15 07:55:56 Requesting WireGuard configuration from remote server
INFO: 2025/12/15 07:55:57 Connecting to endpoint: pangolin.mydom.xx
INFO: 2025/12/15 07:55:57 Starting UDP hole punch to 1 exit nodes with shared bind
INFO: 2025/12/15 07:55:57 Starting hole punch to XX.XX.XX.XX with public key: pubKey
INFO: 2025/12/15 07:55:57 Resolved exit node: XX.XX.XX.XX -> XX.XX.XX.XX:21820
INFO: 2025/12/15 07:55:57 Tunnel connection to server established successfully!
INFO: 2025/12/15 07:55:57 Started direct UDP relay on XX.XX.XX.XX:63093 (bidirectional via SharedBind)
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:8096
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:22300
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5880
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:8004
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5001
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:3075
INFO: 2025/12/15 07:55:57 Direct UDP relay started (bidirectional through SharedBind)
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:3000
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:4588
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5232
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:2283
INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:9200
INFO: 2025/12/15 07:55:58 Received WireGuard clients configuration from remote server
ERROR: 2025/12/15 07:55:58 Failed to ensure WireGuard interface: invalid IP address format:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x260 pc=0x632b2c]

goroutine 99 [running]:
sync/atomic.(*Int32).Add(...)
	/usr/local/go/src/sync/atomic/type.go:94
sync.(*RWMutex).RLock(...)
	/usr/local/go/src/sync/rwmutex.go:72
golang.zx2c4.com/wireguard/device.(*Device).IpcGetOperation(0x0, {0x11a3ca0, 0xc0000ac580})
	/go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20250521234502-f333402bd9cb/device/uapi.go:52 +0x4c
golang.zx2c4.com/wireguard/device.(*Device).IpcGet(0x0)
	/go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20250521234502-f333402bd9cb/device/uapi.go:409 +0x38
github.com/fosrl/newt/clients.(*WireGuardService).ensureWireguardPeers(0xc0001ba820, {0x19981c0, 0x0, 0x19981c0?})
	/app/clients/clients.go:648 +0x45
github.com/fosrl/newt/clients.(*WireGuardService).handleConfig(0xc0001ba820, {{0xc00034a2d0, 0x16}, {0xec0520, 0xc0003eae40}})
	/app/clients/clients.go:475 +0x274
github.com/fosrl/newt/websocket.(*Client).readPumpWithDisconnectDetection(0xc0001bd180, {0x0?, 0x0?, 0x1976320?})
	/app/websocket/client.go:742 +0x21c
created by github.com/fosrl/newt/websocket.(*Client).establishConnection in goroutine 8
	/app/websocket/client.go:565 +0xb6a

Environment

  • OS Type & Version: Ubuntu 24.04.3 LTS (Noble Numbat)
  • Pangolin Version: 1.13.1
  • Gerbil Version: 1.3
  • Traefik Version: 3.5
  • Newt Version: 1.7

To Reproduce

The problem presented after the update, before all was smoothly running. No changes has been made to the configuration.

Expected Behavior

Successfully connect to the gerbil istance.

Originally created by @sickmitch on GitHub (Dec 15, 2025). Original GitHub issue: https://github.com/fosrl/newt/issues/201 ### Describe the Bug After updating the whole stack to be compatible to pangolin 1.13.1 my newt istance can't stay up anymore. At first glance all connects fine but after half a second the program panic and restart the container, over and over. Both pangolin and gerbil successfully add and connect to the newt istance for a moment, with normal logs. Seems like the problem is in the PANGOLIN_ENDPOINT variable, tried to change to various syntax but the only reaching gerbil is like from the docs PANGOLIN_ENDPOINT=https://app.pangolin.xx, changing the value changes the error in the newt container logs but without reaching out. Looked at [#176](https://github.com/fosrl/newt/issues/176) but segmentation violation codes looks different so I guess is another prob. ``` INFO: 2025/12/15 07:55:56 Starting metrics server on 127.0.0.1:2112 INFO: 2025/12/15 07:55:56 Newt version 1.7.0 INFO: 2025/12/15 07:55:56 Setting up clients with netstack2... INFO: 2025/12/15 07:55:56 Created shared UDP socket on port 63093 (refcount: 2) INFO: 2025/12/15 07:55:56 Server version: 1.13.1 INFO: 2025/12/15 07:55:56 Websocket connected INFO: 2025/12/15 07:55:56 Requesting WireGuard configuration from remote server INFO: 2025/12/15 07:55:57 Connecting to endpoint: pangolin.mydom.xx INFO: 2025/12/15 07:55:57 Starting UDP hole punch to 1 exit nodes with shared bind INFO: 2025/12/15 07:55:57 Starting hole punch to XX.XX.XX.XX with public key: pubKey INFO: 2025/12/15 07:55:57 Resolved exit node: XX.XX.XX.XX -> XX.XX.XX.XX:21820 INFO: 2025/12/15 07:55:57 Tunnel connection to server established successfully! INFO: 2025/12/15 07:55:57 Started direct UDP relay on XX.XX.XX.XX:63093 (bidirectional via SharedBind) INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:8096 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:22300 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5880 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:8004 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5001 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:3075 INFO: 2025/12/15 07:55:57 Direct UDP relay started (bidirectional through SharedBind) INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:3000 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:4588 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:5232 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:2283 INFO: 2025/12/15 07:55:57 Started tcp proxy to 10.0.0.30:9200 INFO: 2025/12/15 07:55:58 Received WireGuard clients configuration from remote server ERROR: 2025/12/15 07:55:58 Failed to ensure WireGuard interface: invalid IP address format: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x260 pc=0x632b2c] goroutine 99 [running]: sync/atomic.(*Int32).Add(...) /usr/local/go/src/sync/atomic/type.go:94 sync.(*RWMutex).RLock(...) /usr/local/go/src/sync/rwmutex.go:72 golang.zx2c4.com/wireguard/device.(*Device).IpcGetOperation(0x0, {0x11a3ca0, 0xc0000ac580}) /go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20250521234502-f333402bd9cb/device/uapi.go:52 +0x4c golang.zx2c4.com/wireguard/device.(*Device).IpcGet(0x0) /go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20250521234502-f333402bd9cb/device/uapi.go:409 +0x38 github.com/fosrl/newt/clients.(*WireGuardService).ensureWireguardPeers(0xc0001ba820, {0x19981c0, 0x0, 0x19981c0?}) /app/clients/clients.go:648 +0x45 github.com/fosrl/newt/clients.(*WireGuardService).handleConfig(0xc0001ba820, {{0xc00034a2d0, 0x16}, {0xec0520, 0xc0003eae40}}) /app/clients/clients.go:475 +0x274 github.com/fosrl/newt/websocket.(*Client).readPumpWithDisconnectDetection(0xc0001bd180, {0x0?, 0x0?, 0x1976320?}) /app/websocket/client.go:742 +0x21c created by github.com/fosrl/newt/websocket.(*Client).establishConnection in goroutine 8 /app/websocket/client.go:565 +0xb6a ``` ### Environment - OS Type & Version: Ubuntu 24.04.3 LTS (Noble Numbat) - Pangolin Version: 1.13.1 - Gerbil Version: 1.3 - Traefik Version: 3.5 - Newt Version: 1.7 ### To Reproduce The problem presented after the update, before all was smoothly running. No changes has been made to the configuration. ### Expected Behavior Successfully connect to the gerbil istance.
Author
Owner

@sickmitch commented on GitHub (Dec 15, 2025):

Redeployed fresh and is working, keeping the old images and confs to troubleshoot if needed but i guess it has been a migraion problem.

<!-- gh-comment-id:3654681818 --> @sickmitch commented on GitHub (Dec 15, 2025): Redeployed fresh and is working, keeping the old images and confs to troubleshoot if needed but i guess it has been a migraion problem.
Author
Owner

@oschwartz10612 commented on GitHub (Dec 15, 2025):

Yeah this seems like a migration problem - the site was not assigned an
IP address or a malformed one and the clients stuff was trying to init
and crashing. I will update Newt to prevent a full on panic when this
happens and just instead not start the clients.

The other patch solution that could have fixed this was to use
--disable-clients on the site - this would prevent it from trying to init.

In terms of why it failed to migrate you could click on the site in UI
in the old config or look in the database and see if it has a valid IP
in the address field. For the database:

s1lite3 config/db/db.sqlite

.headers on
select * from sites where niceId = '';

<!-- gh-comment-id:3656461615 --> @oschwartz10612 commented on GitHub (Dec 15, 2025): Yeah this seems like a migration problem - the site was not assigned an IP address or a malformed one and the clients stuff was trying to init and crashing. I will update Newt to prevent a full on panic when this happens and just instead not start the clients. The other patch solution that could have fixed this was to use --disable-clients on the site - this would prevent it from trying to init. In terms of why it failed to migrate you could click on the site in UI in the old config or look in the database and see if it has a valid IP in the address field. For the database: s1lite3 config/db/db.sqlite > .headers on > select * from sites where niceId = '<enter animal identifier here>';
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/newt#2046