LS-WTGL no IP after reboot

[JiroMusik]

Hi there,

I am so happy I found this project since I have an old LS-W1.0TGL/R1 NAS and would love to get the latest Stretch or Buster Version running on it. So I just renamed & copied the installer files to the boot location (there was no "OK" and no "error") and then rebooted the device with "ok" After that, my device did not receive any IP, so I cant start the installer. What did I do wrong? Do I need to setup the boot mount point prior to copying files there?

[1000001101000]

Good to hear from you!

A lot of the time this happens because people accidentally download the HTML page for the installer files rather than the files themselves.

What are the file sizes of your installer files?

[JiroMusik]

Thanks for you fast reply. The files I used are initrd with 6.81MB and uimage.buffalo with 2MB. The image.buffalo is the one i renamed from buffalo..wtgl to .buffalo.

I probably have to use the TFTP option to get the device back into a working state, am I right here?

[1000001101000]

Sounds like that isn't the issue then.

You can recover with either TFTP or connecting the drives to a Linux system and loading them directly. Before you do, you might want to test with a spare drive if you have one.

Are you saying you followed this process (loading via the stock firmware)?: https://github.com/1000001101000/Debian_on_Buffalo/wiki/Preparing-Device-for-Debian-Install#option-1-load-onto-device-running-the-stock-firmware

That usually works reliably since the stock firmware already has a working /boot volume, etc.

Did you try with Stretch or Buster? The Stretch images tend to be a little smaller and might work if there's something preventing the buster installer from loading for some reason. The current image works with all the other Orion5x devices I've tested (LS-GL, LS-QL and TS2PRO). I would expect it to work for this device but I don't think that has been tested yet. Sadly, I don't have a working LS-WTGL to test with.

One thing that is worth trying is this method: https://github.com/1000001101000/Debian_on_Buffalo/wiki/Alternate-install-method-via-debootstrap-script

I made it specifically for devices that have trouble running the installer. It involves running a script that creates a pre-built disk image that you then load on a drive and boot from.

[JiroMusik]

I tried it with Stretch since in the Buster Folders there was no .wtgl file. And yes, I just copied both files with acp commander and then the reboot command. Since the reboot I dont receive any ping. Checked the DHCP too but nothing. I will try the Debootstrap Method and post here if I need some more help or got it running.

[1000001101000]

hmm, wonder why I would have that in there for stretch and not buster.

Let me know how the debootstrap process works out. If the problem is somehow related to loading the installer itself that should solve it. If not there are other things we can look into.

[JiroMusik]

I thought this will be as easy installing most other custom roms or server systems but in fact it takes so much longer. For the debootstrap you obviously need a running Linux. A live system has problems with the space (script showing errors), so I have to install another Debian on another hard drive to do the steps from the tutorial.

To be continued...

[1000001101000]

Hmm, I hadn't thought about the system requirements for running the deboostrap to be honest. By default a live system would try to generate everything in a ramdisk, but that would require a lot of ram to succeed. If it's easier, you could just format and mount a spare drive from inside the live environment and use that for where you clone/run the script. That should be faster to set up than running through a whole debian install.

This is the main advantage of running the installer on the device, that it doesn't really require anything else. I only recently added the deboostrap options because there are a few devices that physically can't handle running the installer anymore. It does offer some interesting opportunities like using hybrid partition tables and makes backup OS images easy.... but the perquisites can be a bit of a pain.

Let me know how it goes.

[JiroMusik]

It is running now, the debootstrap method worked from the live system. There were some errors while running the script but it finished 🥇 I now have the raid1 for my 3 partitions and would love to set up the next raid for my shares. Is there any nice software with a (hopefully) beautiful webpage to create the partitions, shares and stuff? I dont know if the old thing could handle a complete NAS Server solution...is there something small but modern looking? Webmin won't install because there is no release file...

Otherwise the way will be mdadm and smb right? Is there any chance for adding WOL on this device? I would love the device only to start per command or at one day a month and let my Windows make a Backup when the NAS is up and running. Then shut down NAS again. If theres no chance for WOL, Cronjobs should do the trick on both systems I think...

[1000001101000]

Nice!

I wonder if this device can't handle the size of the installer. Most older devices have a 2MB kernel limit and 7MB initrd limit for some reason, the current installer is like 6.9MB. If the limit is smaller for this model it might explain why the installer fails. There could be other reasons, maybe someday I'll get one and take a look. It's good to know the deboostrap method works in the meantime.

Some folks have used OMV and webmin for that type of set up, but I doubt either would work with this device just due to the cpu/memory requirements. I wish there was a lightweight version of something like that, but I'm not aware of one.

But yeah, mdadm and smb should get you ready to use it for backups. One other thing I'd recommend is setting up email alerts for mdadm, that way you'll get a notification if something happens to your arrays. I should probably add that to the post install options page.

I'm not familiar with this device specifically, but I haven't had any luck getting WOL working on these devices so far. Only some models have the hardware for it and the ones that I've looked at seem to lack kernel support to make it work. If the buffalo firmware supported it you could give it a try and see what happens.

[JiroMusik]

Thank you very much for your help so far. With this method I even got Debian Buster installed. Now I have the Backup running and will check the WOL / power on settings later. If WOL does not work properly, do you think rtcwake -m off -s 2629800 could do the reboot a month later?

[1000001101000]

That raises some interesting questions about this model. Could you check a few things for me?

Try rebooting the device and shutting down the device with reboot and shutdown now. I'd like to know if it successfully reboots or just shuts down.

Also, can you run dmesg | grep -i rtc and post the output?

I'm not sure if we can make the rtcwake function work or not but we might have to start by getting the rtc working if it isn't already. The LS-QL uses the rtc to signal to the bootloader to signal restart vs. shutdown, if this model does too we'll need to set that up as well.

[JiroMusik]

Yes of course. I had to put the /usr/sbin and /sbin into PATH after the installation because I could not execute any of the commands. sudo reboot is working fine, sudo shutdown now also reboots the device. Sudo halt powers it off.

sudo dmesg | grep -i rtc [ 2.730992] hctosys: unable to open rtc device (rtc0) [ 4.143149] rtc-rs5c372 0-0032: rs5c372a found, 24hr [ 4.182396] rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

[1000001101000]

interesting.

Buffalo was used a few different methods over the years to signal to the bootloader whether it should reboot or shutdown when the system stops (apparently this is difficult for embedded devices). They usually accomplish this by setting a "magic" value somewhere that the bootloader can see it. This will either be in the RTC, the ethernet chip, or a special microcontroller.

This model must default to "reboot", which is better than the alternative but I'd like to add logic to the deboostrap process to get it working properly if possible.

Could your run the following on your device and post the output?

apt-get install i2c-tools
modprobe i2c-dev
i2cdump -f -y 0 0x32

[JiroMusik]

This device has got an power switch "Off, Auto and On" It turns out I had it "ON" while using the shutdown command. I will do another shutdown with the switch on Auto now. I could also check what happens if you switch to "off".

niklas@Linkstation:~$ sudo modprobe i2c-dev

niklas@Linkstation:~$ sudo i2cdump -f -y 0 0x32

No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 53 53 53 53 XX XX XX XX 57 57 57 57 57 57 57 57 SSSSXXXXWWWWWWWW 10: 33 33 33 33 XX XX XX XX 33 33 33 33 33 33 33 33 3333XXXX33333333 20: 14 14 14 14 XX XX XX XX 14 14 14 14 14 14 14 14 ????XXXX???????? 30: 04 04 04 04 XX XX XX XX 04 04 04 04 04 04 04 04 ????XXXX???????? 40: 20 20 20 20 XX XX XX XX 20 20 20 20 20 20 20 20 XXXX 50: 08 08 08 08 XX XX XX XX 08 08 08 08 08 08 08 08 ????XXXX???????? 60: 20 20 20 20 XX XX XX XX 20 20 20 20 20 20 20 20 XXXX 70: 15 15 15 15 XX XX XX XX 15 15 15 15 15 15 15 15 ????XXXX???????? 80: 00 00 00 00 XX XX XX XX 00 00 00 00 00 00 00 00 ....XXXX........ 90: 00 00 00 00 XX XX XX XX 00 00 00 00 00 00 00 00 ....XXXX........ a0: 2a 2a 2a 2a XX XX XX XX 2a 2a 2a 2a 2a 2a 2a 2a XXXX**** b0: 3a 3a 3a 3a XX XX XX XX 3a 3a 3a 3a 3a 3a 3a 3a ::::XXXX:::::::: c0: 00 00 00 00 XX XX XX XX 00 00 00 00 00 00 00 00 ....XXXX........ d0: 2a 2a 2a 2a XX XX XX XX 2a 2a 2a 2a 2a 2a 2a 2a XXXX**** e0: 00 00 00 00 XX XX XX XX 00 00 00 00 00 00 00 00 ....XXXX........ f0: 20 20 20 20 XX XX XX XX 20 20 20 20 20 20 20 20 XXXX

[1000001101000]

Yeah, try it out with the switch too (I forgot about that).

The devices with just "on" and "off" tend to use the switch to determine shutdown vs reboot. Devices with an "auto" option usually use one of the options I mentioned above, though sometimes combined with the switch.

Try this and see if it causes a normal shutdown:

i2cset -y -f 0 0x32 0xB0 0x43
shutdown now

[JiroMusik]

This command did not help but the Switch set to Off did it. If I switch to off it doesnt shut down directly but if I use the shutdown now command it does

I hope we can find a solution for shutdown without using the switch Is the Auto position not for WOL maybe?

[1000001101000]

Generally the firmware just reads the state of the switch and uses that to decide which "magic values" to set in the RTC or one of the other methods.

Here are the values listed in the buffalo kernel source:

        #define MagicKeyReboot                  0x18
        #define MagicKeyRebootUbootPassed       0x3a
        #define MagicKeyNormalState             0x71
        #define MagicKeyHwPoff                  0x43
        #define MagicKeySwPoff                  0x02
        #define MagicKeySWPoffUbootPassed       0x5c
        #define MagicKeyFWUpdating              0x6f
        #define MagicKeyRebootReachedHalt       0x2b
        #define MagicKeySWPoffReachedHalt       0x7a
        #define MagicKeyUpsShutdown             0x21
        #define MagicKeyUpsShutdownReachedHalt  0x32

Your i2cdump output matches what I've seen on other devices where uboot sets 0xB0 to 0x3A "MagicKeyRebootUbootPassed" when it starts linux. For the LS-QL I have a script which sends 0x18 on reboot and 0x43 on shutdown which allows it to work properly.

It seems 0x43 didn't work for you, could you try 0x02?

[JiroMusik]

I tested both values with both switch positions AUTO and ON but it does come on again :(

[1000001101000]

The way most newer linkstations handle reboot is by setting the WOL interrupt which uboot can see and use to determine shutdown vs. restart. The script to handle that would have been installed by default (I think).

See if it is present in /lib/systemd/system-shutdown/

[JiroMusik]

There is a mdm script and the phy_restart:

#!/bin/bash

phytool="/usr/local/bin/phytool"

##I think only needed for dhcp leases file
mount -o remount,rw /

ifup --no-scripts --force eth0
sleep 3

$phytool write eth0/0/22 3
if [ "$1" == "halt" ] || [ "$1" == "poweroff" ]; then
    $phytool write eth0/0/16 0x0881
else
    $phytool write eth0/0/16 0x0981
fi
$phytool write eth0/0/22 0

ifdown --force eth0
mount -o remount,ro /

exit 0

[1000001101000]

The phy restart script is the WOL one I was talking about. Clearly that must not work for this model and can be removed.

You can try copying /usr/local/bin/rtc_restart.sh into that directory and see if it helps, but it just does what we tried earlier with rtcset

[JiroMusik]

I think I am starting to understand how this whole bootup process works but yeah, no shutdown with the rtc_restart script either.

[1000001101000]

There's some good info about the device here: https://web.archive.org/web/20180312180934/http://buffalo.nas-central.org/wiki/Category:LS-WTGL/R1

Here's the uboot output, it looks exactly like the LS-QL: https://web.archive.org/web/20180306180735/http://buffalo.nas-central.org/wiki/LS_DUO:_Serial_Port_Output_-_Boot-Log

I'm not sure what button it would be referring to though, you might want to try the rtc_restart with the switch set to "OFF". That might result in the desired behavior though that sounds strange. you could also try 0x5c as a shutdown code.

[JiroMusik]

Thanks for the information but I wouldnt even know where to look further into to get this solved With the Switch set to Off the device wont reboot even if I use the reboot command. I then need to manually start it again.

A smart power outlet would be the dirty solution but I would like to avoid taking this approach ..

FYI: In the manual it says the Auto Function is used in combination with the NAS Navigator Software for Windows and the device starts when the Computer is on and turns off when the Computer is turned off

[1000001101000]

What did you try with the switch set to off?

The output on that old wiki page made it look just like the LS-QL which basically sits and waits for the power button to be checked unless it receives the "magic" code to allow it to skip that and just boot.

I'm curious if this would have that effect with the switch set to off: i2cset -y -f 0 0x32 0xB0 0x43

[JiroMusik]

With the switch turned to off, it doesnt matter if I use i2cset -y -f 0 0x32 0xB0 0x43 i2cset -y -f 0 0x32 0xB0 0x5c i2cset -y -f 0 0x32 0xB0 0x02 i2cset -y -f 0 0x32 0xB0 0x18 or change it in the script you provided. It turns off completely. I tried with systemctl reboot and shutdown now.

[1000001101000]

weird.

Could you scan for other i2c devices?

modprobe i2c-dev
i2cdetect -y 0

[JiroMusik]

Could something be wrong in the boot image since I made it with Debian Buster live version?

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

[1000001101000]

No, I think everything is working just fine.

Buffalo heavily modified the Linux kernel to support these devices when they created the stock firmware. Some of the stranger things like this shutdown/reboot behavior are hard to reproduce using the modern Debian kernel. I don't think the folks that originally added support for these devices were very interested in the shutdown/restart/WOL features either. When I finally put together the "phy restart" method for the ls400 I was really surprised to find it worked for the older kirkwood devices too. I haven't been able to find any reference to it anywhere (though the main forum they worked in is no longer online). I only knew to look for the rtc method on the LS-QL because I had seen it in Buffalo's kernel source when working on the ls400 originally.

All of which is to say figuring out how these devices handle shutdown/restart requires some trial and error.

[JiroMusik]

I found someone having the same problem with some other LS device: https://lists.debian.org/debian-arm/2017/12/msg00015.html Sounds like it could really have to do with the new Debian versions...

But what could I try next ?

Maybe this could help: https://git.thm.de/mhnn55/eco32-linux-ba/commit/dc57844a736f10bf3799d63d7c0d0efc29b1ad7d

[1000001101000]

the LS-WXL shutdown/reboot works properly under Buster with my phy_restart script. That post is from before I wrote the script and well before it had been tested with that model. I'll have to see if I can post an update to that thread to let them know.

That second link is for the device-tree that you're currently using for this device (it's part of the standard linux kernel package now).

There are a few more things we can try. I'm under the impression they didn't move to the phy/WOL based approach until later devices, but it's possible they did with this one and it just works differently than the others. I have a script you can run to dump the phy registers which we could take a look at. Try running physcan.sh from the Tools directory and post the output.

If you have any experience soldering you could try adding a serial console: https://web.archive.org/web/20180426083259/http://buffalo.nas-central.org/wiki/Add_a_Serial_port_to_the_LS_DUO

we could then learn more by seeing the output form the bootloader.

You could also install the stock firmware and take a look at the console during shutdown/restart/etc and look at the output. You could even correlate those messages with the kernel source code to understand what is going on.

[JiroMusik]

Page 0
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 1
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 2
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 3
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 4
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 5
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 6
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 7
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 8
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 9
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 10
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 11
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 12
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 13
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 14
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 15
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 16
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 17
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 18
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 19
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 20
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 21
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 22
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 23
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 24
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 25
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 26
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 27
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 28
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 29
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 30
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
Page 31
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff ffff

[1000001101000]

See if your network interface is eth0 or eth1: ip addr

If it is eth1 try changing all the references in the script to eth1 and try again.

[1000001101000]

I've been looking at devices even older than this one recently and learned something new that may be relevant.

Before now the oldest devices I've worked on were the LS-GL, LS-QL and TS2PRO. All of these either use a speperate microcontroller or the i2c RTC to signal shudown/restart where most devices newer than that use the ethernet method. This led me to believe the LS-WTGL probably didn't use the ethernet method because that came later.

Today I noticed that the original PowerPC Linkstation used the ethernet method for its shutdown/reboot. This makes me think it's very likely that the LS-WTGL does too. Let me know when you get a chance to try physcan.sh with eth1 (or if you need help doing so). I'm guessing that is the answer.

[1000001101000]

...okay, I got confused about what i was looking at. most of what I said above isn't actually true. Still, it could be that we just need to add logic to the script to try either eth0 or eth1. Let me know when you have time to check on that.

[JiroMusik]

Hi I am back from vacation and have some time now for checking the script... IP a shows the device uses eth0.

Should I replace the eth0/0/22too or only the eth0/0/$i

[1000001101000]

if ip addr shows you have eth0 and not eth1 then we don't need to alter the script. If it does show eth1 then you'll want to change all instances of eth0 -> eth1.

if you do have eth0 you could try replacing eth0/0 with eth0/8 to match how the phy connects to mdio.

[JiroMusik]

phytool write eth0/8/22 $page val="$(phytool read eth0/8/$i)" phytool write eth0/8/22 0 phytool write eth0/8/22 0

these are the lines I changed and now I got this output:

Page 0 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 6060 6c48 0000 0000 0000 0000 0000 0000 0000 0000 0040 0000 0000 0000 0000 0000 Page 1 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 2 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0288 0000 0000 0008 0000 1070 0002 0000 4705 0044 0000 0000 0000 0000 0000 0000 Page 3 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 021e 4401 4105 0073 0000 0000 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 4 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0004 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 5 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 025a 8001 0280 0000 2000 0005 0603 0000 0104 0f12 0a0c 0006 0000 0000 0000 Page 6 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0006 0000 0000 0000 000d 0000 0000 0000 0000 0000 Page 7 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0007 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 8 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0008 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 9 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0009 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 10 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000a 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 11 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000b 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 12 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000c 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 13 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000d 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 14 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000e 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 15 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 000f 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 16 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0010 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 17 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0011 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 18 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0012 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 19 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0013 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 20 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0014 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 21 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0015 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 22 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0016 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 23 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0017 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 24 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0018 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 25 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 0019 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 26 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001a 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 27 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001b 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 28 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001c 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 29 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001d 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 30 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001e 0000 0000 0000 0000 0000 0000 0000 0000 0000 Page 31 1140 796d 0141 0e11 01e1 c1e1 000d 2001 6801 0200 4000 0000 0000 0000 0000 3000 0000 0000 0000 0000 0000 0000 001f 0000 0000 0000 0000 0000 0000 0000 0000 0000

[1000001101000]

Great!

Try making the same change to /usr/local/bin/phy_restart.sh

Then we can see if that changes the shutdown/restart behavior

[JiroMusik]

It seems like it changed a little bit, but it is not working as expected:

Switch to Off, Sudo Reboot Now = Tries to reboot, you can see blue led shortly, but hardware turns off, including fan Switch to Auto, Sudo Shutdown now = Reboot Switch to On, Sudo Shutdown now = Feels like shutdown but turns back on Switch to On, Sudo halt = LED turn off, fan keeps running. Only possible to restart via power connector.