[BUG] remote access to GUI from other local subnet

[mockbot]

First of all...
Dear @rerdavies, I love your amazing project very much! WOW!

Issue: it's some kind of cosmetic issue, but it is a small bug.

when accessing the web gui from another local subnet an error will be throw:

Error: Can't connect to server.
JSON.parse: unexpected
character at line 1 column 1 of
the JSON data

Network hints: 2 subnets 192.168.1.0/24 and 192.168.2.0/24
-the pipedal instance is located at an trusted IOT network .e.g. 192.168.1.11
-the client user, which needs to control the pipedal instance, is located at another untrusted guest wifi network e.g. 192.168.2.101
Both networks are properly routed and firewalled.
This means, there is no broadcast communication possible between the both routed networks ;-)

Screenshots

** Environment (please complete the following information):**
Pipedal:
Ubuntu 24.04 LTS Server (headless)
Focusride 2i2
USB-Midi

Webclients:
IPAD, MacOSX, Linux Ubuntu Studio with firefox or chrome

Notice: when both devices are in the same subnet, everything works perfectly!!!

Don't panic!
Best regards and greetings from the north of germany
Chrimo

[mockbot]

in the 'browser developer debug' is a webserver "server error 500" visible when fetching config.json
Error 500
Unexpected error. Address not supported.

Status
500
Internal Server Error
VersionHTTP/1.1
Transferred317 B (158 B size)
Referrer Policystrict-origin-when-cross-origin
DNS ResolutionSystem

[rerdavies]

The request fails because PiPedal is trying to generate an IPv4 address that the client machine can use for subsequent websocket and dynamic content requests to the server. Actually, it's trying to determine which network interface the request was received on, and what the IPv4 address for that interface is. Due to problems with IPv6 routing on Android, the websocket address must be provided to the client as an IPv4 address rather than an IPv6 address; and it has to be done carefully, because the PiPedal server can sometimes be dual-homed (an ethernet connection, AND an active auto-hotspot connection).

PiPedal may be running into trouble because the server is running on a guest subnet, that wouldn't ordinarily have access to the primary subnet. And if there is a VPN present, or network address translation (NAT) going on, that may also cause problems.

At any rate, I'm pretty sure the root issue is that existing code can't figure out what the routing back to the client machine is, when it is attempting to rewrite the server address to an IPv4 address. There are steps I could take to get this working, but I'd need to see what your routing tables look like.

Could you run the following commands on the Pipedal server, and send me the results. (You can send the results to me directly at rerdavies at gmail.com if you are concerned about publishing details of your local network on the open internet).

    ip addr show
    ip route show

[mockbot]

Hello, the answer for the routing tables is quite easy for both networks and devices --- a single default route to the central firewall-router. NO-DUAL-HOMED devices in this scenario ;-) The pipedal device is using the WiFi-interface wlo1 as client to the accesspoint only, LAN not used. The iPad or the Mac device with the webbrowser have WiFi only. cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=24.04 DISTRIB_CODENAME=noble DISTRIB_DESCRIPTION="Ubuntu 24.04.4 LTS" uname -a Linux nam 6.8.0-124-generic #124-Ubuntu SMP PREEMPT_DYNAMIC Tue May 26 13:00:45 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux dpkg -l pipedal Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-======================================== ii pipedal 2.0.108 amd64 IoT guitar effect pedal for Raspberry Pi ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether b0:6e:bf:1e:81:b3 brd ff:ff:ff:ff:ff:ff altname enp2s0 3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether a0:a4:c5:ab:0a:e5 brd ff:ff:ff:ff:ff:ff altname wlp0s12f0 inet 10.17.42.155/24 metric 600 brd 10.17.42.255 scope global dynamic wlo1 valid_lft 772sec preferred_lft 772sec inet6 fe80::a2a4:c5ff:feab:ae5/64 scope link valid_lft forever preferred_lft forever ip r default via 10.17.42.254 dev wlo1 proto dhcp src 10.17.42.155 metric 600 10.17.42.0/24 dev wlo1 proto kernel scope link src 10.17.42.155 metric 600 10.17.42.254 dev wlo1 proto dhcp scope link src 10.17.42.155 metric 600 192.166.253.21 via 10.17.42.254 dev wlo1 proto dhcp src 10.17.42.155 metric 600 ip l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000 link/ether b0:6e:bf:1e:81:b3 brd ff:ff:ff:ff:ff:ff altname enp2s0 3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000 link/ether a0:a4:c5:ab:0a:e5 brd ff:ff:ff:ff:ff:ff altname wlp0s12f0 Am Do., 2. Juli 2026 um 00:28 Uhr schrieb Robin Davies < ***@***.***>:

…

*rerdavies* left a comment (rerdavies/pipedal#522) <#522 (comment)> The request fails because PiPedal is trying to generate an IPv4 address that the client machine can use for subsequent websocket and dynamic content requests to the server. Actually, it's trying to determine which network interface the request was received on, and what the IPv4 address for that interface is. Due to problems with IPv6 routing on Android, the websocket address must be provided to the client as an IPv4 address rather than an IPv6 address; and it has to be done carefully, because the PiPedal server can sometimes be dual-homed (an ethernet connection, AND an active auto-hotspot connection). PiPedal may be running into trouble because the server is running on a guest subnet, that wouldn't ordinarily have access to the primary subnet. And if there is a VPN present, or network address translation (NAT) going on, that may also cause problems. At any rate, I'm pretty sure the root issue is that existing code can't figure out what the routing back to the client machine is, when it is attempting to rewrite the server address to an IPv4 address. There are steps I could take to get this working, but I'd need to see what your routing tables look like. Could you run the following commands on the Pipedal server, and send me the results. (You can send the results to me directly at rerdavies at gmail.com if you are concerned about publishing details of your local network on the open internet). ip addr show ip route show — Reply to this email directly, view it on GitHub <#522?email_source=notifications&email_token=AAIRDACRQ2PNDQE6DRVY5BL5CWGCTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWGA2TGNZSGYZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4860537263>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIRDADHTD5IYEOA73NZVTT5CWGCTAVCNFSNUABFKJSXA33TNF2G64TZHMZTSNRTHE4DGNJTHNEXG43VMU5TINZYGQ2TGNBZGU2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAIRDAEA46VMZQ2FCXLE5OL5CWGCTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWGA2TGNZSGYZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAIRDAAOUBAWOYKKZIEKW6D5CWGCTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBWGA2TGNZSGYZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[rerdavies]

Ok. I haven't reviewed code yet to see what's going on, but I strongly suspect that it's not handling the following routing entry properly. Could you just confirm that I'm reading this right.

From ip r:

192.166.253.21 via 10.17.42.254 dev wlo1 proto dhcp src 10.17.42.155 metric
600

Which I read as: packets directed to 192.166.253.21 (your PiPedal client systems) from 10.17.42.155 (your PiPedal server system) must be forwarded to 10.17.24.254 (the IPv4 gateway for interface wlo1).

[mockbot]

no, this additional route is added by the dhcp-server (isc-dhcpd)!
it is not really needed, because this is included in the default route.
Routing and priorities are always like this (with fallback)

1. host route
2. network route
3. default route

FYI: tomorrow, I install tshark/pcap-tools and try to make some network traces!
As I said before: I love to use your amazing software for playing guitar !!!!
Please don't waste your time with this special issue ;-)

[mockbot]

During debug sessions, I've noticed the following issue:
after the error appeared, wait 3 minutes and the WebUI starts working...
Every menue entry is available, but there is is no valid config loaded...
The pipedal is in mode "unconfigured"!
hmmmm...
the http error 500 before, indicates me: pipedal cannot read its own configuration...
I did not completely understand the process flow ;-(

[mockbot]

Some more traces

Same subnet / Browser client and Pipedal in the same WiFi VLAN: OK
160 7.263603925 10.17.42.178 → 10.17.42.155 HTTP 432 GET / HTTP/1.1
163 7.264300244 10.17.42.155 → 10.17.42.178 HTTP 4624 HTTP/1.1 200 OK (text/html)
182 7.300575434 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1
187 7.300575575 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1
191 7.300776834 10.17.42.178 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1
192 7.300776909 10.17.42.178 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1
193 7.300776946 10.17.42.178 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1
197 7.301165285 10.17.42.155 → 10.17.42.178 HTTP 926 HTTP/1.1 200 OK (text/css)
198 7.301175491 10.17.42.155 → 10.17.42.178 HTTP 3701 HTTP/1.1 200 OK (text/css)
200 7.301683669 10.17.42.155 → 10.17.42.178 HTTP 229 HTTP/1.1 200 OK (text/css)
203 7.303265745 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
206 7.308087941 10.17.42.178 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1
208 7.308606060 10.17.42.155 → 10.17.42.178 HTTP 2015 HTTP/1.1 200 OK (text/css)
210 7.312113115 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
404 7.423393398 10.17.42.155 → 10.17.42.178 HTTP 10835 HTTP/1.1 200 OK (application/javascript)
1453 8.450581129 10.17.42.155 → 10.17.42.178 HTTP 4452 HTTP/1.1 200 OK (application/javascript)
1473 8.806192160 10.17.42.178 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1
1475 8.807127025 10.17.42.155 → 10.17.42.178 HTTP/JSON 465 HTTP/1.1 200 OK , JSON (application/json)
1484 8.840613628 10.17.42.178 → 10.17.42.155 HTTP 538 GET /pipedal HTTP/1.1
1486 8.841108924 10.17.42.155 → 10.17.42.178 HTTP 226 HTTP/1.1 101 Switching Protocols

Router with NAT / Browser client inside trusted WiFi WLAN, Pipedal inside provider WiFi, all access to Pipedal is NATed: OK
111 4.708539714 192.168.2.254 → 192.168.2.113 HTTP 433 GET / HTTP/1.1
113 4.709238844 192.168.2.113 → 192.168.2.254 HTTP 4624 HTTP/1.1 200 OK (text/html)
134 4.806734319 192.168.2.254 → 192.168.2.113 HTTP 402 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1
136 4.806734452 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/roboto.css HTTP/1.1
138 4.806734581 192.168.2.254 → 192.168.2.113 HTTP 380 GET /assets/main-DzxI6d7I.js HTTP/1.1
140 4.806734716 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/modGui.css HTTP/1.1
147 4.807420619 192.168.2.113 → 192.168.2.254 HTTP 926 HTTP/1.1 200 OK (text/css)
149 4.808305911 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
150 4.808325312 192.168.2.113 → 192.168.2.254 HTTP 1225 HTTP/1.1 200 OK (text/css)
152 4.809685443 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
157 4.822366146 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
162 4.830634119 192.168.2.254 → 192.168.2.113 HTTP 418 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1
163 4.830634670 192.168.2.254 → 192.168.2.113 HTTP 411 GET /assets/main-Bul5VobU.css HTTP/1.1
176 4.831032672 192.168.2.113 → 192.168.2.254 HTTP 229 HTTP/1.1 200 OK (text/css)
178 4.831258713 192.168.2.113 → 192.168.2.254 HTTP 2015 HTTP/1.1 200 OK (text/css)
371 5.212175604 192.168.2.113 → 192.168.2.254 HTTP 931 HTTP/1.1 200 OK (application/javascript)
1121 6.652742329 192.168.2.113 → 192.168.2.254 HTTP 8166 HTTP/1.1 200 OK (application/javascript)
1153 6.950634563 192.168.2.254 → 192.168.2.113 HTTP 387 GET /var/config.json HTTP/1.1
1155 6.951668228 192.168.2.113 → 192.168.2.254 HTTP/JSON 466 HTTP/1.1 200 OK , JSON (application/json)
1164 6.967850821 192.168.2.254 → 192.168.2.113 HTTP 540 GET /pipedal HTTP/1.1
1166 6.968125558 192.168.2.113 → 192.168.2.254 HTTP 226 HTTP/1.1 101 Switching Protocols

Router with different VLANs, Firewall between Browser client and Pipedal: FAILED with Webserver Error 500 !!!!
4 0.009880886 192.166.253.107 → 10.17.42.155 HTTP 432 GET / HTTP/1.1
6 0.010529844 10.17.42.155 → 192.166.253.107 HTTP 4624 HTTP/1.1 200 OK (text/html)
28 0.055835660 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1
30 0.056404271 10.17.42.155 → 192.166.253.107 HTTP 3701 HTTP/1.1 200 OK (text/css)
34 0.062146997 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1
36 0.062147051 192.166.253.107 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1
38 0.062147107 192.166.253.107 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1
39 0.062147135 192.166.253.107 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1
45 0.062327915 192.166.253.107 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1
47 0.062730609 10.17.42.155 → 192.166.253.107 HTTP 926 HTTP/1.1 200 OK (text/css)
48 0.062884279 10.17.42.155 → 192.166.253.107 HTTP 229 HTTP/1.1 200 OK (text/css)
51 0.064449981 10.17.42.155 → 192.166.253.107 HTTP 2015 HTTP/1.1 200 OK (text/css)
53 0.064932824 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
61 0.076209463 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU]
272 0.477339482 10.17.42.155 → 192.166.253.107 HTTP 7121 HTTP/1.1 200 OK (application/javascript)
953 1.049774180 10.17.42.155 → 192.166.253.107 HTTP 15594 HTTP/1.1 200 OK (application/javascript)
994 1.336847070 192.166.253.107 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1
996 1.337826862 10.17.42.155 → 192.166.253.107 HTTP 383 HTTP/1.1 500 Internal Server Error

Fetching the config failed, because of "internal server error 500"
The GUI will be empty, because config is not available and switch to websocket not done.

FYI:
I cannot detect any packet drop in the firewall logs.
For some tests I've disabled IPv6 at Pipedal device (sysctl.conf and netplan wifi config) - no change!

[rerdavies]

Sorry. I should have been more clear. The bug is in C++ code. The process flow is: 1. PiPedal loads the web application from http://serveraddress 2. Once loaded, it fetches http://serveraddress/var/config.json, which is non-static content (anything in http://serveraddress/var is dynamic content, served from C++ code. Among other things, the config.json file contains the address of the websocket server. The websocket address may not be the same as serveraddress. In fact, it often is not. If serveraddress is an IPv6 address, it has to be switched to an IPv4 address. (Tone3000 web APIs absolutely require an IPv4 address; at one point, clients on Android also required an IPv4 address when running over the hotspot connection, but I think this is no longer the case). There is still a lot of cruft associated with debugging of routing problems when PiPedal was using Logs indicate that the server is throwing an exception while trying figure out which IPv4 address the client needs to use for the websocket connection. And that's most probably where the bug lies. The C++ code takes the local address on the HTTP connection, and attempts to convert it to an IPv4 address, which will be written back in config.json. There may well be legacy code, that should have been removed, that attempts the procedure on IP4 addresses as well. The procedure: take the local address of the HTTP connection; find the associated network interface; find the IPv4 address for that interface. Something goes wrong during that process. The code does not currently look at routing tables; it looks only at the subnet masks for the IPv4 address(es) on the interface. If I had to guess, I would guess that the code is incorrectly using the REMOTE address, instead of the local address, and therefore cannot find an interface associated with a 192.168.* address, which is a bit tragic, because I think your connection is made using IPv4, and all the code has to do is return the LOCAL address. (An Ipv6 address requires a bit of extra work -- the socket address does actually contain an interface ID buried away somewhere in the IPV6 addr). Unfortunately, the code bears a lot of cruft that should have been removed when PiPedal was using P2P Wi-Fi connections (broken in Debian 12), which triggered an emergency fix to switch over to a standard Wi-Fi AP, and code that wasn't really cleaned up properly afterward. :-/ I suspect that it should be MUCH simpler than it currently is, particularly when the inbound connection is already IPv4. It might be best to leave the fix (and the overdue removal of cruft) to me. If the fix is really urgent, I can take a look at it, and push a commit fix for it tomorrow (you would have to build it), but I can't push a public build for three or four days atm, due to a feature in progress. In the meantime, I'm not sure there's much you can do in client code. Robin Davies PiPedal Project

…

On Sun, Jul 5, 2026 at 8:09 AM Christian Mock ***@***.***> wrote: *mockbot* left a comment (rerdavies/pipedal#522) <#522 (comment)> Some more traces Same subnet / Browser client and Pipedal in the same WiFi VLAN: OK 160 7.263603925 10.17.42.178 → 10.17.42.155 HTTP 432 GET / HTTP/1.1 163 7.264300244 10.17.42.155 → 10.17.42.178 HTTP 4624 HTTP/1.1 200 OK (text/html) 182 7.300575434 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1 187 7.300575575 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1 191 7.300776834 10.17.42.178 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1 192 7.300776909 10.17.42.178 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 193 7.300776946 10.17.42.178 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 197 7.301165285 10.17.42.155 → 10.17.42.178 HTTP 926 HTTP/1.1 200 OK (text/css) 198 7.301175491 10.17.42.155 → 10.17.42.178 HTTP 3701 HTTP/1.1 200 OK (text/css) 200 7.301683669 10.17.42.155 → 10.17.42.178 HTTP 229 HTTP/1.1 200 OK (text/css) 203 7.303265745 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 206 7.308087941 10.17.42.178 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1 208 7.308606060 10.17.42.155 → 10.17.42.178 HTTP 2015 HTTP/1.1 200 OK (text/css) 210 7.312113115 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 404 7.423393398 10.17.42.155 → 10.17.42.178 HTTP 10835 HTTP/1.1 200 OK (application/javascript) 1453 8.450581129 10.17.42.155 → 10.17.42.178 HTTP 4452 HTTP/1.1 200 OK (application/javascript) 1473 8.806192160 10.17.42.178 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1 1475 8.807127025 10.17.42.155 → 10.17.42.178 HTTP/JSON 465 HTTP/1.1 200 OK , JSON (application/json) 1484 8.840613628 10.17.42.178 → 10.17.42.155 HTTP 538 GET /pipedal HTTP/1.1 1486 8.841108924 10.17.42.155 → 10.17.42.178 HTTP 226 HTTP/1.1 101 Switching Protocols Router with NAT / Browser client inside trusted WiFi WLAN, Pipedal inside provider WiFi, all access to Pipedal is NATed: OK 111 4.708539714 192.168.2.254 → 192.168.2.113 HTTP 433 GET / HTTP/1.1 113 4.709238844 192.168.2.113 → 192.168.2.254 HTTP 4624 HTTP/1.1 200 OK (text/html) 134 4.806734319 192.168.2.254 → 192.168.2.113 HTTP 402 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 136 4.806734452 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/roboto.css HTTP/1.1 138 4.806734581 192.168.2.254 → 192.168.2.113 HTTP 380 GET /assets/main-DzxI6d7I.js HTTP/1.1 140 4.806734716 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/modGui.css HTTP/1.1 147 4.807420619 192.168.2.113 → 192.168.2.254 HTTP 926 HTTP/1.1 200 OK (text/css) 149 4.808305911 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 150 4.808325312 192.168.2.113 → 192.168.2.254 HTTP 1225 HTTP/1.1 200 OK (text/css) 152 4.809685443 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 157 4.822366146 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 162 4.830634119 192.168.2.254 → 192.168.2.113 HTTP 418 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 163 4.830634670 192.168.2.254 → 192.168.2.113 HTTP 411 GET /assets/main-Bul5VobU.css HTTP/1.1 176 4.831032672 192.168.2.113 → 192.168.2.254 HTTP 229 HTTP/1.1 200 OK (text/css) 178 4.831258713 192.168.2.113 → 192.168.2.254 HTTP 2015 HTTP/1.1 200 OK (text/css) 371 5.212175604 192.168.2.113 → 192.168.2.254 HTTP 931 HTTP/1.1 200 OK (application/javascript) 1121 6.652742329 192.168.2.113 → 192.168.2.254 HTTP 8166 HTTP/1.1 200 OK (application/javascript) 1153 6.950634563 192.168.2.254 → 192.168.2.113 HTTP 387 GET /var/config.json HTTP/1.1 1155 6.951668228 192.168.2.113 → 192.168.2.254 HTTP/JSON 466 HTTP/1.1 200 OK , JSON (application/json) 1164 6.967850821 192.168.2.254 → 192.168.2.113 HTTP 540 GET /pipedal HTTP/1.1 1166 6.968125558 192.168.2.113 → 192.168.2.254 HTTP 226 HTTP/1.1 101 Switching Protocols Router with different VLANs, Firewall between Browser client and Pipedal: FAILED with Webserver Error 500 !!!! 4 0.009880886 192.166.253.107 → 10.17.42.155 HTTP 432 GET / HTTP/1.1 6 0.010529844 10.17.42.155 → 192.166.253.107 HTTP 4624 HTTP/1.1 200 OK (text/html) 28 0.055835660 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1 30 0.056404271 10.17.42.155 → 192.166.253.107 HTTP 3701 HTTP/1.1 200 OK (text/css) 34 0.062146997 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1 36 0.062147051 192.166.253.107 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1 38 0.062147107 192.166.253.107 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 39 0.062147135 192.166.253.107 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 45 0.062327915 192.166.253.107 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1 47 0.062730609 10.17.42.155 → 192.166.253.107 HTTP 926 HTTP/1.1 200 OK (text/css) 48 0.062884279 10.17.42.155 → 192.166.253.107 HTTP 229 HTTP/1.1 200 OK (text/css) 51 0.064449981 10.17.42.155 → 192.166.253.107 HTTP 2015 HTTP/1.1 200 OK (text/css) 53 0.064932824 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 61 0.076209463 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 272 0.477339482 10.17.42.155 → 192.166.253.107 HTTP 7121 HTTP/1.1 200 OK (application/javascript) 953 1.049774180 10.17.42.155 → 192.166.253.107 HTTP 15594 HTTP/1.1 200 OK (application/javascript) 994 1.336847070 192.166.253.107 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1 996 1.337826862 10.17.42.155 → 192.166.253.107 HTTP 383 HTTP/1.1 500 Internal Server Error Fetching the config failed, because of "internal server error 500" The GUI will be empty, because config is not available and switch to websocket not done. FYI: I cannot detect any packet drop in the firewall logs. For some tests I've disabled IPv6 at Pipedal device (sysctl.conf and netplan wifi config) - no change! — Reply to this email directly, view it on GitHub <#522?email_source=notifications&email_token=ACXK2DHS62TPVUTKUKV47PL5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4885979820>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXK2DHYVUUNPUEKOZ6XBKL5DJAOHAVCNFSNUABFKJSXA33TNF2G64TZHMZTSNRTHE4DGNJTHNEXG43VMU5TINZYGQ2TGNBZGU2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACXK2DF6QAWZ5BN4MXXFZCT5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ACXK2DDUUGUDTQEC5KRR6DL5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[rerdavies]

Looking at the code now... It's actually much cleaner than I thought. Very clean, in fact, if the connection is being made via IPv4. It should work with the IPv4 addresses you are using (but it obviously does not). Can you currently do a local build of the pipedal project? If so, there's a test I need to run. I'll send you a patch that logs the info I need. If not, I'll prepare a private build for you. In passing, PiPedal will definitely not run if there is active NAT (Network Address Translation) that's rewriting packet addresses. And I don't think there's actually a NAT involved if you are going WLAN to Wi-Fi connection on the same Wi-Fi router. It does work, which rather suggests that there is not. However, if the VLAN is doing substantial rewriting of packets, that might be a problem (I don't think it should). Unless the VLAN is rewriting IPv4 packets as IPv6 packets. (Handling of Ipv6 packets in the code in question is substantially more complicated than the Ipv4 case). Is the PiPedal server running in a VM? Robin Davies

…

On Sun, Jul 5, 2026 at 8:09 AM Christian Mock ***@***.***> wrote: *mockbot* left a comment (rerdavies/pipedal#522) <#522 (comment)> Some more traces Same subnet / Browser client and Pipedal in the same WiFi VLAN: OK 160 7.263603925 10.17.42.178 → 10.17.42.155 HTTP 432 GET / HTTP/1.1 163 7.264300244 10.17.42.155 → 10.17.42.178 HTTP 4624 HTTP/1.1 200 OK (text/html) 182 7.300575434 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1 187 7.300575575 10.17.42.178 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1 191 7.300776834 10.17.42.178 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1 192 7.300776909 10.17.42.178 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 193 7.300776946 10.17.42.178 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 197 7.301165285 10.17.42.155 → 10.17.42.178 HTTP 926 HTTP/1.1 200 OK (text/css) 198 7.301175491 10.17.42.155 → 10.17.42.178 HTTP 3701 HTTP/1.1 200 OK (text/css) 200 7.301683669 10.17.42.155 → 10.17.42.178 HTTP 229 HTTP/1.1 200 OK (text/css) 203 7.303265745 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 206 7.308087941 10.17.42.178 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1 208 7.308606060 10.17.42.155 → 10.17.42.178 HTTP 2015 HTTP/1.1 200 OK (text/css) 210 7.312113115 10.17.42.155 → 10.17.42.178 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 404 7.423393398 10.17.42.155 → 10.17.42.178 HTTP 10835 HTTP/1.1 200 OK (application/javascript) 1453 8.450581129 10.17.42.155 → 10.17.42.178 HTTP 4452 HTTP/1.1 200 OK (application/javascript) 1473 8.806192160 10.17.42.178 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1 1475 8.807127025 10.17.42.155 → 10.17.42.178 HTTP/JSON 465 HTTP/1.1 200 OK , JSON (application/json) 1484 8.840613628 10.17.42.178 → 10.17.42.155 HTTP 538 GET /pipedal HTTP/1.1 1486 8.841108924 10.17.42.155 → 10.17.42.178 HTTP 226 HTTP/1.1 101 Switching Protocols Router with NAT / Browser client inside trusted WiFi WLAN, Pipedal inside provider WiFi, all access to Pipedal is NATed: OK 111 4.708539714 192.168.2.254 → 192.168.2.113 HTTP 433 GET / HTTP/1.1 113 4.709238844 192.168.2.113 → 192.168.2.254 HTTP 4624 HTTP/1.1 200 OK (text/html) 134 4.806734319 192.168.2.254 → 192.168.2.113 HTTP 402 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 136 4.806734452 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/roboto.css HTTP/1.1 138 4.806734581 192.168.2.254 → 192.168.2.113 HTTP 380 GET /assets/main-DzxI6d7I.js HTTP/1.1 140 4.806734716 192.168.2.254 → 192.168.2.113 HTTP 401 GET /css/modGui.css HTTP/1.1 147 4.807420619 192.168.2.113 → 192.168.2.254 HTTP 926 HTTP/1.1 200 OK (text/css) 149 4.808305911 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 150 4.808325312 192.168.2.113 → 192.168.2.254 HTTP 1225 HTTP/1.1 200 OK (text/css) 152 4.809685443 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 157 4.822366146 192.168.2.113 → 192.168.2.254 TCP 2542 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 162 4.830634119 192.168.2.254 → 192.168.2.113 HTTP 418 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 163 4.830634670 192.168.2.254 → 192.168.2.113 HTTP 411 GET /assets/main-Bul5VobU.css HTTP/1.1 176 4.831032672 192.168.2.113 → 192.168.2.254 HTTP 229 HTTP/1.1 200 OK (text/css) 178 4.831258713 192.168.2.113 → 192.168.2.254 HTTP 2015 HTTP/1.1 200 OK (text/css) 371 5.212175604 192.168.2.113 → 192.168.2.254 HTTP 931 HTTP/1.1 200 OK (application/javascript) 1121 6.652742329 192.168.2.113 → 192.168.2.254 HTTP 8166 HTTP/1.1 200 OK (application/javascript) 1153 6.950634563 192.168.2.254 → 192.168.2.113 HTTP 387 GET /var/config.json HTTP/1.1 1155 6.951668228 192.168.2.113 → 192.168.2.254 HTTP/JSON 466 HTTP/1.1 200 OK , JSON (application/json) 1164 6.967850821 192.168.2.254 → 192.168.2.113 HTTP 540 GET /pipedal HTTP/1.1 1166 6.968125558 192.168.2.113 → 192.168.2.254 HTTP 226 HTTP/1.1 101 Switching Protocols Router with different VLANs, Firewall between Browser client and Pipedal: FAILED with Webserver Error 500 !!!! 4 0.009880886 192.166.253.107 → 10.17.42.155 HTTP 432 GET / HTTP/1.1 6 0.010529844 10.17.42.155 → 192.166.253.107 HTTP 4624 HTTP/1.1 200 OK (text/html) 28 0.055835660 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/modGui.css HTTP/1.1 30 0.056404271 10.17.42.155 → 192.166.253.107 HTTP 3701 HTTP/1.1 200 OK (text/css) 34 0.062146997 192.166.253.107 → 10.17.42.155 HTTP 399 GET /css/roboto.css HTTP/1.1 36 0.062147051 192.166.253.107 → 10.17.42.155 HTTP 378 GET /assets/main-DzxI6d7I.js HTTP/1.1 38 0.062147107 192.166.253.107 → 10.17.42.155 HTTP 400 GET /assets/jsx-runtime-9Cf67OdD.js HTTP/1.1 39 0.062147135 192.166.253.107 → 10.17.42.155 HTTP 416 GET /assets/jsx-runtime-x1XGuNl0.css HTTP/1.1 45 0.062327915 192.166.253.107 → 10.17.42.155 HTTP 409 GET /assets/main-Bul5VobU.css HTTP/1.1 47 0.062730609 10.17.42.155 → 192.166.253.107 HTTP 926 HTTP/1.1 200 OK (text/css) 48 0.062884279 10.17.42.155 → 192.166.253.107 HTTP 229 HTTP/1.1 200 OK (text/css) 51 0.064449981 10.17.42.155 → 192.166.253.107 HTTP 2015 HTTP/1.1 200 OK (text/css) 53 0.064932824 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 61 0.076209463 10.17.42.155 → 192.166.253.107 TCP 6256 HTTP/1.1 200 OK [TCP segment of a reassembled PDU] 272 0.477339482 10.17.42.155 → 192.166.253.107 HTTP 7121 HTTP/1.1 200 OK (application/javascript) 953 1.049774180 10.17.42.155 → 192.166.253.107 HTTP 15594 HTTP/1.1 200 OK (application/javascript) 994 1.336847070 192.166.253.107 → 10.17.42.155 HTTP 385 GET /var/config.json HTTP/1.1 996 1.337826862 10.17.42.155 → 192.166.253.107 HTTP 383 HTTP/1.1 500 Internal Server Error Fetching the config failed, because of "internal server error 500" The GUI will be empty, because config is not available and switch to websocket not done. FYI: I cannot detect any packet drop in the firewall logs. For some tests I've disabled IPv6 at Pipedal device (sysctl.conf and netplan wifi config) - no change! — Reply to this email directly, view it on GitHub <#522?email_source=notifications&email_token=ACXK2DHS62TPVUTKUKV47PL5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4885979820>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXK2DHYVUUNPUEKOZ6XBKL5DJAOHAVCNFSNUABFKJSXA33TNF2G64TZHMZTSNRTHE4DGNJTHNEXG43VMU5TINZYGQ2TGNBZGU2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACXK2DF6QAWZ5BN4MXXFZCT5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ACXK2DDUUGUDTQEC5KRR6DL5DJAOHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU4TOOJYGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[rerdavies]

During debug sessions, I've noticed the following issue: after the error appeared, wait 3 minutes and the WebUI starts working...

Thanks for the info. Actually a minor bug-let. Failure to fetch the config.json file should be firmly and irrevocably fatal (and the uncaught error should be better, although no less grim). I logged the issue, and will correct it shortly.

…

On Sun, Jul 5, 2026 at 5:22 AM Christian Mock ***@***.***> wrote: *mockbot* left a comment (rerdavies/pipedal#522) <#522 (comment)> During debug sessions, I've noticed the following issue: after the error appeared, wait 3 minutes and the WebUI starts working... Every menue entry is available, but there is is no valid config loaded... The pipedal is in mode "unconfigured"! hmmmm... the http error 500 before, indicates me: pipedal cannot read its own configuration... I did not completely understand the process flow ;-( — Reply to this email directly, view it on GitHub <#522?email_source=notifications&email_token=ACXK2DBQLAHAXNJLCATXLGT5DIM5FA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU2TENBRG43KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4885524176>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXK2DHEW3SF22RW4J6DTOT5DIM5FAVCNFSNUABFKJSXA33TNF2G64TZHMZTSNRTHE4DGNJTHNEXG43VMU5TINZYGQ2TGNBZGU2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACXK2DCD2SADJ4RXGMLXTDL5DIM5FA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU2TENBRG43KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ACXK2DH5AZLZH3YSVU2GBS35DIM5FA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBYGU2TENBRG43KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[rerdavies]

Fixed. Will show up in next release.

[mockbot]

Dear RerDavies,
sorry for the late response, I was busy and plaing my daughters wedding party!
My PC is your PC! When you need a testenvironment, please drop me a note!
I can connect my small ASUS PN42 to the internet and give you access or I can prepare some more testbed for you!

Million thanks for your endless friendly support
Regards
Chrimo

[rerdavies]

Sub-net routing issues are fixed in v2.0.109. Please update and try again.