Speicherzugriffsfehler im gluon-segment-mover

[Kistelini]

Moin, mir ist in der aktuellen Beta folgende Fehlermeldung im Log aufgefallen, die vorher nicht (ganz so umfangreich) da war.

Von zwei MIPS-Routern:

Sun May  3 23:25:00 2026 daemon.info micrond[2824]: Sleeping for 25 seconds.
Sun May  3 23:25:25 2026 kern.info kernel: [265286.176275] do_page_fault(): sending SIGSEGV to wget for invalid read access from 00000000
Sun May  3 23:25:25 2026 kern.info kernel: [265286.184725] epc = 00000000 in uclient-fetch[400000+4000]
Sun May  3 23:25:25 2026 kern.info kernel: [265286.190324] ra  = 77d0eaa3 in libubox.so.20240329[77d09000+1f000]
Sun May  3 23:25:25 2026 daemon.info micrond[2824]: Servers answer is weird. Aborting.

Und PowerPC:

Sun May  3 23:20:00 2026 daemon.info micrond[2754]: Sleeping for 11 seconds.
Sun May  3 23:20:11 2026 kern.info kernel: [263904.000149] wget[6359]: segfault (11) at 0 nip 0 lr b784a0ec code 1 in uclient-fetch[10000000+5000]
Sun May  3 23:20:11 2026 kern.info kernel: [263904.009492] wget[6359]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Sun May  3 23:20:11 2026 kern.info kernel: [263904.019000] wget[6359]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Sun May  3 23:20:11 2026 daemon.info micrond[2754]: Servers answer is weird. Aborting.

Die micrond-Meldungen kommen mit bekannt vor, die Speicherzugriffsfehler sind aber neu. Der Fehler tritt immer dann auf, wenn micrond den gluon-segment-mover startet.

Scheint mir relativ unkritisch und vll. ist das Problem ja auch schon bekannt, aber ich dachte ich gebe mal eben Bescheid.

[Manawyrm]

Nur auf MIPS und PowerPC gesehen? Schreit ein wenig danach, dass in uclient-fetch ausversehen ein Endianess-Bug eingebaut wurde (beide Architekturen sind Big Endian).
Müsste man mal die letzten Commits in der Gegend genau anschauen.

[Kistelini]

Ist u.a. ein Zyxel WSM20, somit ramips und little endian :)

[lemoer]

@Manawyrm Hattest du da noch irgendwas rausgefunden? :)

[lemoer]

Also observed on a fritzbox 7360:

Mon May 11 14:10:31 2026 kern.info kernel: [226813.162310] do_page_fault(): sending SIGSEGV to wget for invalid read access from 00000000
Mon May 11 14:10:31 2026 kern.info kernel: [226813.169342] epc = 00000000 in uclient-fetch[400000+4000]
Mon May 11 14:10:31 2026 kern.info kernel: [226813.174642] ra  = 77d0f983 in libubox.so.20240329[77d0a000+1f000]
Mon May 11 14:10:31 2026 daemon.info micrond[2209]: Servers answer is weird. Aborting.
Mon May 11 14:15:00 2026 daemon.info micrond[2209]: Sleeping for 35 seconds.
Mon May 11 14:15:35 2026 kern.info kernel: [227117.177123] do_page_fault(): sending SIGSEGV to wget for invalid read access from 00000000
Mon May 11 14:15:35 2026 kern.info kernel: [227117.184185] epc = 00000000 in uclient-fetch[400000+4000]
Mon May 11 14:15:35 2026 kern.info kernel: [227117.189466] ra  = 77d41983 in libubox.so.20240329[77d3c000+1f000]

[lemoer]

The wget seems to be triggered by

/usr/bin/lua /lib/gluon/gluon-segment-mover/relocate.lua

which calls:

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -q -O - 'http://hannover.freifunk.net/api/move/3431c400b8
6a'
Segmentation fault

[lemoer]

Interesting, it only segfaults for hannover.freifunk.net:

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -q -O /dev/null 'http://google.com/'
root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -q -O /dev/null 'http://code.ffh.zone/'
root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -q -O /dev/null 'http://hannover.freifunk.net/'
Segmentation fault

[lemoer]

Without -q

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -O /dev/null 'http://hannover.freifunk.net/'
Downloading 'http://hannover.freifunk.net/'
Connecting to 2a0a:4587:2031:10c::67:80
Failed to redirect to / on hannover.freifunk.net
Segmentation fault

strace output:

...
read(6, "HTTP/1.1 301 Moved Permanently\r\n"..., 4096) = 374
epoll_ctl(3, EPOLL_CTL_DEL, 6, NULL)    = 0
munmap(0x77df9000, 16384)               = 0
close(6)                                = 0
writev(2, [{iov_base="Failed to redirect to / on hanno"..., iov_len=49}, {iov_base=NULL, iov_len=0}], 2Failed to redirect to / on hannover.freifunk.net
) = 49
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++
Segmentation fault

[lemoer]

Ok, it seems to happen, when a page wants to redirect to https.

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -O /dev/null 'http://facebook.com/'
Downloading 'http://facebook.com/'
Connecting to 2a03:2880:f176:181:face:b00c:0:25de:80
Failed to redirect to / on facebook.com
Segmentation fault
root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -O /dev/null 'http://google.com/'
Downloading 'http://google.com/'
Connecting to 2a00:1450:4001:c15::66:80
Redirected to / on www.google.com
Writing to '/dev/null'

Download completed (79810 bytes)

E.g. google does redirect to http only:

lemoer@sol ~> curl -i http://google.com/
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
...

while e.g. facebook redirects to https

lemoer@sol ~> curl -i http://facebook.com/
HTTP/1.1 301 Moved Permanently
Location: https://facebook.com/
...

When I try to reach a server directly with https, it shows an error without segfaulting:

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# wget -O /dev/null 'https://facebook.com/'
wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

[lemoer]

If I correctly trace this, we are using a very old version of uclient due to still using the OpenWrt 24.10 release:

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='24.10-SNAPSHOT'

https://github.com/openwrt/openwrt/blob/v24.10.6/package/libs/uclient/Makefile#L10

or

root@UFU-FWH-F046-Oheriedentrift-50-W10:~# opkg list | grep uclient
libuclient20201210 - 2024.10.22~88ae8f20-r1 - HTTP/1.1 client library
uclient-fetch - 2024.10.22~88ae8f20-r1 - Tiny wget replacement using libuclient
ucode-mod-uclient - 2024.10.22~88ae8f20-r1 - ucode uclient module

=>

https://github.com/openwrt/uclient/commits/88ae8f20

After this, there were some fixes.

[lemoer]

I now removed the gluon-segment-mover to avoid the logspam for now. It might be fixed in the future anyways if Gluon updates its OpenWrt feed. Currently, we do not want to use the gluon-segment-mover.

[AiyionPrime]

Removing the segment mover is something we should avoid,
as it would result in a whole new version without it, which we can't move then.

I think we talked about the segment mover last week and also talked about how we're working towards Schwarmstedt, which is currently blocked by vH25 devices.

I think the conclusion that we do not want to move devices is not adequate and suggest we configure our webserver correctly.

The segment mover never worked with SSL due to the lack of space and does its command verification via signatures instead iirc.

I'd suggest we fix the configuration of our webserver and exclude the path segment mover expects to be reachable via HTTP from being a redirect to HTTPS.

[lemoer]

Ok, I reverted the commit. Fixing the webserver can be done independently from this.