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

jcard: Just want to vent an idea.

My experience or fonz reload (which is an amazing peace of sw) isnt entirely stable. Sometimes it workes sometimes not, much depinding on size of what is being reloaded and amount of free memory. Would reloading in two stages maybe raise successrate? First reload into something minimal with sole purpose to successfully reload again into alt-f?

bjby wrote:

jcard: Just want to vent an idea.

My experience or fonz reload (which is an amazing peace of sw) isnt entirely stable. Sometimes it workes sometimes not, much depinding on size of what is being reloaded and amount of free memory. Would reloading in two stages maybe raise successrate? First reload into something minimal with sole purpose to successfully reload again into alt-f?

The problem seems to be the size of the initramfs, you might want to read this thread:
http://dns323.kood.org/forum/viewtopic. … 280#p40280

Alt-F initramfs is 6.37 MB compressed and about 11MB uncompressed.

I have a (still untested) modified version of fonz reloaded, and when I have the time I will try to incorporate puterboy ideas. Pitty that he doesn't provide the source code with the modifications he has done...
When memory allocation fails, my version just frees all allocated memory and tries to relaunch the web interface, instead of freezing.
But according to puterboy memory allocation isn't the problem, the problem seem to be enough available memory for uncompressing the initramfs, and avoiding that the uncompressed image does not destroy some (unknown) memory areas.

dlink firmware looks for and executes the fun_plug script 30 seconds after starting its own services, so when fun_plug starts most memory is already in use, which leads to fragmentation.
Alt-F uses kexec instead of fonz reloaded, and it never fails! I use kexec to load new kernel and initramfs during Alt-F development.

Meanwhile you should disable all (but the essentials) dlink provided services and addons, and retry, and retry, and retry -- reloading works, but not always!

kingjafad wrote:

jcard wrote:

No issue should arise because of upgrading.

Please consider  filling-in the NTFS compressed  issue in http://code.google.com/p/alt-f/issues/list so I won't forget to upgrade to the last version, if flash space permits.

Thanks for diagnosing the problem.

Jcard,
I have submitted as requested but feel free to put it at the lower priority levels of your work as i can certainly work around it.
Many thanks,

Can you please try http://dl.dropbox.com/u/1555717/DNS-323 … index.html
It has ntfs-3g-2010.10.2 and several other fixes.

rellikzephyr wrote:

jcard wrote:

Packages were built for Alt-F version B2 or B3, mostly to prove the concept and to be an appetizer for most users. All (but avahi and afs) worked at the time.
I have not updated them meanwhile, I intended to do it after B6, but I'm concentrating my efforts in bug fixes.

Please be patient, I have already compiled the last minidlna and transmission releases, I have yet to test them.

i dont like asking this question cause i know its one of the most annoying and common ones but im going to anyway

do you have an ETA on dlna completion?

the reason i ask is, dlna server is the single reason i bought this nas. when my standard firmware stopped working i was hoping alt-f would pick up where standard left off. although alt-f has fixed all other problems...Thanks!. i neeeed a dlna server, ill have to go back to a server on a comp in mean time i guess

keep up the good work

RellikZephyr

No, I don't have a ETA.

My plans was to look at packages after 0.1B6, but I found rev-A1 board and other issues in the base firmware more important to fix.

But this afternoon I just recompiled all Alt-F packages and the first one I tried was minidlna-1.0.18 with xbmc on another computer.
It worked. But not with my media-center.

minidlna has lots of dependencies: ffmpeg, flac, jpeg, libexif, libid3tag, libogg, libvorbis, ncurses, readline, sqlite... and I need to make sure that all are working.

How do i know that alt-f is my firmware? I flashed my dns 323 C1 yesterday. is there a way to se that vendor firmware is gone or replaced with alt-f?
I have one Alt-f and one alt-f folder, can i delete one of them? i dont know if the system uses Alt-f or alt-f folder?

Last edited by konke (2011-02-14 11:40:54)

If you flashed Alt-F (System->Firmware) and no errors appear during the process (why should?), only a message saying "The new firmware will only be active after a reboot" and a "reboot" button appears at the end,  then the current box firmware is Alt-F.

Also, the boot time has dropped from more than 2 minutes with the stock firmware to one minute with Alt-F.

But, just to be sure, telnet/ssh the box and issue the following command:

   dd if=/dev/mtdblock2 ibs=64 count=1 2> /dev/null | strings

If Alt-F is flashed, the command output should be "Alt-F-0.1B6, kernel 2.6.36.2"

The  Alt-F folder is where packages are installed, and it must have a README.txt file saying

   DON'T ADD, REMOVE OR MODIFY ANY FILE IN THIS DIRECTORY
   OR ANY OF ITS SUBDIRECTORIES, OR THE SYSTEM MIGHT HANG!

If you want to remove all packages, use the web interface, Packages->Alt-F and hit the "RemoveAll" button. The Alt-F directory should now disappear.

The alt-f directory is only needed when using Alt-F with the reloaded method, i.e., no flashing was involved. If your box is Alt-F flashed, you can remove it.

Note the letters casing: Alt-F is not the same as alt-f :-)

Just tried it out and it worked, then i can say that it works flashing the dns323 C1. And it works like a charm.   Thank you.

One more thing, can i delete funplug and alt-f and alt-f_reloaded files in root of disk1 "mnt\HD_a1\"?

jcard wrote:

Yes, they are only used when using the reload method to boot Alt-F, they are ignored by Alt-F itself.
Just don't touch the Alt-F directory.
The alt-f.log file will always be generated (on all filesystems) on each new boot (in 0.1B7 you can disable its generation)

Great, thank you again, sorry if my questions are stupid

When there is a nother alt-f release, can i test it and then flash the dns and just load my old setting from ex 0.1B6 to B7?

So when will  0.1B7 be released?

zero13th wrote:

hei jcard,

using alt-f 6+ with jbod disks, i found this:

Code:

http://img220.imageshack.us/img220/1013/altfraid.png

cat: can't open 'sys/block//dev/sda/size': No such file or directory

This has already been fixed.

Feb 22 22:40:52 DNS-323 user.info kernel:  md0: unknown partition table
is it normal?

Yes, this is normal.

With RAID one can create a partition table inside a RAID device. A RAID device like md0 can be used like a sda disk device.

Some people prefer to partition a disk in several partitions, and to create RAID devices in each one of these partitions, while others prefer to create a single RAID disk partition and to partition the resulting RAID  device in several RAID partitions.

Alt-F uses the first approach, but the RAID device driver seems to always search a partition table inside the RAID device -- as it found none that it recognizes (there is none), it emits the warning.

Convoluted?

Thanks for the report.

BTW, there is another experimental Alt-F-ipv6 release in the same place you got your B6+.

jcard,

thanks for the latest firmware

i found that reboot and shutdown from web doesn't work.
manual reboot also make system hang. (i must plug/unplug power adaptor to restart the system)

i'm using nfs with default setting
/mnt/md0/zero13th *(rw,no_root_squash,no_subtree_check,anonuid=99,anongid=98)

in system log:
Feb 25 12:05:08 DNS-323 daemon.notice rpc.statd[654]: Version 1.2.1 Starting
Feb 25 12:05:08 DNS-323 daemon.notice rpc.statd[654]: Flags:
Feb 25 12:05:08 DNS-323 daemon.notice rpc.statd[654]: Unable to read state from '/var/lib/nfs/state': errno 5 (Input/output error)
Feb 25 12:05:09 DNS-323 user.info kernel: NET: Registered protocol family 10
Feb 25 12:05:09 DNS-323 user.warn kernel: svc: failed to register lockdv1 RPC service (errno 97).
Feb 25 12:05:09 DNS-323 user.notice root: Starting portmap: .OK. Starting rpc.mountd: OK. Starting rpc.statd: OK. Starting rpc.nfsd: OK. Starting sm-notify: OK.


i found this err code: (also from B6+ log)

Feb 25 12:05:08 DNS-323 daemon.notice rpc.statd[654]: Unable to read state from '/var/lib/nfs/state': errno 5 (Input/output error)
Feb 25 12:05:09 DNS-323 user.warn kernel: svc: failed to register lockdv1 RPC service (errno 97).

is it also normal?


and if i want to setup alt-f NFS server behind NAT,
is it possible to bind nfs-related port (rpc.mountd, rpc.statd) to static port?

Last edited by zero13th (2011-02-25 17:05:49)

hi uksparky,

with my dns rev c1 with the latest firmware and 100Mbps router, i can achieve 5-6MBps on rsync and 9-10MBps on ftp transfer.

uksparky wrote:

Hi jcard,

Awesome work on the firmware, owned my dns less than a week, and already overwhelmed at it's possibilities.

I seem to have an issue with file transfers being limited at 10Mbit, despite having a connection of around 18mbit and all other devices on the network being able to achieve that kind of speed. Even LAN transfers over ethernet appear to be maxing at around 2MB/sec. I've tried transferring files using scp/ftp/wget and all hit around 1MB/sec and don't go any higher. I've tried changing the ethernet cables, the ports, and still only my NAS download speed is limited, so it appears to be some kind of issue with the firmware, unfortunately I never tried to see what the speeds were with the pre-installed firmware, so can't confirm that the transfer speeds were once much higher, and I really don't want to go back to the stock firmware just to test this.

Can you confirm you don't suffer any issues with the transfer speeds maxing out at 1MB/sec, and if not suggest any possible reasons for the capped transfer speeds? I'm wondering if it could be due to the tcp configuration of the firmware.

*Update* I've just noticed flow control is disabled on the network interface, will this affect things?

Cheers

Everybody has flow control disabled.
Flow control is done at the IP level, not by hardware, that is what the message means.

Edited: this should read: Flow control is done at the TCP level between endpoints, not at IP level between endpoint and switch, which is what the message means.

I now get 15MBps on ftp on a Gbit network with Alt-F-IPv6.

But I have older records of 22MBps and even 40MBps when using a MTU of 7000.

Have you IPv6 enabled in Alt-F? Is your network IPv6 ready? Macs?

Can you try 0.1B6 or even previous versions, just to see if the results are consistent?
Just download the Alt-F*.bin file and go to System->Firmware->Upload, but hit the "TryIt" button instead of the "FlashIt" button. No flashing is involved, and after hitting the "Reboot " button you will be running the new (older) kernel. Just don't save anything to flash while running the new kernel, to prevent incompatibilities in configuration settings.

I really wouldn't advise using Alt-F-IPv6 for everyday usage. Alt-F-0.1B6+ will be OK.
But if you want to test and report problems, you are welcome.

Edited: After removing all Alt-F packages, thus disabling the aufs overlay mechanism, ftp transfer rate rises to 19.5MBps. Without rebooting from the previous test, Gbit network, MTU of 1500,  1.1 GB transfer, IPv6 enabled. So IPv6 is not deteriorating the network.

Last edited by jcard (2011-02-28 18:07:45)

Have used the try it idea and still experiencing the same, wget ftp://ftp.sunet.se/ls-lR.gz from my laptop connected using wireless is getting 1.6MB/sec but the same command from the NAS connected using an ethernet cable is only getting 1.03MB/sec. Have tried changing the network cable and ports, have tried downloading to different disks, have tried using scp over the LAN and still experiencing these slow speeds. Other than changing the router I'm all out of ideas.