Segfault running redsocks on GL.inet GL A1300 wrt 24

Hi, so after multiple tries to run OpenWRT on GL.inet GL A1300 router I have to admit that neither is working:

  1. on default GL inet firmware redsocks were failing to run (segfault)
  2. After update of firmware to pure OpenWRT 24 factory image and then sysimage it was the same
  3. I've requested custom image with redsocks installed - same package was provided in the image, resulting in the same issue.

  4. package of redsocks wasn't really changed between releases 24.10.1 and 24.10.2 so it is same problem
root@OpenWrt:~# uname -m
armv7l
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='24.10.1'
DISTRIB_REVISION='r28597-0425664679'
DISTRIB_TARGET='ipq40xx/generic'
DISTRIB_ARCH='arm_cortex-a7_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 24.10.1 r28597-0425664679'
DISTRIB_TAINTS=''

Question to dear public - as I'm far from networking, I assume I need something like redsocks to enable me to route all traffic of local wifi users to internet via cloud socks server requiring auth as in below pseudo

[Client Devices]
      │ (Connect via WiFi AP on radio1 — SSID: e.g., "xyz")
      ▼
[GL.iNet A1300]
   ├── radio1: Wi-Fi Access Point for local clients
   └── radio0: Wi-Fi Client connecting to upstream internet (SSID: e.g., "abc")
      │
      ▼
[SOCKS5 Proxy (login:pass@domain:port)]
      │
      ▼
[Public Internet]

If such is true, could you please recommend WRT version and package (redsocks or redsocks2 or shadowsocks or anything else) which you tested and it works on specifically GL A1300 which could enable me doing expected routing and communication with remote socks server.

Can you get logread from around the crash e.g. restarting redsock service.

Disable demon (background execution) and set logging to console instead of syslog in the conf file, run redsocks manually from prompt.

Post error messages, if any.

Post you conf, if needed, mask socks IP/FQDN and logon details.
Use </> button when you paste the text.

Ok, so I've disable daemon run in config and run it in console. Got zero output in log and in console it was only the below

root@OpenWrt:~# redsocks -c /etc/redsocks.conf
Segmentation fault
base {
    log_debug = on;
    log_info = on;
    daemon = off;
    redirector = iptables;
}

redsocks {
    local_ip = 127.0.0.1;
    local_port = 12345;
    ip = ip.com;
    port = 9999;
    type = socks5;
    login = yyyy;
    password = xxx;
}

and logread has last messages related to dhcp when I connected to router:

Thu Jul  3 19:33:34 2025 daemon.notice netifd: wwan (2427): udhcpc: lease of 192.168.1.103 obtained from 192.168.1.1, lease time 86400
Thu Jul  3 19:33:35 2025 daemon.notice netifd: Interface 'wwan' is now up
Thu Jul  3 19:33:35 2025 user.notice firewall: Reloading firewall due to ifup of wwan (phy0-sta0)
Thu Jul  3 19:33:35 2025 daemon.warn odhcpd[1222]: No default route present, overriding ra_lifetime to 0!
Thu Jul  3 19:33:36 2025 daemon.warn odhcpd[1222]: No default route present, overriding ra_lifetime to 0!
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 0xxx3
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.5.140 0xxx3
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using nameserver 8.8.8.8#53
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using nameserver 1.1.1.1#53
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using nameserver 192.168.1.1#53
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for test
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for local
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Thu Jul  3 19:s33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Thu Jul  3 19:33:38 2025 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Thu Jul  3 19:33:39 2025 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.5.140 0xxxx3
Thu Jul  3 19:33:39 2025 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.5.140 0xxxx3 username 

In general I'm trying to solve routing thing, not exacly with redsocks so if you think there is a stable package for WRT 24 and GL A1300 which i should try instead - please let me know. I guess there few theories why redsocks might fall:

  1. nftables instead of iptables
  2. 2 radios on device and it doesnt know about it
  3. package is compiled for another architecture but is shipped for this device (not sure if this is even possible with build pipelines wrt has)

Do you have iptables-nft and ip6tables-nft installed?

this is WRT 24 it should have nftables, not iptables. but below are all packages installed

root@OpenWrt:~# opkg list-installed
ath10k-board-qca4019 - 20241110-r1
ath10k-firmware-qca4019-ct - 2020.11.08-r1
base-files - 1658~0425664679
busybox - 1.36.1-r2
ca-bundle - 20241223-r1
cgi-io - 2022.08.10~901b0f04-r21
dnsmasq - 2.90-r4
dropbear - 2024.86-r1
firewall4 - 2024.12.18~18fc0ead-r1
fstools - 2024.07.14~408c2cc4-r1
fwtool - 2019.11.12~8f7fe925-r1
getrandom - 2024.04.26~85f10530-r1
hostapd-common - 2024.09.15~5ace39b0-r2
iw - 6.9-r1
iwinfo - 2024.10.20~b94f066e-r1
jansson4 - 2.14-r3
jshn - 2024.03.29~eb9bcb64-r1
jsonfilter - 2024.01.23~594cfa86-r1
kernel - 6.6.86~86a3ff6dadb6f11ea15032190af7b3de-r1
kmod-ath - 6.6.86.6.12.6-r1
kmod-ath10k-ct - 6.6.86.2024.07.30~ac71b14d-r2
kmod-cfg80211 - 6.6.86.6.12.6-r1
kmod-crypto-acompress - 6.6.86-r1
kmod-crypto-aead - 6.6.86-r1
kmod-crypto-ccm - 6.6.86-r1
kmod-crypto-cmac - 6.6.86-r1
kmod-crypto-crc32c - 6.6.86-r1
kmod-crypto-ctr - 6.6.86-r1
kmod-crypto-gcm - 6.6.86-r1
kmod-crypto-geniv - 6.6.86-r1
kmod-crypto-gf128 - 6.6.86-r1
kmod-crypto-ghash - 6.6.86-r1
kmod-crypto-hash - 6.6.86-r1
kmod-crypto-hmac - 6.6.86-r1
kmod-crypto-manager - 6.6.86-r1
kmod-crypto-null - 6.6.86-r1
kmod-crypto-rng - 6.6.86-r1
kmod-crypto-seqiv - 6.6.86-r1
kmod-crypto-sha3 - 6.6.86-r1
kmod-crypto-sha512 - 6.6.86-r1
kmod-gpio-button-hotplug - 6.6.86-r5
kmod-hwmon-core - 6.6.86-r1
kmod-leds-gpio - 6.6.86-r1
kmod-lib-crc-ccitt - 6.6.86-r1
kmod-lib-crc32c - 6.6.86-r1
kmod-lib-lzo - 6.6.86-r1
kmod-mac80211 - 6.6.86.6.12.6-r1
kmod-nf-conntrack - 6.6.86-r1
kmod-nf-conntrack6 - 6.6.86-r1
kmod-nf-flow - 6.6.86-r1
kmod-nf-log - 6.6.86-r1
kmod-nf-log6 - 6.6.86-r1
kmod-nf-nat - 6.6.86-r1
kmod-nf-reject - 6.6.86-r1
kmod-nf-reject6 - 6.6.86-r1
kmod-nfnetlink - 6.6.86-r1
kmod-nft-core - 6.6.86-r1
kmod-nft-fib - 6.6.86-r1
kmod-nft-nat - 6.6.86-r1
kmod-nft-offload - 6.6.86-r1
kmod-nls-base - 6.6.86-r1
kmod-ppp - 6.6.86-r1
kmod-pppoe - 6.6.86-r1
kmod-pppox - 6.6.86-r1
kmod-slhc - 6.6.86-r1
kmod-usb-core - 6.6.86-r1
kmod-usb-dwc3 - 6.6.86-r1
kmod-usb-dwc3-qcom - 6.6.86-r1
kmod-usb-xhci-hcd - 6.6.86-r1
kmod-usb3 - 6.6.86-r1
libblobmsg-json20240329 - 2024.03.29~eb9bcb64-r1
libc - 1.2.5-r4
libevent2-core7 - 2.1.12-r2
libgcc1 - 13.3.0-r4
libiwinfo-data - 2024.10.20~b94f066e-r1
libiwinfo20230701 - 2024.10.20~b94f066e-r1
libjson-c5 - 0.18-r1
libjson-script20240329 - 2024.03.29~eb9bcb64-r1
liblucihttp-ucode - 2023.03.15~9b5b683f-r1
liblucihttp0 - 2023.03.15~9b5b683f-r1
libmbedtls21 - 3.6.3-r1
libmnl0 - 1.0.5-r1
libnftnl11 - 1.2.8-r1
libnl-tiny1 - 2025.03.19~c0df580a-r1
libpthread - 1.2.5-r4
libubox20240329 - 2024.03.29~eb9bcb64-r1
libubus20250102 - 2025.01.02~afa57cce-r1
libuci20250120 - 2025.01.20~16ff0bad-r1
libuclient20201210 - 2024.10.22~88ae8f20-r1
libucode20230711 - 2025.02.10~a8a11aea-r1
libudebug - 2023.12.06~6d3f51f9
libustream-mbedtls20201210 - 2024.07.28~99bd3d2b-r1
logd - 2024.04.26~85f10530-r1
luci - 25.103.51521~2ac26e5
luci-app-firewall - 25.103.51521~2ac26e5
luci-app-package-manager - 25.103.51521~2ac26e5
luci-base - 25.103.51521~2ac26e5
luci-light - 25.103.51521~2ac26e5
luci-mod-admin-full - 25.103.51521~2ac26e5
luci-mod-network - 25.103.51521~2ac26e5
luci-mod-status - 25.103.51521~2ac26e5
luci-mod-system - 25.103.51521~2ac26e5
luci-proto-ipv6 - 25.103.51521~2ac26e5
luci-proto-ppp - 25.103.51521~2ac26e5
luci-ssl - 25.103.51521~2ac26e5
luci-theme-bootstrap - 25.103.51521~2ac26e5
microsocks - 1.0.4-r2
mtd - 26
netifd - 2024.12.17~ea01ed41-r1
nftables-json - 1.1.1-r1
odhcp6c - 2024.09.25~b6ae9ffa-r1
odhcpd-ipv6only - 2024.05.08~a2988231-r1
openwrt-keyring - 2024.11.01~fbae29d7-r2
opkg - 2024.10.16~38eccbb1-r1
ppp - 2.5.1-r1
ppp-mod-pppoe - 2.5.1-r1
procd - 2024.12.22~42d39376-r1
procd-seccomp - 2024.12.22~42d39376-r1
procd-ujail - 2024.12.22~42d39376-r1
px5g-mbedtls - 11
redsocks - 0.5-r2
rpcd - 2024.09.17~9f4b86e7-r1
rpcd-mod-file - 2024.09.17~9f4b86e7-r1
rpcd-mod-iwinfo - 2024.09.17~9f4b86e7-r1
rpcd-mod-luci - 20240305-r1
rpcd-mod-rrdns - 20170710
rpcd-mod-ucode - 2024.09.17~9f4b86e7-r1
ubi-utils - 2.2.1-r1
uboot-envtools - 2024.07-r1
ubox - 2024.04.26~85f10530-r1
ubus - 2025.01.02~afa57cce-r1
ubusd - 2025.01.02~afa57cce-r1
uci - 2025.01.20~16ff0bad-r1
uclient-fetch - 2024.10.22~88ae8f20-r1
ucode - 2025.02.10~a8a11aea-r1
ucode-mod-fs - 2025.02.10~a8a11aea-r1
ucode-mod-html - 1
ucode-mod-math - 2025.02.10~a8a11aea-r1
ucode-mod-nl80211 - 2025.02.10~a8a11aea-r1
ucode-mod-rtnl - 2025.02.10~a8a11aea-r1
ucode-mod-ubus - 2025.02.10~a8a11aea-r1
ucode-mod-uci - 2025.02.10~a8a11aea-r1
ucode-mod-uloop - 2025.02.10~a8a11aea-r1
uhttpd - 2023.06.25~34a8a74d-r4
uhttpd-mod-ubus - 2023.06.25~34a8a74d-r4
urandom-seed - 3
urngd - 2023.11.01~44365eb1-r1
usign - 2020.05.23~f1f65026-r1
wifi-scripts - 1.0-r1
wireless-regdb - 2025.02.20-r1
wpad-basic-mbedtls - 2024.09.15~5ace39b0-r2

I won't have access to any Openwrt device for another couple of days, but I don't think you've changed all the settings I told you to change...

No need, AFAIK.

To be fair - I retried to setup iptables, iptables-mod-nat-extra and now have these rules in iptables whcih are running:

# Generated by iptables-save v1.8.10 (nf_tables) on Sat Jul  5 11:37:49 2025
*filter
:INPUT ACCEPT [490:46261]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i br-lan -p tcp -m tcp --dport 12345 -j ACCEPT
COMMIT
# Completed on Sat Jul  5 11:37:49 2025
# Generated by iptables-save v1.8.10 (nf_tables) on Sat Jul  5 11:37:49 2025
*nat
:PREROUTING ACCEPT [355:118327]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:REDSOCKS - [0:0]
-A PREROUTING -i br-lan -p tcp -j REDSOCKS
-A REDSOCKS -d 0.0.0.0/8 -j RETURN
-A REDSOCKS -d 10.0.0.0/8 -j RETURN
-A REDSOCKS -d 100.64.0.0/10 -j RETURN
-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 198.18.0.0/15 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN
-A REDSOCKS -p tcp -j REDIRECT --to-ports 12345
COMMIT
# Completed on Sat Jul  5 11:37:49 2025

still I got sefault on running redsocks. again, it is wrt 24 and a1300 gl.inet. I can provide also list of packages again - from previous only iptables, iptables-mod-nat-extra were added.

I think it needs tproxy too (iptables mod and nft kmod)

As long as binary crashes, OP probably don't need any extras är all ,)

to be honest i'm very sad that redsocks upon running gives nothing except 'Segmentation fault' message. imho how this software is engineered it can't print anything meaningful even in debug... :rofl:

I even tried to follow route of compilation of redsocks from wrt for specific architecture but having only a mac and then docker I got full night of very weird issues compiling and ended nowhere.

Since this package isn't really release bound, you could try to manually install an older or later (snapshot, if you're already on 24.10.2) release of redsocks.

I can see here
https://downloads.openwrt.org/snapshots/packages/arm_cortex-a7_neon-vfpv4/packages/

a package https://downloads.openwrt.org/snapshots/packages/arm_cortex-a7_neon-vfpv4/packages/redsocks-0.5-r2.apk but it is not an ipk, but apk - how to install it on wrt24? luci or opkg doesn't eat it.

Yeah, my bad, can't easily install an apk package on an opkg environment, I had forgotten about the package manager/format change.

You could however try the package from the 24.10 snapshots in https://downloads.openwrt.org/releases/24.10-SNAPSHOT/.

As previously stated, you can go back to the gl.inet stock image any time.

No one here owes you anything.

I also get the segfault running redsocks on more recent OpenWrt versions. In particular, I am using Gl.Inet AR750S Slate (ath79) with NAND and NOR support (although I don't imagine that makes a difference).

I also get zero debugging output when running in a terminal, with logging to stderr. I guess my next step is to try running with strace to see what calls it is making, and maybe get an idea of where it is failing.

Of course, segfault is usually caused by trying to access inaccessible memory (.e.g buffer overflow) so not sure if that will show up. Is Valgrind available on OpenWrt?

Try downgrading the redsocks package, it doesn't have any kmod dependencies, AFAIK.

If it works using an older version, it might be a good idea to create a bug report at https://github.com/openwrt/packages.

Good call. I was able to get it working by downgrading everything to 22.x iirc, but that is a huge diff to wade through :slight_smile: Will see how I get on with just downgrading the redsocks opkg. I'm guessing the easiest way is just to download the opkg (and dependencies) from an earlier build, and install them manually? Or does opkg have a way of specifying a version from a different build?

This is the tail of strace -f redsocks output:

socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
bind(7, {sa_family=AF_INET, sin_port=htons(10053), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
fcntl64(7, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 7, {events=EPOLLIN, data={u32=7, u64=7}}) = 0
socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
bind(8, {sa_family=AF_INET, sin_port=htons(5300), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
fcntl64(8, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(8, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 8, {events=EPOLLIN, data={u32=8, u64=8}}) = 0
rt_sigaction(SIGTERM, {sa_handler=0x77e0c479, sa_mask=~[RTMIN RT_1 RT_2], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 16) = 0
rt_sigaction(SIGINT, {sa_handler=0x77e0c479, sa_mask=~[RTMIN RT_1 RT_2], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 16) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x6d6b6} ---
+++ killed by SIGSEGV +++
Segmentation fault

Checking opkg options now.

Doing some initial digging into the opkg archives, and pulling all the versions of redsocks from 22.03.0 to present, and checking for their dependencies, I get:

22.03.0/control.tar.gz: Depends: libc, libevent2-core7
22.03.1/control.tar.gz: Depends: libc, libevent2-core7
22.03.2/control.tar.gz: Depends: libc, libevent2-core7
22.03.3/control.tar.gz: Depends: libc, libevent2-core7
22.03.4/control.tar.gz: Depends: libc, libevent2-core7
22.03.5/control.tar.gz: Depends: libc, libevent2-core7
22.03.6/control.tar.gz: Depends: libc, libevent2-core7
22.03.7/control.tar.gz: Depends: libc, libevent2-core7
23.05.0/control.tar.gz: Depends: libc, libevent2-core7
23.05.1/control.tar.gz: Depends: libc, libevent2-core7
23.05.2/control.tar.gz: Depends: libc, libevent2-core7
23.05.3/control.tar.gz: Depends: libc, libevent2-core7
23.05.4/control.tar.gz: Depends: libc, libevent2-core7
23.05.5/control.tar.gz: Depends: libc, libevent2-core7
24.10.0/control.tar.gz: Depends: libc, libevent2-core7
24.10.1/control.tar.gz: Depends: libc, libevent2-core7
24.10.2/control.tar.gz: Depends: libc, libevent2-core7

i.e. there doesn't seem to be much change. The only thing I can imagine changing is the compiler and/or compiler options. Anyway, will try step through the various versions to see if I get any different behaviour.

Ok, I downloaded all of the libevent2-core7 and redsocks builds from packages as far back as 22.03.0.

I installed them one at a time (working backwards) on my Xiaomi 4A gigabit (mipsel_24kc) router, running 24.10.0.

for release in $(ls -d 2* | sort -rh); do
echo $release
scp -O $release/{redsocks,libevent}* ap2:/tmp
read
done

On my PC, and:

opkg install libevent*.ipk; opkg install redsocks*.ipk
opkg remove redsocks libevent2-core7; rm redsocks* libevent*

on the Xiaomi.

I was hoping to see that at least one version worked, but every single instance resulted in a segmentation fault.

 sha1sum 2*/*.ipk | sort
9078a81a583765bda1ab7fea3a8945cd5a83037c  24.10.0/libevent2-core7_2.1.12-r2_mipsel_24kc.ipk
9078a81a583765bda1ab7fea3a8945cd5a83037c  24.10.1/libevent2-core7_2.1.12-r2_mipsel_24kc.ipk
9078a81a583765bda1ab7fea3a8945cd5a83037c  24.10.2/libevent2-core7_2.1.12-r2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.0/redsocks_0.5-2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.1/redsocks_0.5-2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.2/redsocks_0.5-2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.3/redsocks_0.5-2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.4/redsocks_0.5-2_mipsel_24kc.ipk
d2678c2f63c77889e855356147fb328cde1e2c3b  23.05.5/redsocks_0.5-2_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.0/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.1/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.2/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.3/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.4/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
df72ecee6c87c738ccb3d4c4d3075798c38e1934  23.05.5/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
e34307678eeb99afb8ba31ee8efdc5afa253f871  24.10.0/redsocks_0.5-r2_mipsel_24kc.ipk
e34307678eeb99afb8ba31ee8efdc5afa253f871  24.10.1/redsocks_0.5-r2_mipsel_24kc.ipk
e34307678eeb99afb8ba31ee8efdc5afa253f871  24.10.2/redsocks_0.5-r2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.0/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.1/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.2/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.3/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.4/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.5/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.6/redsocks_0.5-2_mipsel_24kc.ipk
f6eb77db40acc681e318b30f37ab8f1af6fa587e  22.03.7/redsocks_0.5-2_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.0/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.1/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.2/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.3/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.4/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.5/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.6/libevent2-core7_2.1.12-1_mipsel_24kc.ipk
fa3593804af3c5243db19ea87b04828b95a20e21  22.03.7/libevent2-core7_2.1.12-1_mipsel_24kc.ipk

Just to confirm that there were actually some changes between those versions :smiley: I clearly could have skipped some steps, had I checked this before.