On-device port exposure on SoundTouch 30 via iptables REDIRECT

[stegerj]

Hi,
I had the same port exposure issue as mentioned in #196 and #250, requiring tunneling to access the Aftertouch UI, which now includes also the Player. Apparently (according to Claude Sonnet 4.6) only a few ports are managed by the Linux System of the Soundtouch System, while the others are intercepted/handled at a lower level (DSP acting as ARP proxy intercepting all traffic on eth0).
This issue can be overcome with a redirect rule similar to the one of the HTTPS CA workaround. I tested the following rules (ST 30, on-device install, v0.112.0, cat /proc/variant: mojo):

# redirect p 8000 to 17008 (SoftwareUpdate - should be okay as I'd not expect further software updates from BOSE)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 17008 -j REDIRECT --to-port 8000

# redirect p 8000 to 8200 (STSCertified)
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8200 -j REDIRECT --to-port 8000

With this redirect one can access the Aftertouch UI with IP of the speaker e.g. http://192.168.x.x:17008.

I attempted a bit to make the TLS handshake happen connecting to the forwarded 8443 port, but even after installation of the certificate it fails.

The advantage of this approach is I can access the UI from all devices connected to WiFi the ST system is on straight away. Curious of your thoughts or any issues you might see with this approach. Eventually one could persist it adding it to an init script.

[gmuth]

• Is this a Series I ST30?
• How do you disable the process listening on port 17008?
• Why do you redirect ports instead of configuring aftertouch to use port 17008?

[stegerj]

a) yes, ST30 Series I

b) the iptables redirect works also without disabling the process listening on port 17008, the prerouting intervenes before the tcp packages reach the 17008 port

c) great suggestion! here indeed I had to kill the existing process before I was able to bind aftertouch-ser to 17008. I updated then the /etc/init.d/aftertouch to launch the daemon on port 17008 (not sure if there is a better location where to configure aftertouch to use another port than 8000). aftertouch starts before SoundTouch, therefore, on start up/reboot of the system it will bind the 17008 port before Soundtouch tries to assign it to 'SoftwareUpdate'. In order to make this a bit more graceful, one could comment the following lines of the /opt/Bose/etc/Shepherd-mojo.xml:

<daemon name="SoftwareUpdate" recovery="ignore"/>

or use the override mechanism mentioned in the /etc/init.d/Soundtouch script (create the dir /mnt/nv/shepherd, copy the /opt/Bose/etc/Shepherd-* files into that directory, and amend the /mnt/nv/shepherd/Shepherd-mojo.xml as above - when Soundtouch starts it will read from there; rollback by doing rm -rf /mnt/nv/shepherd/)

[gmuth]

The REDIRECT solution could help to solve the issue with remote port access on all series I models. We'd just have to choose one service we can disable. Did you find other potential services providing remote access? Softwareupdates still work and I would like to keep that use case. In my soundploy logs I see devices still running on older firmwares.

Or we could create a reverse proxy that would by default forward all traffic to the original process (using another internal only port) and additionaly handle requests matching paths like /aftertouch/*. This way we would keep the existing functionality. Candidates are also WebServer or pts-handler.

[Henri-be]

I tested the first command (port 17008) on my ST Portable Series I, and it works perfectly.
This lets me access the Aftertouch interfaces from my iPad without having to pull out my laptop and set up a tunnel.
Great job, Jean, and thanks for the tip!
Unfortunately, I don’t have the technical skills of the people posting here, but how can I simply set it up so that it’s active every time Speaker restarts?
Thanks for your help,
Henri

[Henri-be]

Confirming the --dport 17008 -j REDIRECT --to-port 8000 trick works well on a SoundTouch Portable 412540 Series I (taigan variant, fw 27.0.6) too — same approach as @stegerj's ST30 test, no need to kill the SoftwareUpdate process beforehand since PREROUTING intercepts before the local listener.

One caveat worth flagging for others: port 17008 is owned by SoftwareUpdate, which gets periodically respawned by Shepherd (observed PID change across sessions, e.g. 1862 → 1896). During that respawn window the redirect target briefly becomes unreliable — the AfterTouch UI on 17008 intermittently stops responding, even though the iptables rule itself stays in place.
Switched the target port to 82 (PtsServer, the "xfer" service) instead, which seems much more dormant and isn't subject to the same Shepherd restart cycle:
shiptables -t nat -A PREROUTING -i eth0 -p tcp --dport 82 -j REDIRECT --to-port 8000
Confirmed stable across a full reboot.
Full port list for the taigan variant for reference, in case it's useful for picking alternate redirect targets on other models:
82 PtsServer (xfer — chosen, stable)
8080 WebServer
8090 BoseApp (SoundTouch API)
8200 STSCertified
17000 CLIServer
17004 BoseApp
17005 BoseApp
17008 SoftwareUpdate (unstable target — periodic Shepherd restarts)
17018 LegacyProduct (untested, likely similar candidate to 82)
Persistence: same approach discussed earlier — /mnt/nv/iptables-redirect.sh + S21iptables-redirect symlinks across /etc/rc2.d–/etc/rc5.d.

(message drafted with the help of Claude, based on my own testing)

[gesellix]

An update for everyone here: this is built in now. Thanks, @stegerj, for the idea and the testing, and @gmuth and @Henri-be for trying it on more models.

Since v0.125.0, the on-device installer sets up the redirect itself, and it's re-applied every time AfterTouch starts, so it survives reboots:

• Where it applies: on speakers where :8000 isn't reachable from the LAN, it redirects port 17008 to AfterTouch. So http://<speaker-ip>:17008 opens the web UI without a tunnel.
• Setting: AFTERTOUCH_LAN_PORT in /mnt/nv/aftertouch/aftertouch.conf. auto is the default. none switches it off. A port number redirects that port instead.
• Status: /etc/init.d/aftertouch status on the speaker shows which LAN port is active.

Details are in the on-device install walkthrough and the Model Support Matrix.

@Henri-be, about your observation that 17008 was sometimes unreliable while SoftwareUpdate gets restarted: I haven't reproduced that. If you see it with the built-in redirect, you can move it to another port that nothing else on the speaker uses, with AFTERTOUCH_LAN_PORT=<port>, and restart AfterTouch.

If you set up the manual iptables scripts from this thread, remove them after updating, so the redirect isn't installed twice.

HTTPS through the redirect isn't covered; the web UI over plain HTTP is.

[Henri-be]

Hello Tobias,
I haven't encountered any specific issues with port 17008.
Congratulations on your work—enabling SSH has worked perfectly on about ten devices that I've converted to Aftertouch :)
I'm using port 82 for an app player I developed to suit my needs, and it hasn't caused any problems so far either.

[gesellix]

Thanks, @Henri-be, good to hear that SSH enabling worked on all ten, and that 17008 has been fine for you.

I corrected two things in my comment above: the settings file is /mnt/nv/aftertouch/aftertouch.conf (I had the wrong directory), and I dropped port 82 as the example, since that's where your own player lives.

[Henri-be]

Thanks for all !
My player runs on port 9000 :)

[gmuth]

I wonder if it would be possible to create a solution with full compatibility over all devices and all series (including Series I).
So for example when using 17008 for a custom service we're removing software update operations.
We could start the Software Update Process using another port internally available (e.g. 27008).
Than the custom service on port 17008 would need to http proxy (or forward) update-requests to port 27008 internally.
This would only work if the update process does not depend on HTTP HOST headers received as request.

Or we could document alternative solutions for installing firmware updates. see also

deborahgu/soundcork#203
https://github.com/gmuth/soundtouch-device-survival/blob/main/software-update/swUpdate.http