OpenWrt Based TalkTalk Sagemcom FAST 5364 Tinkering

I haven't seen a lot of resources on the TalkTalk provided Sagemcom FAST 5364 so wanted to share a few collated findings from around the web in case it's useful to anyone. Thanks to all the work on similar devices that helped me get this far!

SSH Access is possible by enabling remote access on the default Admin account through a JavaScript developer console once logged in to the web interface:

$.xmo.setValuesTree(true,"Device/UserAccounts/Users/User[@uid=3]/RemoteAccesses/RemoteAccess[@uid=3]/Enabled")

Then SSH as admin with your password. Then use the login command with username root and password root for complete access.

The Sagemcom default SG4K10001400t firmware seems 'inspired by' an old OpenWrt build.

cat /proc/version
Linux version 3.4.11-rt19 (g361146@compil-atr-1) (gcc version 4.6.2 (GCC) ) #1 SMP PREEMPT Fri Mar 16 20:29:03 CET 2018
cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
processor       : 0
BogoMIPS        : 1990.65

processor       : 1
BogoMIPS        : 1990.65

Features        : swp half thumb fastmult edsp tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : BCM963138
Revision        : 0000
Serial          : 0000000000000000

xmo-client is the main interface to the configuration XML and can be used to disable subsequent updates:

xmo-client -p "Device\ManagementServer\URL" -s ""
xmo-client -p "Device\ManagementServer\TR69InternalData\Settings\Port" -s 0

Or re-enable:

xmo-client -p "Device\ManagementServer\URL" -s "https://acs.talktalk.co.uk:7443/ACS-server/ACS"
xmo-client -p "Device\ManagementServer\TR69InternalData\Settings\Port" -s 7547

Firmware can be read out of mtd10 and saved to a file that can be uploaded using the web interface:
dd if=/dev/mtd10 of=/root/tmp/SG4K10002808t.gsdf

Using the router as a pure VDSL bridge is possible but clunky using the following commands in a startup script:

rmmod hard_watchdog
killall hg6d
killall dhclient
killall dhcpd
brctl addif BR_LAN ptm0.101
ifconfig ptm0.101 0.0.0.0

The public WAN IP is then exposed via DHCP on the local interfaces.

The static ARM binaries at https://github.com/therealsaumil/static-arm-bins/ are useful for further investigations. curl can be used to transfer files to the router and a symlink to the web interface a quick way of getting files off:

ln -s /root/tmp /usr/share/gui-core/www/gui/tmp

Then download via http://192.168.1.1/0.1/gui/tmp/filename

I'm not sure if a clean build of OpenWrt is feasible for this model as the VDSL binaries are unlikely to port across I guess? I'd value other opinions to see if custom firmware is possible at all?

3 Likes

Hi David,
Tried this with no success on my F@ST 5364 software version SG4K10002808t. Seems TalkTalk may have updated the firmware to disallow XMO commands at user level because attempting $.xmo.getValuesTree("Device/UserAccounts/Users/User[@uid=2]"); simply doesn't work anymore. Can you confirm if your device is on this firmware please?

Regards,
Darren

Hey Darren,

I think you're correct, differencing 2808t with 2600t shows they've attempted to stop these parameters being changed in the config XML. However, you can downgrade back to 2600, make the change to get remote access and then go back to 2808 via the firmware upgrade page. I tested this after a pinhole reset and all looks good!

Downgraded firmware, enabled logon and was able to create static route through the GUI. However, for some reason the route randomly gets deleted from the router. Is there a way to make the route persist? Do I need to disable the xmo-client updates?

My test routes seem to stay put on the original SG4K10001400t version, what were you trying to add? You should only need to disable the remote management to stop future updates and monitoring from TalkTalk. Might also be worth checking /var/log/messages around the time the routes go missing?

Gents

I read your thread on tinkering with the Sagem 5364 with interest as I have this unit and am interested in running it in bridge mode in order to avoid a double NAT with my DSL-AC68U.

I am very new to this but keen to learn and so apologise in advance if some of the below appears very naïve. I would be very grateful if you could cast your eye over it and comment if there are errors in my intended actions.

I have already enabled remote access and am able to login as root using username: root & password: root

So my intentions are as follows (using PuTTY):

SSH as admin using my username & password then type:

Login

Enter root as user and password and once in type:

Vi setbridgemode.sh (to create the file setbridgemode.sh)

a (to enter text mode)

rmmod hard_watchdog

killall hg6d

killall dhclient

killall dhcpd

brctl addif BR_LAN ptm0.101

ifconfig ptm0.101 0.0.0.0

Hit ESC & type

:w /etc/init.d/setbridgemode.sh (to save the file setbridgemode.sh in /etc/init.d)

chmod +x /etc/init.d/setbridgemode.sh (to make the file executable)

Close out and reboot. Then on restart the Sagem should be in bridge mode.

I assume future firmware updates will delete this script so I either need to disable future updates by typing your commands:

xmo-client -p "Device\ManagementServer\URL" -s ""

xmo-client -p "Device\ManagementServer\TR69InternalData\Settings\Port" -s 0

Or leave updates enabled and re-create the script after a firmware update.

I am currently on firmware 2600t.

Finally I appreciate this is all done at my own risk.

Many thanks

Cliff

Hi Cliff,

I've been pondering this and now realise that killing hg6d on startup is potentially a little risky as it could block the reset button working properly in case you get in to trouble!

So, I've been experimenting with creating a proper bridge using the configuration file, that way the bridge is automatically created on startup - no scripts required.

This is all a little experimental (so definitely at your own risk) but, assuming you are on Fibre, you can try the following once SSH'd as root. This will setup a bridge on the first Ethernet port - so don't use that port to run these commands from!

xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=1]/Ports/Port[@uid=2]/Enable" -s "false"
xmo-client -p "Device/Bridging/Bridges" -a
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports" -a
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports" -a
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports" -a
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Enable" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=1]/Enable" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=1]/ManagementPort" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=2]/Enable" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=3]/Enable" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=2]/LowerLayers" -s "Device/Ethernet/Interfaces/Interface[PHY1]"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]/Ports/Port[@uid=3]/LowerLayers" -s "Device/Ethernet/VLANTerminations/VLANTermination[VLAN_DATA]"
xmo-client -p "Device/IP/Interfaces/Interface[@uid=2]/IPv4Addresses/IPv4Address[@uid=1]/Enable" -s "false"

Then restart to check all is well.

Let us know how you get on!

Hey David

Many thanks for this. I'll give a go at the weekend when I have a little more time and let you know how I get on.

One question if I may (and apologies if it's again naive) but the 4rd, 4th and 5th line are identical.

Is that correct?

Many thanks

Cliff

Mine's been acting as a bridged modem all week and so far so good!

Yes, you need to add three virtual ports to the bridge so that line is repeated.

So yes it did show my lack of knowledge; I've so much to learn.

Thank you so much for the guidance, i'll give this a go across the weekend.

Cliff

I successfully downgraded firmware to enable ssh access and then upgraded.

After logging in as root, I seem to get errors with the xmo-client commands:

root@ttrouter:~# xmo-client -p "Device\ManagementServer\URL" -s ""
error: xpath: Device\ManagementServer\URL
error: XMO_PARAMETER_ERR
>
root@ttrouter:~# xmo-client -p "Device\ManagementServer\TR69InternalData\Settings\Port" -s 0
error: xpath: Device\ManagementServer\TR69InternalData\Settings\Port
error: XMO_PARAMETER_ERR

More info:

root@ttrouter:~# cat /proc/version
Linux version 3.4.11-rt19 (g361295@compil-atr-1) (gcc version 4.6.2 (GCC) ) #3 SMP PREEMPT Fri Jul 19 17:08:21 CEST 2019
root@ttrouter:~# cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
processor       : 0
BogoMIPS        : 1990.65

processor       : 1
BogoMIPS        : 1990.65

Features        : swp half thumb fastmult edsp tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x4
CPU part        : 0xc09
CPU revision    : 1

Hardware        : BCM963138
Revision        : 0000
Serial          : 0000000000000000

Any idea what the issue might be?

EDIT: turns out it was the slashes. The following commands work:

xmo-client -p "Device/ManagementServer/URL" -s ""
xmo-client -p "Device/ManagementServer/TR69InternalData/Settings/Port" -s 0

Sorry, yes slashes were wrong in the first post! Glad you're up and running.

Many thanks for sharing these instructions David. Is the best way to rollback the bridge to press the reset pin? Just asking in case I run into any issues.

The simplest way is to push the reset pin, this will remove the SSH access too of course. Off the top of my head, you could try the opposite commands to return to the usual NAT mode:

xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=3]" -d
xmo-client -p "Device/IP/Interfaces/Interface[@uid=2]/IPv4Addresses/IPv4Address[@uid=1]/Enable" -s "true"
xmo-client -p "Device/Bridging/Bridges/Bridge[@uid=1]/Ports/Port[@uid=2]/Enable" -s "true"

@DavidBrent
So im coming to the end of my contract and was wondering have you messed about with setting one of the port to a WAN DHCP and then bridge both Wireless and LAN interfaces?

I know downgrade back to 2600 would be a start to enable SSH

I think there’s a DHCP WAN port already configured as eth0 or Device/Ethernet/Interfaces/Interface[PHY6_WAN]. The xmo-client Bridges tree seems pretty flexible in creating whatever you want, here’s a few tips I learned along the way:

  • Use brctl show to validate that your bridge is setup correctly.
  • Bridges are only populated when the port is up.
  • A port should be disabled from a previous bridge before adding it to another.
  • The first virtual port in the bridge tree is set as the ManagementPort and automatically populates the LowerLayers.
  • Otherwise you can add in the LowerLayers you’d like as the second, third, etc. ports.

So all in all, it’s seems possible to bridge anything to anything!

1 Like

its work for me thanks

A post was split to a new topic: Unbrick FAST 5280

Hi @DavidBrent, thanks for this.

I logged in, opened the developer console, and ran the command "$.xmo.setValuesTree(true,"Device/UserAccounts/Users/User[@uid=3]/RemoteAccesses/RemoteAccess[@uid=3]/Enabled")"
But it returns error >"XMO setValue request error: xmo.js? numbersandlettershere "Undefined (XMO_REQUEST_ACTION_ERR)" (16777236)"

The firmware version is the default one, SG4K10001400t, but I have no broadband set up yet as the engineer hasn't arrived.

I am also rather confused as I contracted faster fibre (which I believe must be VDSL, not fibre (unless the engineer comes and literally installs it, which I doubt).

Also, is there a way to connect before the going live date? We have no internet at the moment and only 4G.

I hope you are all staying safe, cheers OpenWRT gurus !

Hey there!

I've just re-tested on 1400t and that command definitely works for me. It won't on 2808t and above though which will be automatically pushed around 2am after you go live. Have you tested with another browser or after a pinhole reset on the back? Feel free to PM me a screenshot if you are still stuck.

If you've ordered Fibre To The Cabinet (FTTC) there is no engineer visit as the final delivery is over your existing copper wiring. Sadly you can't do much until go live, although sometimes this happens earlier than TalkTalk predict.

As an update, I now use my FAST 5364 purely as a bridged modem with a better separate router. It works flawlessly using the bridge commands above. Not quite the OpenWrt dream installation but a better setup than double NAT for sure.

Happy tinkering during lockdown!

1 Like