Padavan's Custom Firmware

[Zoomer88]

Check the 'edit 3' part of my previous post if you haven't seen it yet. I put an answer to your question about HFS there. I'm not sure whether it answers your question and how much this journaling is important for the users of HFS and how difficult it is to disable it. That was just a direct translation. So if you have anything else to add - don't hesitate to post it!

 

[kenguru2005]

That's bad news about HFS+ as there are only few other file systems supported by Mac OS X and I don't suppose that exFAT is supported by custom firmware. So I have to switch back to FAT32

 

[Zoomer88]

But why? What storage are you using? Is it permamently connected to the router HDD? Why don't you setup an SMB share and access it from MacOS if you need to copy files to it? Or just setup miniDLNA. Or is there a need in connecting this storage directly to your PC?

 

[kenguru2005]

That's the problem: the 2.5" USB drive is not permanently connected to the router, from time to time I have to connect it directly to the Mac.

 

[Zoomer88]

So how important journaling for this HDD then? Maybe it will be acceptable for you to disable it? Though AFAIK it was specificaly designed for the cases when abrupt interuption of the wirte process is expected (in other words for removable devices).

 

[kenguru2005]

Journaling isn't important at all for me ... so I misunderstood you ... Non- journaled HFS will be supported?

 

[Zoomer88]

That's just the question I'm asking the developers right now. As to current plans: no, they won't be supported.

But it is possible to support un-journaled drivers in rw mode (read-write) and journaled drivers in ro (read-only) mode through kernel driver. That's how the kernel driver works. You just need to enable it.

On the other hand enabling such a support and encouraging users to disable journaling on their volumes may lead to the situation where we will have mad-at-us users who have lost their files due to the disabled journaling. So it kinda cuts both ways. We'll see what the devs will say.

 

[kenguru2005]

Ok ... I´m going to switch to FAT32 as I don't have large files on this disk. Perhaps ExFat will be implemented in future.

 

[Zoomer88]

Right. A flag for HFS+ support the way I described it will be included in the project configuration. All those who realize what the journaling is and undesrstand that its disabling may lead to sad consequences in case of abrupt shutdown of the system during the read/write process, may compile the firmware with that flag set to on. The default value is off.

The firmware's file system logic is designed in such a way, that enabling this HFS+ support flag will be enough. It will be automatically used.

As to exFAT support - no, there's no support of it and it's not planned, sorry.

 

[Zoomer88]

Build 012 is available in the downloads section!

 

[Zoomer88]

@kenguru2005
In the end it was decided to enable HFS+ support by default. If you're feeling brave enough, you might want to try it out. As I said before: if you connect storage with journaling enabled, it'll be mounted but only in READ ONLY mode. If you'll disable journaling it'll be mounted in READ-WRITE mode. I suggest you poking around the Internet to find out how important this journaling actually is and what random Internet guys say about using HFS+ w/o journaling. Maybe it's not that bad. Maybe it is. I honestly have no experience with HFS!

 

[zainday4]

RT-N56U_3.0.2.4-012

Changes to firmware ver. 3.0.2.4-011:
----------------------------------------------------------
- Upgrade Linux kernel to 3.0.43 from www.kernel.org.
- Fixed IPTV issue after PPP connection established.
- Fixed HW_NAT drop bindings issue.
- Fixed static routes metric, fixed static routes table in WebGUI.
- Fixed NTPD and DDNS update issue after router startup.
- Fixed upload CFG settings issue under IE9/IE10.
- Add pppoe-relay support (userspace only).
- Add HFS+ support (rw mode only w/o journal).
- Add Cisco 794x IP phones support in SIP ALG.
- Add symlinks mkfs.ext4, fsck.ext4 for easy handling ext4 partitions.

http://code.google.com/p/rt-n56u/downloads/detail?name=RT-N56U_3.0.2.4-012_newgui.zip&can=2&q=

 

[aaronwt]

RT-N56U_3.0.2.4-012

Changes to firmware ver. 3.0.2.4-011:
----------------------------------------------------------
- Upgrade Linux kernel to 3.0.43 from www.kernel.org.
- Fixed IPTV issue after PPP connection established.
- Fixed HW_NAT drop bindings issue.
- Fixed static routes metric, fixed static routes table in WebGUI.
- Fixed NTPD and DDNS update issue after router startup.
- Fixed upload CFG settings issue under IE9/IE10.
- Add pppoe-relay support (userspace only).
- Add HFS+ support (rw mode only w/o journal).
- Add Cisco 794x IP phones support in SIP ALG.
- Add symlinks mkfs.ext4, fsck.ext4 for easy handling ext4 partitions.

http://code.google.com/p/rt-n56u/downloads/detail?name=RT-N56U_3.0.2.4-012_newgui.zip&can=2&q=

SO is this still considered a beta?

 

[aaronwt]

...................
Edit: remembered one more case where HW_NAT may be disabled automatically. If you go to the Netfilter settings and change default 16384 allowed connections (HW_NAT maximum) to anything more than that, the HW_NAT module will be disabled. Though honestly 16384 is A LOT! You might need more in some specific cases (10 p2p clients running simultaneously from different PCs? I dunno...). Even then more than ~20k connections will be a massive load on CPU and you'll still lose in the end. So HW_NAT is a good thing

.................

Is there any disadvantage(or advantage) to dropping the HW_NAT to 8192?
I've never even seen mine show more than 2000 connections.

 

[Guz]

Now considering FastNAT module from wive-NG project:

IPoE connection speeds
Current 2.x kernel:
FastNAT=OFF
~270 mbit/s
FastNAT=ON
~420 mbit/s

3.0.42 kernel:
~400 mbit/s without FastNAT and some other optimizations.

With HW_Nat module enabled speed is around ~930-940 mbit/s on both kernels.

OK, this is one area where I get confused. What is the preferred setting to maximize throughput?

Hardware NAT:
Enable offload LAN
Enable offload LAN/WiFi

BTW, I just loaded 3.0.2.4-012 (Friday and Monday are my maintenance windows). WOW! NTFS SAMBA/CIFS throughput is finally acceptable!!! WoooHooo!!!

Zoomer88, could you ask on the Russian board about preserving DOS Attributes (Hidden, Read Only, System, Archive) on network shares in SAMBA? Has the kernel been compiled with extended attributes support (xattrs) enabled?

Or, has there been any thought of running a newer version of SAMBA? Pavadan is currently using 3.0.37 (smbd -V = Version 3.0.37), where-as the current stable release from samba.org is 3.6.8, I do believe that 3.2.0 is the version that started support for storing alternate data streams in xattrs (I think).

I know, I know, I sound like a broken record on this topic. But it is the last piece of the puzzle that would set this router apart from others and allow some software to work properly when copying files.

 

[RMerlin]

Or, has there been any thought of running a newer version of SAMBA? Pavadan is currently using 3.0.37 (smbd -V = Version 3.0.37), where-as the current stable release from samba.org is 3.6.8, I do believe that 3.2.0 is the version that started support for storing alternate data streams in xattrs (I think).

Newer versions of Samba take a couple of additional megabytes in terms of space. That's problematic for a device with limited firmware space such as a router.

 

[zainday4]

SO is this still considered a beta?

I believe so, it's not stated anywhere (that I noticed), but version 1.1.2.3-010 is still on the main page of the project and the newer version is in the download area.

 

[Shikami]

I think I am seeing more CPU usage when downloading than normally with previous versions of the firmware. Anyone else notice this? Normally I wouldn't see anything when downloading 6.9MB/s

Is there any disadvantage(or advantage) to dropping the HW_NAT to 8192? I've never even seen mine show more than 2000 connections.

You will save a little memory that is all. If you reached that maximum then the NAT table would be full and cannot make anymore relations to the packets and therefore cannot connect.

Just leave it at its max with HW_NAT acceleration. You can be surprised every once in a while just how many connections can be created with a modern family household.

OK, this is one area where I get confused. What is the preferred setting to maximize throughput?

Hardware NAT:
Enable offload LAN
Enable offload LAN/WiFi

The Wi-Fi was experimental for a bit and then finalized later. It offloaded some of the Wi-Fi not all and lowered the sirq's when enabled. Overall it was better to have it enabled. Unless you were having issues with Wi-Fi. I personally have not even during the experimental stage.

SO is this still considered a beta?

Yes, this is beta, but stable

 

[Guz]

Found an intermittent bug in 3.0.2.4-012

USB drive, NTFS format, intermittent permission denied when dragging-n-drop or create directory via SAMBA.

Sometimes I have to remove the drive and take it to a local machine and run chkdsk /F on the drive then reattach. Sometimes I just have to wait a couple of minutes and retry the action, and will then copy the directory and files.

Or, I telnet into the router, and create the directory name, then just copy the files in the directory, then it works.

I haven't verified but it mainly happens in any sub directory that is monitored by minidlna.

P.S.
Please don't recommend changing the drive format, I'm not gonna do it.

 

[Shikami]

Woot! IPv6 support official, but still beta. A wonderful step forward with this firmware! Thank you, gentlemen for all the work.

http://code.google.com/p/rt-n56u/downloads/detail?name=RT-N56U_3.0.2.5-015.zip#makechanges