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

jcard wrote:

What's new:

-NFS setup web page done.
-Native package manager based on ipkg, and administering web page.
-Added a temporary and experimental package feed with some packages
available (some of them were not even tested)
-Fixed fun_plug

http://code.google.com/p/alt-f/
http://sites.google.com/site/altfirmware/
http://groups.google.com/group/alt-f

Looks good so far.

I could build a new ALT-F set but I do not dare to load it yet.
As I have alt-f 1B1 running I can not use the "reloaded" version because the FONZ reloaded tools are for
the 2.6.12 kernel which DLINK uses.

Because of  my very limited knowledge I was not able to create a reload module suitable for the running 2.6.30 kernel.

Anybody out there who is able to help?

jcard wrote:

nogi wrote:

Anybody out there who is able to help?

Under Alt-F you must use kexec, not "reloaded". kexec is already builtin Alt-F.

Just put your zImage and initramfs in directory "/root" (not "/" ) and issue a reboot command. This procedure does an ordered system shutdown and, instead of rebooting or shutting down the system it reloads the new kernel/initramfs.
For details, take a look at the end of /etc/init.d/rcE

I should have known that you already provided a way to test the new images.

Will report back as soon as I have tested it.

BTW. Thanks for the fast reply

lucien wrote:

Hello

Is Alt-F work in standard mode?

Thank in advance.

I'm afraid that I don't understand what you mean. Can you elaborate?

[Lucien, je ne comprends pas ce que vous voulez dire. Pouvez-vous préciser?]

Last edited by jcard (2010-05-01 21:21:26)

lucien wrote:

Bonjour

(et merci pour le français;-)

Mon DNS323 est en mode standard avec 2 disques (HD_a2 et HD_b2). Il me semble avoir vu que Alt-f 01b2 fonctionnait  en mode  Raid 0/1/5, Job mais je n'ai pas vu de mode standard, voici la raison de ma question (un peu stupide peut etre ;-). J'ai lancé avec le fun_plug (Alt-f.sh renomé en fun_plug) et Alt-F-0.1B2.tar (chmod +x fun_plug), il me créé bien le Rep Alt-f il ce lance a priori (led start clignotant pendant 1min puis stable) mais pas d'interface et pas de ping (ni par 192.168.0.32 ni par l'ip fourni pas dhcp). L'ip est par defaut en dhcp (ip fixé par le routeur suivant adresse mac). j'ai du loupé quelque chose (je doit etre une brelle;-).

Merci pour les reponces.
PS: tres bonne idée ce firmware alternatif et bon courrage.

Lucien essentially asks if Alt-F only runs disks in RAID mode or also in standard mode; he also says that he wasn't able to use Alt-F -- after an apparently successful loading (the power led flashes during a minute and then stays steady) he wasn't able to communicate with it. He uses DHCP and his previous box IP was 192.168.0.32.

-Alt-F runs in both standard and RAID mode, it just uses the disks as it founds then -- not touching them in any way other than mounting them (RAID partitions created by the vendor's firmware are not even mounted).

-As for the loading question: It's really a pity (in my humble and biased opinion :-) that loading Alt-F is a problem for so many, as I believe that it's a good starting point for an alternative firmware.
Obviously it works for me, although I must admit that I didn't test the fun_plug script invoking it directly under ffp.
The script has obviously a flaw that I don't see, can anyone help? A "nohup" instead of an "exec" for ffp users?

Lucien, can you tell us what hardware version your box is? A1, B1 or C1? And what firmware version are you using?

As for the IP, the new fun_plug uses the IP assigned to the box, so if you were using 192.168.0.32 it will use that.

I enclose a slighly modified fun_plug that saves in the alt-f directory a copy of the real reload script, "reload.sh". This test script does not tries to load Alt-F, so after invoking it please post the reload.sh file that you can find in the alt-f directory.

[Lucien, j'espere que vous comprenez bien l'anglais, parce que mon français est trés faible -- mais vou pouvez reprondre en français]

---

Attachments:
fun_plug, Size: 2,453 bytes, Downloads: 612

lucien wrote:

Hello

Thank for the answer. The revision of my dns is B1 and i've the 1.09B1 firmware.

Thank for all.

Thanks lucien,

According to the script output (look at its end), your box IP is currently 192.168.0.171 so you should point your web browser to http://192.168.0.171 after the reloading.

I enclose another fun_plug script. As the previous one it will save the real reload script into the alt-f directory, and will print your current IP address in the console 5 seconds before doing the reload.

If it does not succeed, can you try another thing, just to be sure that Alt-F is actually running?
Can you please press and keep pressing the front power button for some 3 to 5 seconds? The right led should start flashing, and if you release it while it is flashing the box should perform a reboot.

Thanks,

---

Attachments:
fun_plug, Size: 2,555 bytes, Downloads: 556

I have flash my dns firmware in 1.08 and i have stop and delete all add on.

3 minutes after boot the flashing power button is is irregularly and right disk have continous acces.
I pressed the button for 4 seconds and nothing happened.


Thank and good night.

Last edited by lucien (2010-05-03 02:30:05)

nogi wrote:

Hello,
It's me again with a success story:

We are getting used :-)

I reloaded DLINK's 1.09B1 onto my box in order to test the reloading process again.

You mean flashed, not reloaded, right?

It would be interesting to be able to reload (kexec, as a matter of fact) the vendors firmware.

I tried it briefly but failed. I guess that one has to mangle the kernel image with devio in order to pass the correct "cpuid" to the kernel. Similar to what mkfw.sh already does, but in the reverse way, as the vendors kernel expects a wrong cpuid.

Then I tried the hard stuff ;-)

I removed the first line from the start script

You mean the script that fun_plug creates, /tmp/reload.sh, right?

---> #/bin/sh
which starts a shell by its own and started the script as a sub-shell of the running (telnet) shell.

-- > . ./fun_plug.altf
This line reads <DOT><BLANK><DOT><SLASH>[name of the start script]

Perhaps you could post a diff? Or the whole new script?

And in what directory were you "sitting"?

The last line from fun_plug, "exec", does a similar thing to "sourcing", ".", but replaces the current script (fun_plug) with the new one (reload.sh), not creating a new process.

Reloading Alt-F using ffp should be fairly simple (so I didn't try it :-()
Take a look at reload.sh from fonz ffp-reloaded-0.5-2.tgz

Basically create a script that kills all processes except the invoking one (killall5), turns swap off, umount or remount read-only all partitions, and then does a reload.

That script should be invoked from the command line with "nohup", such that the script continues executing when killall5 kills the telnet or ssh process that you use to login.

killing all processes is "only" needed to release memory and make it available to the reload process.
If you are using an old disk, small and without valuable data, you can even skip the umount filesystems step (after all the vendors firmware doesn't do an umount at shutdown!!!). And if you are on a serial line you can even execute the reload command directly, typing it at the command line (this last one is speculation).

Until 0.1B3 (within 2 weeks, I hope) I will not reflash my box again, so unless someone gives me a clue :-O on how to kexec the vendors firmware, I will not debug the fun_plug script.

Thanks again, nogi. No further issues compiling 0.1B2?

Last edited by jcard (2010-05-07 05:49:37)

nogi wrote:

jcard wrote:

nogi wrote:

Hello,
It's me again with a success story:

We are getting used :-)

I reloaded DLINK's 1.09B1 onto my box in order to test the reloading process again.

You mean flashed, not reloaded, right?

It would be interesting to be able to reload (kexec, as a matter of fact) the vendors firmware.

I tried it briefly but failed. I guess that one has to mangle the kernel image with devio in order to pass the correct "cpuid" to the kernel. Similar to what mkfw.sh already does, but in the reverse way, as the vendors kernel expects a wrong cpuid.

Then I tried the hard stuff ;-)

I removed the first line from the start script

You mean the script that fun_plug creates, /tmp/reload.sh, right?

---> #/bin/sh
which starts a shell by its own and started the script as a sub-shell of the running (telnet) shell.

-- > . ./fun_plug.altf
This line reads <DOT><BLANK><DOT><SLASH>[name of the start script]

Perhaps you could post a diff? Or the whole new script?

And in what directory were you "sitting"?

The last line from fun_plug, "exec", does a similar thing to "sourcing", ".", but replaces the current script (fun_plug) with the new one (reload.sh), not creating a new process.

Reloading Alt-F using ffp should be fairly simple (so I didn't try it :-()
Take a look at reload.sh from fonz ffp-reloaded-0.5-2.tgz

Basically create a script that kills all processes except the invoking one (killall5), turns swap off, umount or remount read-only all partitions, and then does a reload.

That script should be invoked from the command line with "nohup", such that the script continues executing when killall5 kills the telnet or ssh process that you use to login.

killing all processes is "only" needed to release memory and make it available to the reload process.
If you are using an old disk, small and without valuable data, you can even skip the umount filesystems step (after all the vendors firmware doesn't do an umount at shutdown!!!). And if you are on a serial line you can even execute the reload command directly, typing it at the command line (this last one is speculation).

Until 0.1B3 (within 2 weeks, I hope) I will not reflash my box again, so unless someone gives me a clue :-O on how to kexec the vendors firmware, I will not debug the fun_plug script.

Thanks again, nogi. No further issues compiling 0.1B2?

Just two lines before I have to go off to work:

Yes. I flashed the DLINK 1.09b1.

It usually rename your fun_plug script to fun_plug.altf .So it was this one, which creates the reload.sh.

Will report and post a diff during the weekend.

O.K. Here we go. I downloaded your latest fun_plug, changed it, tested it (with success of course :-) )
And in addition I attached the tree logs which my version of the script creates. 

--- fun_plug.jcard      2010-05-08 11:31:02.000000000 +0200
+++ fun_plug.nogi       2010-05-10 00:13:15.000000000 +0200
@@ -1,4 +1,4 @@
-#!/bin/sh
+#####n#!/bin/sh

 # disable recurring reboots,
 # comment if you want to go to Alt-F on every reboot
@@ -13,6 +13,7 @@
 ALTF_DIR=alt-f
 ALTF_PATH=$BASE_DIR/alt-f
 ALTF_TARBALL=$BASE_DIR/Alt-F-*.tar
+ALTF_SCRIPT_NAME=`basename $0`
 FFPRC=/ffp/etc/rc

 check() {
@@ -63,12 +64,20 @@
 fi

 cat<<EOF > $TMP_DIR/reload.sh
-#!/bin/sh
+#####!/bin/sh

 # disable recurring reboots
-if test "$ONCE" = yes; then
-       chmod -x $BASE_DIR/fun_plug
+# avoid revoking executable rights our if own name is NOT "fun_plug"
+# 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
+# Let's record memory use and processes before we try to clean up
+ps ax > $BASE_DIR/altf_pre_reload.log
+echo "" >> $BASE_DIR/altf_pre_reload.log
+free >> $BASE_DIR/altf_pre_reload.log

 # stop ffp services
 if test -f $FFPRC; then
@@ -99,6 +108,11 @@
 # try to solve usb problems when reloading
 rmmod usblp

+# Now let's see what we have after clean-up
+ps ax > $BASE_DIR/altf_post_reload.log
+echo "" >> $BASE_DIR/altf_post_reload.log
+free >> $BASE_DIR/altf_post_reload.log
+
 sleep 3
 ps

@@ -114,7 +128,7 @@
 EOF

 # save a copy of the real reload script
-cp $TMP_DIR/reload.sh $ALTF_PATH/reload.sh
+cp $TMP_DIR/reload.sh $BASE_DIR/reload.log

 if test -f $FFPRC; then
        echo "Your box IP will be $ip. Use http://$ip in your browser to access it."

Just for the record: I do use and old 80GB Sata Disk for my tests. I would not dare to (miss)treat a production system in such a way.

Eagerly awaiting ALT-F-01.B3

---

Attachments:
scriptsNlogs.tar.gz, Size: 2,855 bytes, Downloads: 513

lucien wrote:

hello

I used the last fun_plug.altf.
The Alt-f firmware launches but the giga0 interface does not start (ethernet LED extinct), when I push the start button five second, the LED will turn red and the dns restart.

I still have no series to see what's happening in startup.

thank.

Bonjour Lucien,


Si tu veux tu peux repondre en Franc;ais.

Please download the attached filefrom my last posting and use this "fun_plug.nogi" instead of the file which came with ALT-F 0.1Bx.
Do not forget to start it with ". ./fun_plug.nogi" like I wrote a few postings before.

If your box does not start get the post* and pre* files and upload these files.

As a side note: The network led will only light up if a network access occurs.

lucien wrote:

Bonjour Nogi

J'ai donc essayé avec le ". ./fun_plug.nogi". A priori le firmware alt-f ce charge (si je presse le bouton de démarrage du boitier pendant 3 seconde la led du disque clignote rouge et le boitier redémarre ), par contre je n'ai pas d'accès en ethernet (ping ou interface de gestion) avec l'ip 192.168.0.171 (adresse ip de mon dns), le voyant réseau ne s'allume pas du tout.

ci joint les fichiers post et pre

Je n'ai toujours pas reçus mon interface rs232 pour voir ce qu'il ce passe.

Merci pour l'aide

De rien.

The logs you attached look good so far. There is enough memory to start ALT-F.
Unfortunately one can not see what network address the system uses.

But I think I found a way to create another log file without changing ALT-F.

ALT-F calls during start-up as last action ""//ffp/etc/rc" in order to start the ffp programs.

I added a few commands to this file which create a "HereWeGo.log" in /mnt/HD_a2 or /mnt/sda2 repective.

You can save /ffp/etc/rc and copy the attached "rc" file as /ffp/etc/rc.
Make sure that the newly copied file is executable.

Than try to run fun_plug.nogi again.

After the reboot you should find in /mnt/HD_a2 a File "HereWeGo.log which should contain the logs
of both boot atempts.

This should at least show what is going wrong during the first boot (of ALT_F).
If the log only contains the boot of DLINK 1.0xx this will tell us that ALT_F did not manage to get that far.

---

Attachments:
ffprc.tar.gz, Size: 5,559 bytes, Downloads: 541

lucien wrote:

Bonjour

J'ai fini par me faire une interface avec un max3233. donc Alt-f boot sans problème
mais je n'ai pas d'interface sous firefox avec l'adresse 192.168.0.171, pas de réponce au ping non plus.
si je ping du dns via la console série, le led réseau du boitier clignote mais tout les paquets sont perdu.

ci joint le log du boot de alt-f et le fichier herewego.log.



cordialement.

Bonjour,

Now that you have a serial connection we're getting closer.

If the network LED lights up during outgoing pings at least the network layer in the kernel is working so far.

While ping-ing does the LED on the receiving part (router?) also light up?
If you do an  ifconfig afterwards is TX-counter also going up?

Which addresses are you pinging, both your computer and the gateway (router)?

what output do you get from

arp -an
ethtool eth0
???



Is the gateway and net-mask on your computer the same as on the DNS323?

nogi wrote:

lucien wrote:

Bonjour

J'ai fini par me faire une interface avec un max3233. donc Alt-f boot sans problème
mais je n'ai pas d'interface sous firefox avec l'adresse 192.168.0.171, pas de réponce au ping non plus.
si je ping du dns via la console série, le led réseau du boitier clignote mais tout les paquets sont perdu.

ci joint le log du boot de alt-f et le fichier herewego.log.



cordialement.

Bonjour,

Now that you have a serial connection we're getting closer.

If the network LED lights up during outgoing pings at least the network layer in the kernel is working so far.

While ping-ing does the LED on the receiving part (router?) also light up?
If you do an  ifconfig afterwards is TX-counter also going up?

Which addresses are you pinging, both your computer and the gateway (router)?

what output do you get from

arp -an
ethtool eth0
???



Is the gateway and net-mask on your computer the same as on the DNS323?

Great job, Lucien and nogi.

Besides what nogi asks, can you also give us the output of "ifconfig eth0" after several pings from the box to the router?

Have you tried to bypass the router and directly connect another computer?

Can you also try to ping the local 192.168.0.171 ip?

And unplug the network cable and replug it again?
On my box I see the message " eth0: link down" when unpluging and "eth0: link up, 1000 Mb/s, full duplex, flow control disabled" when repluging.

Also try to bring the interface down, "ifconfig eth0 down" and then up, "ifconfig eth0 up 192.168.0.171".

Other from that, I have no other clue, thanks for your attempts.

[added: do you have another network cable that you can try? There are direct and cross cables, and if there is a problem at the link level perhaps the router and the box can't detect crossed signals?
Or trying a direct computer-nas connection, bypassing the router, as mushanga suggests?]

Last edited by jcard (2010-05-18 19:37:19)