DSM-G600, DNS-3xx and NSA-220 Hack Forum

jcard · 2010-04-05 16:47:40

nogi wrote:
Just a few remarks:

I'm not yet using the "firmware" version but the "reloaded" version.

The ffp package downloads fine and is also installaed.
But every try to start one of the executables inmediately end s with a segmentation fault.

As I'm not very deep into LINUX the only thing I can see is that e.g. busybox of alt-f and busybox of ffp use completly differnt sets of libs.

...
Could this be the reason?

I don't think so, because ffp is completely "isolated" from alt-f as it's library paths are hardcoded in the binaries.
However, alt-f directories are searched first than ffp directories: try "echo $PATH".

Try using the absolute path to ffp binaries, e.g. try "/ffp/bin/sh"

nogi details: (please always state this kind of info, its very important)

ALT-F 1B1 running on my B1.

The box was running 1.08b5
After each start of alt-f it looked like the kernel was reloaded but I could not get network access.
So, I downloaded 1.09b1 and flashed it onto my box.

With this firmware version alt-f immediately started to work.

nogi · 2010-04-05 22:11:04

jcard wrote:
nogi wrote:
Just a few remarks:

I'm not yet using the "firmware" version but the "reloaded" version.

The ffp package downloads fine and is also installaed.
But every try to start one of the executables inmediately end s with a segmentation fault.

As I'm not very deep into LINUX the only thing I can see is that e.g. busybox of alt-f and busybox of ffp use completly differnt sets of libs.

...
Could this be the reason?
I don't think so, because ffp is completely "isolated" from alt-f as it's library paths are hardcoded in the binaries.
However, alt-f directories are searched first than ffp directories: try "echo $PATH".

Try using the absolute path to ffp binaries, e.g. try "/ffp/bin/sh"

nogi details: (please always state this kind of info, its very important)
ALT-F 1B1 running on my B1.

The box was running 1.08b5
After each start of alt-f it looked like the kernel was reloaded but I could not get network access.
So, I downloaded 1.09b1 and flashed it onto my box.

With this firmware version alt-f immediately started to work.

O.K. So I burned all bridges and loaded ALT-F 0.1B1 as firmware.

Box is running fine as long as I do not touch the ffp executables. It does not matter whether I use the full path or change into /ffp/bin.
Every executable seg-faults. Even "strace"

It is kind of hard to trace a segmentation fault if strace itself faults.

Unfortunately ALF does not provide strace. So I decided to download the sources and tried to build it myself.

BUT: ALT-F will not build. Make complains about "
==========================================================================
cp -dpRf package/config/buildroot-config /usr/src/altf/project_build_arm/dns323/buildroot-config
make: *** No rule to make target `/usr/src/altf/dl/aufs+sqfs4lzma-2.6.33.patch', needed by `/usr/src/altf/project_build_arm/dns323/linux-2.6.33.1/.patched'. Stop.
=========================================================================

There are a lot of references to "aufs+sqfs4lzma-2.6.33.patch" but the patch is missing.
Is it possible for you to build a strace and add it to the next version of ALT-F ?

jcard · 2010-04-06 04:34:27

nogi wrote:
O.K. So I burned all bridges and loaded ALT-F 0.1B1 as firmware.

Box is running fine as long as I do not touch the ffp executables. It does not matter whether I use the full path or change into /ffp/bin.
Every executable seg-faults. Even "strace"

Try "ldconfig /ffp/lib" (ldconfig from alt-f)
I really don't know what the problem is...

So I decided to download the sources and tried to build it myself.

BUT: ALT-F will not build. Make complains about "
==========================================================================
cp -dpRf package/config/buildroot-config /usr/src/altf/project_build_arm/dns323/buildroot-config
make: *** No rule to make target `/usr/src/altf/dl/aufs+sqfs4lzma-2.6.33.patch', needed by `/usr/src/altf/project_build_arm/dns323/linux-2.6.33.1/.patched'. Stop.
=========================================================================

There are a lot of references to "aufs+sqfs4lzma-2.6.33.patch" but the patch is missing.

Please read the HowToBuild wiki entry in http://code.google.com/p/alt-f/w/list (I know that you have already read it :-)

Have you first run the mkprepare.sh script? It should compile some needed tools, create some links, and also copy patches/aufs+sqfs4lzma-2.6.33.patch to the downloads directory (dl). If it is not there, copy it from the patches directory to the dl dir and try again.

Crap! I just checked the SVN tree and it is missing!
Please download it from the Misc page at http://sites.google.com/site/altfirmware

Is it possible for you to build a strace and add it to the next version of ALT-F ?

0.1B2 will have a ipkg based package manager, and also tools to create packages from the build tree. But it is not yet ready.

My priority now is to find a pattern and discover why there are so many "reloaded" problems.

BTW, for all those that tried and failed: after rebooting into the vendor fw, does a "alt-f" directory appears, and the Alt-F-0.1B1.tar file disappeared? The fw tar I tried (1.08) has some problems that I tried to solve using some non-orthodox methods...

PS: you can also find in the Misc page an *untested* strace. Just scp/ftp/whatever to the box.

Last edited by jcard (2010-04-06 22:02:26)

jcard · 2010-04-08 04:31:51

jcard wrote:
mushanga wrote:
For information I've tried it on a C1 hw and as for Debian, Gentoo and all no DLINK kernel, the network link does not come up on my 100M switch
So I was not able to log in anything but it has definitly booted since I was able to use the power switch 2x 3sec to properly shut it down.

Sadly I don't have any serial connection to debug further so I'm currently stuck here...
I will try to boot it directly connected to my macbook to see if the link comes up and log in.

Anyway have you any C1 to devellop?
If not I am willing to help, with the means I have.
I have a B1 board, we have to rely on someone with a rev-C1 board and a serial link to debug the problem.

As nobody shows up...

For reference, from the How to Use wiki page http://code.google.com/p/alt-f/wiki/HowToUse

So, after booting for the first time, if your box was setup with a fixed IP
in the vendors firmware, it will have the same IP as before.
If your box was using DHCP in the vendors firmware, then it might have a different
IP under Alt-F, and you must go to the DHCP server web page (usually your router)
and find the assigned client IP. Do this before trying Alt-F, to be sure that you
know how to do it.
In the "worst" scenario, the box IP will be 192.168.1.240, but this is
very unlikely.

mushanga, your C1 box has a static IP, or does it use DHCP?

If you are using DHCP in the vendor firmware, Alt-F can't guess what IP to use, and will try to use DHCP. If this is the case, have you checked your DHCP server web page (usually your router) for DHCP assigned clients IP?

If you are using DHCP in the vendor firmware, but DHCP failed for Alt-F, and there is no computer using 192.168.1.254, Alt-F will use it. If 192.168.1.254 is in use, Alt-F will try 192.168.1.253, and so on.
DHCP might fail because Alt-F waits only a few seconds for a reply.

In the event that the above holds but your network address is not 192.168.1.xx, than you need to configure a computer (laptop?) with a fixed IP, say 192.168.1.1 and use a computer to computer direct (or crossed) network cable; Alt-F IP will be 192.168.1.254.

If none of the above is true, can you please edit the fun_plug script file with a linux compatible editor (e.g. notepad++ if you are in ms-windows), and add line 69 so it becames

Code:

ps
ifconfig egiga0 down # add this line
# umount filesystems

and try again?
Thanks

nogi · 2010-04-08 08:41:18

jcard wrote:
nogi wrote:
O.K. So I burned all bridges and loaded ALT-F 0.1B1 as firmware.

Box is running fine as long as I do not touch the ffp executables. It does not matter whether I use the full path or change into /ffp/bin.
Every executable seg-faults. Even "strace"
Try "ldconfig /ffp/lib" (ldconfig from alt-f)
I really don't know what the problem is...

So I decided to download the sources and tried to build it myself.

BUT: ALT-F will not build. Make complains about "
==========================================================================
cp -dpRf package/config/buildroot-config /usr/src/altf/project_build_arm/dns323/buildroot-config
make: *** No rule to make target `/usr/src/altf/dl/aufs+sqfs4lzma-2.6.33.patch', needed by `/usr/src/altf/project_build_arm/dns323/linux-2.6.33.1/.patched'. Stop.
=========================================================================

There are a lot of references to "aufs+sqfs4lzma-2.6.33.patch" but the patch is missing.
Please read the HowToBuild wiki entry in http://code.google.com/p/alt-f/w/list (I know that you have already read it :-)

Have you first run the mkprepare.sh script? It should compile some needed tools, create some links, and also copy patches/aufs+sqfs4lzma-2.6.33.patch to the downloads directory (dl). If it is not there, copy it from the patches directory to the dl dir and try again.

Crap! I just checked the SVN tree and it is missing!
Please download it from the Misc page at http://sites.google.com/site/altfirmware

Is it possible for you to build a strace and add it to the next version of ALT-F ?
0.1B2 will have a ipkg based package manager, and also tools to create packages from the build tree. But it is not yet ready.

My priority now is to find a pattern and discover why there are so many "reloaded" problems.

BTW, for all those that tried and failed: after rebooting into the vendor fw, does a "alt-f" directory appears, and the Alt-F-0.1B1.tar file disappeared? The fw tar I tried (1.08) has some problems that I tried to solve using some non-orthodox methods...

PS: you can also find in the Misc page an *untested* strace. Just scp/ftp/whatever to the box.

Thanks for providing the strace.

I managed to change .config and compiled strace myself. Copied it to the box and it worked without problems.

During the tests I discovered that the ffp binaries are compiled as OABI whereas alt-f is compiled as EABI.
Could this be the problem?.

Unfortunately I can not check it as after changing .config to use OABI the compile /buld process ends witjh an error while building uClibc.

fonz · 2010-04-08 09:56:18

nogi wrote:
Unfortunately I can not check it as after changing .config to use OABI the compile /buld process ends witjh an error while building uClibc.

A few preliminary ffp EABI packages are here:
http://www.inreto.de/testing/ffp/0.6/ar … kages/All/

mushanga · 2010-04-08 13:33:09

jcard wrote:
mushanga, your C1 box has a static IP, or does it use DHCP?

If you are using DHCP in the vendor firmware, Alt-F can't guess what IP to use, and will try to use DHCP. If this is the case, have you checked your DHCP server web page (usually your router) for DHCP assigned clients IP?

If you are using DHCP in the vendor firmware, but DHCP failed for Alt-F, and there is no computer using 192.168.1.254, Alt-F will use it. If 192.168.1.254 is in use, Alt-F will try 192.168.1.253, and so on.
DHCP might fail because Alt-F waits only a few seconds for a reply.

In the event that the above holds but your network address is not 192.168.1.xx, than you need to configure a computer (laptop?) with a fixed IP, say 192.168.1.1 and use a computer to computer direct (or crossed) network cable; Alt-F IP will be 192.168.1.254.

If none of the above is true, can you please edit the fun_plug script file with a linux compatible editor (e.g. notepad++ if you are in ms-windows), and add line 69 so it becames
Code:
ps
ifconfig egiga0 down # add this line
# umount filesystems
and try again?
Thanks

You have to know I have problems with the net link for each kernel I reload except for the DLINK and fonz fsck ones.
Didn't think about "ifconfig egiga0 down" though, I will try that.
FYI my box use fix IP address but the dhcp server can serve it the same IP if needed.

jcard · 2010-04-08 17:50:51

nogi wrote:
During the tests I discovered that the ffp binaries are compiled as OABI whereas alt-f is compiled as EABI.
Could this be the problem?.

odd... the kernel is compiled with OABI compatibility, and I never had problems running trivial ffp apps under alt-f.

But I notice that sometimes buildroot mangles the kernel config, removing the OABI compatibility setting.

And indeed in svn/ tags/ Release-0.1B1/ local/ dns323/ linux-2.6.33.1.config
# CONFIG_OABI_COMPAT is not set

One more item to check when making releases.

Unfortunately I can not check it as after changing .config to use OABI the compile /buld process ends witjh an error while building uClibc.

Yes, that's not easy to make buildroot do what we want it to do.
Do a "make -O=... linux26-menuconfig" and set OABI compatibility. [edited]
It should be enough to re-enable ffp (and, who knows, optware dns-323 feeds) [edited]
But you should do fresh build, to not leave traces of your previous OABI configure.

Last edited by jcard (2010-04-08 18:13:30)

jcard · 2010-04-08 18:07:34

mushanga wrote:
You have to know I have problems with the net link for each kernel I reload except for the DLINK and fonz fsck ones.
Didn't think about "ifconfig egiga0 down" though, I will try that.
FYI my box use fix IP address but the dhcp server can serve it the same IP if needed.

Please tell us what your internal network IP is -- its is not a security breach to tell us that (I think)

Also, if the "ifconfig egiga0 down" does not work (it's just a blind attempt to leave the hardware in a know state before reloading), you can specify the IP you want alt-f to use.

In line 41 of fun_plug, replace

Code:

cmdline="console=ttyS0,115200"

with

Code:

cmdline="console=ttyS0,115200 ip=1.2.3.4"

using evidently the IP you want the box to use.

Thanks

nogi · 2010-04-09 02:02:47

jcard wrote:
Yes, that's not easy to make buildroot do what we want it to do.
Do a "make -O=... linux26-menuconfig" and set OABI compatibility. [edited]
It should be enough to re-enable ffp (and, who knows, optware dns-323 feeds) [edited]
But you should do fresh build, to not leave traces of your previous OABI configure.

It has been a long day so only a short message.

Building, transfering and starting the newly compiled kernel and fs worked very well.
Both types of executables are O.K.

But using "mkfw.sh" can not get a valid uboot firmware image to build.

dns323-fw is always complaining "kernel not in uboot format"

PS. Thanks for providing us with ALT-F

Last edited by nogi (2010-04-09 02:04:26)

mushanga · 2010-04-09 13:04:33

@nogi:
maybe your kernel is too big?
Else you can try to extract the uboot header from the current Alt-F firmware image and put it on your compiled zImage; I can't remember how much bytes it is though.

@jcard:
After much trial and errors I've found my problem is not Alt-F related.
It is the more generic problem with my C1 hw and 2.6.3x marvell ethernet driver under ffp reloading.
Just as with vanilla 2.6.33 Kernel I've succeeded in booting Alt-F by:
- ffp reloading after a reboot and almost all my ffp services shut (to clean memory at maximum)
- connecting the box directly to my macbook (with that it links to 1000M-FD, it never links to my 100M switch...)

I don't know if flashing would solve the problem but I cannot afford it since I have no serial connection...

jcard · 2010-04-09 17:28:05

nogi wrote:
Building, transfering and starting the newly compiled kernel and fs worked very well.
Both types of executables are O.K.

Excellent.

I don't know if you realized that you can just transfer the kernel and initramfs to the box "/root " (not "/", really "/root") directory and issue a "reboot" command.
The last thing that "reboot" does, after cleaning up things, is to verify the existence of those files and "kexec" them (not using fonz "reloaded").

Read the end of /etc/init.d/rcE

But using "mkfw.sh" can not get a valid uboot firmware image to build.

dns323-fw is always complaining "kernel not in uboot format"

nogi, I herein grant you the title of "Official Alt-F bug hunter".
You can use it in your signature or business card, if you want to :-)

The dns323-fw program can create a fw image given a kernel and initramfs when using the "-m" option (merge), or split a fw image into its components when using the "-s" option.
So, after creating the fw image using mkfw.sh, you can, in the host, verify if it is OK by calling

dns323-fw -s <fw image file>

It will output some diagnostics and create a kernel, initramfs and defaults files.
If you do it also in the target box, you should obtain the same results, since it is the same source code just compiled for a different architecture.

So, I believe that you are using a dns323-fw that was compiled from your previous OABI attempt?

Thanks for your work and reports, they have been invaluable.

jcard · 2010-04-09 17:43:07

mushanga wrote:
@nogi:
maybe your kernel is too big?

dns323-fw verifies that. But you found a weakness in mkfw.sh, as it does not verifies dns323-fw exit status. I will correct that.
You are close to an entitlement :-)

Else you can try to extract the uboot header from the current Alt-F firmware image and put it on your compiled zImage; I can't remember how much bytes it is though.

No need for that, mkfw.sh uses "mkimage", that creates the uboot header.

@jcard:
After much trial and errors I've found my problem is not Alt-F related.
It is the more generic problem with my C1 hw and 2.6.3x marvell ethernet driver under ffp reloading.
Just as with vanilla 2.6.33 Kernel I've succeeded in booting Alt-F by:
- ffp reloading after a reboot and almost all my ffp services shut (to clean memory at maximum)
- connecting the box directly to my macbook (with that it links to 1000M-FD, it never links to my 100M switch...)

Then it has to be a protocol negotiation driver problem in the C1 boards...

Alt-F has "ethertool" that can help diagnose those problems. We definitively need more users work on this issue. Anybody?

Or perhaps your mac rendezvous/avahi protocols are able to find and configure the dns323? odd...

I don't know if flashing would solve the problem but I cannot afford it since I have no serial connection...

Wise decision. Thanks.

nogi · 2010-04-09 23:47:16

jcard wrote:
nogi wrote:
Building, transfering and starting the newly compiled kernel and fs worked very well.
Both types of executables are O.K.
Excellent.

I don't know if you realized that you can just transfer the kernel and initramfs to the box "/root " (not "/", really "/root") directory and issue a "reboot" command.
The last thing that "reboot" does, after cleaning up things, is to verify the existence of those files and "kexec" them (not using fonz "reloaded").

Read the end of /etc/init.d/rcE

But using "mkfw.sh" can not get a valid uboot firmware image to build.

dns323-fw is always complaining "kernel not in uboot format"
nogi, I herein grant you the title of "Official Alt-F bug hunter".
You can use it in your signature or business card, if you want to :-)

The dns323-fw program can create a fw image given a kernel and initramfs when using the "-m" option (merge), or split a fw image into its components when using the "-s" option.
So, after creating the fw image using mkfw.sh, you can, in the host, verify if it is OK by calling

dns323-fw -s <fw image file>

It will output some diagnostics and create a kernel, initramfs and defaults files.
If you do it also in the target box, you should obtain the same results, since it is the same source code just compiled for a different architecture.

So, I believe that you are using a dns323-fw that was compiled from your previous OABI attempt?

Thanks for your work and reports, they have been invaluable.

SUCCESSSSSSSSSS!!

Have you ever tried to use the host system compiled tools on a 64bit system like OpenSuse 64 ;-)

The header definitions use long as variable size. But on a 64bit system these are 64 bit not 32 bit.
So dns323-fw did scribble all over the uboot magic numbers of the kernel
No wonder that it complained afterwards that this appeared to.be NO uboot kernel ;-)

I had to install 32bit libs and compiler in order to build a 32 bit version.

I'm not into programming myself so I do not know how to make dns323-fw.c 64bit proof.

With the 32bit executable I could proof that the kernel and the file system are O.K.
So uploaded to my DNS323 and "lo and behold" it started my first by my own compiled firmware.

It was a pleasure to help you testing and debugging "our" ;-) little baby.

jcard · 2010-04-10 18:04:47

SUCCESSSSSSSSSS!!

Have you ever tried to use the host system compiled tools on a 64bit system like OpenSuse 64 ;-)

The header definitions use long as variable size. But on a 64bit system these are 64 bit not 32 bit.
So dns323-fw did scribble all over the uboot magic numbers of the kernel
No wonder that it complained afterwards that this appeared to.be NO uboot kernel ;-)

I had to install 32bit libs and compiler in order to build a 32 bit version.

I'm not into programming myself so I do not know how to make dns323-fw.c 64bit proof.

With the 32bit executable I could proof that the kernel and the file system are O.K.
So uploaded to my DNS323 and "lo and behold" it started my first by my own compiled firmware.

Thanks, its already in the issues list.
You have not only bug-hunter but also bug-killer instincts, the 32/64 bits guess was inspiring :-)

I give up using 64 bits suse linux some years ago, because of flash, firefox plugins, java... perhaps now things are better.
And 64 bits why? its not faster, nor smaller... and I only have 2GB RAM (poor guy :-)

oxygen · 2010-04-10 19:16:53

jcard wrote:
I give up using 64 bits suse linux some years ago, because of flash, firefox plugins, java... perhaps now things are better.
And 64 bits why? its not faster, nor smaller... and I only have 2GB RAM (poor guy :-)

Depending on what kind of application you run, it is indeed faster. e.g. Image/Video editing/compressing, databases or mathematical/technical stuff (in my case matlab). In case you have 4 GB Ram or more you also get rid of the PAE overhead (often called -highmen kernel)

flash - check
firefox dunno, i dont use it
java - check

things that wont work without compat stuff: wine, skype.

mushanga · 2010-04-11 12:00:52

jcard wrote:
@jcard:
After much trial and errors I've found my problem is not Alt-F related.
It is the more generic problem with my C1 hw and 2.6.3x marvell ethernet driver under ffp reloading.
Just as with vanilla 2.6.33 Kernel I've succeeded in booting Alt-F by:
- ffp reloading after a reboot and almost all my ffp services shut (to clean memory at maximum)
- connecting the box directly to my macbook (with that it links to 1000M-FD, it never links to my 100M switch...)
Then it has to be a protocol negotiation driver problem in the C1 boards...

Alt-F has "ethertool" that can help diagnose those problems. We definitively need more users work on this issue. Anybody?

Or perhaps your mac rendezvous/avahi protocols are able to find and configure the dns323? odd...

Trying to use ethtool or miitool to force to 100M (FD or HD) or to force renegociation did not help.
The issue should either come from the marvell ethernet driver itself and/or the fact of using ffp reloading.
It doesn't come from Alt-F either, it is a Kernel/driver thing since it also happens with other 2.6.3X kernels (vanilla, gentoo, debian); see my previous posts here : http://dns323.kood.org/forum/viewtopic.php?id=5484

BTW let me thank you at least once for your hard work!

jrmymllr · 2010-04-14 04:06:42

Awesome! I've been waiting for something like this, but not being a Linux/operating system/html expert, I think I'll have to wait until it's a bit more stable. Dlink's FW has a bit too much of things I don't need, and not enough of what I want.

Alt-F looks very promising.

By the way, does this provide better logging/status than the stock firmware? For example, it always drove me nuts that the only information given about FTP is when a file transfer completely successfully. Not in progress transfers, not who is logged in, not transfer rate.

Last edited by jrmymllr (2010-04-14 21:59:03)

adhd360 · 2010-04-15 04:58:22

nogi wrote:
After fighting for two days I finally managed to get ALT-F 1B1 running on my B1.

Since I do not have a seral connection it was kind of a blind flight without instruments.

The box was running 1.08b5
After each start of alt-f it looked like the kernel was reloaded but I could not get network access.
So, I downloaded 1.09b1 and flashed it onto my box.

With this firmware version alt-f immediately started to work.

Just a few remarks:

In order to make the created "reload.sh" work I had to add a few "\" to the fun_plug script e.g.
==================================
for i in \$proc; do
if test -n "\$(pidof \$i)"; then
kill \$(pidof \$i)
sleep 1
if test -n "\$(pidof \$i)"; then
kill -9 \$(pidof \$i)
fi
fi
done
==================================

Without these you end up with empty variables in the reload.sh script.

Nogi,

is there anything else you did?

after the archive is extracted/deleted i lose power button/SSH/telnet (although i can still ping via router or crossover).

i have:
rev-B1 board
1.09b fw
1tb WD10EACS
fun_plug from http://sites.google.com/site/altfirmware/home/misc (as "alt-f.sh")
~8200 free memory @ reboot (no packages besides ffp-base).

nogi · 2010-04-15 08:48:29

adhd360 wrote:
nogi wrote:
After fighting for two days I finally managed to get ALT-F 1B1 running on my B1.

Without these you end up with empty variables in the reload.sh script.
Nogi,

is there anything else you did?

after the archive is extracted/deleted i lose power button/SSH/telnet (although i can still ping via router or crossover).

i have:
rev-B1 board
1.09b fw
1tb WD10EACS
fun_plug from http://sites.google.com/site/altfirmware/home/misc (as "alt-f.sh")
~8200 free memory @ reboot (no packages besides ffp-base).

I have to admit: Yes, I did a few more things.

First, I killed all ffp processes manually except the ssh process I was logged on with.

Second, I did a few more changes to the "alt-f.sh" script.

I'm attaching the whole diff, against the new fun_plug from jcard. So be careful not to delete the improvements.

Code:

--- fun_plug_new        2010-04-15 07:04:05.000000000 +0200
+++ fun_plug.altf       2010-04-15 07:19:55.000000000 +0200
@@ -9,6 +9,7 @@
 ALTF_DIR=alt-f
 ALTF_PATH=$BASE_DIR/alt-f
 ALTF_TARBALL=$BASE_DIR/Alt-F-*.tar
+ALTF_SCRIPT_NAME=`basename $0`

 check() {
        if ! test -r $1; then
@@ -17,24 +18,21 @@
        fi
 }

-check $BASE_DIR
 cd $BASE_DIR

 if test -r $ALTF_TARBALL; then
-       # tar xzf $ALTF_TARBALL
+    # tar xzf $ALTF_TARBALL
        # what the heck?! -x doesn't work, but -v does, so extract to stdout!
        mkdir $ALTF_PATH
-       check $ALTF_PATH
        for i in $(tar -tf $ALTF_TARBALL); do
                if ! test -d $i; then
                        tar -xOf $ALTF_TARBALL $i > $i
                fi
        done
-       rm $ALTF_TARBALL
+    rm $ALTF_TARBALL
        chown -R nobody:nobody alt-f
 fi

-check $ALTF_PATH
 cd $ALTF_PATH

 KV=$(uname -r)
@@ -49,30 +47,29 @@

 cat<<EOF > $TMP_DIR/reload.sh

-# disable recurring reboots
-if test "$ONCE" = yes; then
-       chmod -x $BASE_DIR/fun_plug
+# disable recurring rebootsi
+# echo "$ALTF_SCRIPT_NAME"xx$0yy
+if test "$ALTF_SCRIPT_NAME" = "fun_plug"; then
+       if test "$ONCE" = yes; then
+               chmod -x $BASE_DIR/$ALTF_SCRIPT_NAME
+       fi
 fi

 # stop processes
 smb stop
-proc="apkg atd crond wget smbclient pure-ftpd prescan upnp \
-       mt-daapd lpd inotify_itune inotify_upnp btdog bt \
-       inotifybt UpdateDB check_hotplug xmldb webs"
+proc="apkg atd crond wget smbclient pure-ftpd prescan upnp mt-daapd lpd inotify_itune inotify_upnp btdog bt inotifybt UpdateDB check_hotplug xmldb webs"

 for i in \$proc; do
        if test -n "\$(pidof \$i)"; then
-               kill -15 \$(pidof \$i)
-               sleep 3
+               kill \$(pidof \$i)
+               sleep 1
                if test -n "\$(pidof \$i)"; then
                        kill -9 \$(pidof \$i)
                fi
        fi
 done
-
-# try to solve network problems in rev-C1 boards
-ifconfig egiga0 down
 sleep 3
+ps

 # umount filesystems
 swapoff -a
@@ -84,6 +81,8 @@
 insmod reloaded-$KV.ko machtype=$machtype kernel=$kernel initrd=$initrd cmdline=\"$cmdline\"
 echo "Reload failed!"
 EOF
+echo "here we are"
+cp $TMP_DIR/reload.sh /mnt/HD_a2/reload.log

 chmod +x $TMP_DIR/reload.sh
 exec $TMP_DIR/reload.sh >/dev/console 2>&1 </dev/null

The changes are mainly to keep a copy of the reload script on disk as /tmp will be re-created on every boot.
The other "main" change is to avoid deleting the execution rights of "fun_plug" if it is not the ALT-F fun-plug.

Hope this helps.

adhd360 · 2010-04-15 08:54:29

Thanks for the quick reply!

Will test shortly, and report back.

jcard · 2010-04-15 16:15:48

adhd360 wrote:
Thanks for the quick reply!

Will test shortly, and report back.

you migh try also to specify the current box ip, see
http://dns323.kood.org/forum/viewtopic. … 837#p35837

I will start fixing the fun_plug ("reloaded") issue next monday, but I need feedback from you all, as obviously it worked for me.

Thanks.

DSM-G600, DNS-3xx and NSA-220 Hack Forum

Announcement

#26 2010-04-05 16:47:40

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#27 2010-04-05 22:11:04

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

nogi wrote:

#28 2010-04-06 04:34:27

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#29 2010-04-08 04:31:51

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

mushanga wrote:

Code:

#30 2010-04-08 08:41:18

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

nogi wrote:

#31 2010-04-08 09:56:18

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#32 2010-04-08 13:33:09

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

Code:

#33 2010-04-08 17:50:51

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#34 2010-04-08 18:07:34

Re: Announce: Alt-F, an alternative firmware for the DNS-323

mushanga wrote:

Code:

Code:

#35 2010-04-09 02:02:47

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

#36 2010-04-09 13:04:33

Re: Announce: Alt-F, an alternative firmware for the DNS-323

#37 2010-04-09 17:28:05

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#38 2010-04-09 17:43:07

Re: Announce: Alt-F, an alternative firmware for the DNS-323

mushanga wrote:

#39 2010-04-09 23:47:16

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

nogi wrote:

#40 2010-04-10 18:04:47

Re: Announce: Alt-F, an alternative firmware for the DNS-323

#41 2010-04-10 19:16:53

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

#42 2010-04-11 12:00:52

Re: Announce: Alt-F, an alternative firmware for the DNS-323

jcard wrote:

#43 2010-04-14 04:06:42

Re: Announce: Alt-F, an alternative firmware for the DNS-323

#44 2010-04-15 04:58:22

Re: Announce: Alt-F, an alternative firmware for the DNS-323

nogi wrote:

#45 2010-04-15 08:48:29

Re: Announce: Alt-F, an alternative firmware for the DNS-323

adhd360 wrote:

nogi wrote:

Code:

#46 2010-04-15 08:54:29

Re: Announce: Alt-F, an alternative firmware for the DNS-323

#47 2010-04-15 16:15:48

Re: Announce: Alt-F, an alternative firmware for the DNS-323

adhd360 wrote:

Board footer