alpha rt-n firmware releases

[ecaddict]

Single page is probably enough. The most important is that information is collected somewhere.

Btw, couple of days ago (after IPv6 was fixed) I've made a quick try with the firmware vsftpd&IPv6. It was listening and my PC tried to connect but after TCP SYN/SYN ACK round disconnect was received.
Is it working/have you checked it?

Don't waste too much time on it if it seems OK, I'll give a second try to it.

[lly]

Btw, couple of days ago (after IPv6 was fixed) I've made a quick try with the firmware vsftpd&IPv6. It was listening and my PC tried to connect but after TCP SYN/SYN ACK round disconnect was received.
Is it working/have you checked it?

Updated 2010-05-08: vsftpd & IPv6 works for me in r1538

[ecaddict]

Updated 2010-05-08: vsftpd & IPv6 works for me in r1538

Can you please send your (a working) vsftpd.conf?

It seems to run, however when I try to connect a FIN comes nearly immediatelly (after SYN, SYN, ACK):

netstat -a | grep ftp
tcp        0      0 :::ftp                  :::*                    LISTEN

lsof | grep vsftpd
...
vsftpd    653    admin    3u     IPv6       4396      0t0     TCP *:ftp (LISTEN)

[wpte]

Can you please send your (a working) vsftpd.conf?

works for me as well...

anonymous_enable=no
dirmessage_enable=yes
download_enable=no
dirlist_enable=no
hide_ids=yes
syslog_enable=yes
local_enable=yes
local_umask=022
chmod_enable=no
chroot_local_user=yes
check_shell=no
isolate=no
user_config_dir=/etc/vsftpd.users
passwd_file=/etc/vsftpd.passwd
listen_ipv6=yes
listen_port=21
background=yes
max_clients=0
idle_session_timeout=0
utf8=yes
use_sendfile=no
anon_max_rate=0
local_max_rate=0

[wpte]

Wow, really nice system utilization monitor

[ecaddict]

works for me as well...

Thanks, it works for me as well now. It was not the listen_ipv6 (as it was listening on IPv6) but some other parameter.

[ecaddict]

I've checked NFS block size again. It seems to be 16K instead of 32K. Probably since modules are included in the firmware...

[lly]

I've checked NFS block size again. It seems to be 16K instead of 32K. Probably since modules are included in the firmware...

Can you explain how did you do measures exactly?

[ecaddict]

Can you explain how did you do measures exactly?

Made the mount as usual:

mkdir /tmp/RT-N16
sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=14,intr,proto=udp 192.168.1.1:/mnt /tmp/RT-N16

started a file copy and monitored the traffic with Wireshark.
I know that in the code it's 32K (maybe in /linux/linux-2.6/include/nfsd/const.h, I cannot check it right now) but in the monitoring I could see only 16K blocks.

[wpte]

I've checked NFS block size again. It seems to be 16K instead of 32K. Probably since modules are included in the firmware...

the modules should be exactly the same as from the separate modules: ftp://core.dumped.ru/rt-n/1547/
They come from exactly the same patched kernel and I didn't change any settings of those modules

[ecaddict]

I thought that modules are taken from flash. I don't know what's wrong:



Update: Probably I've got one step further of this long pending issue.

After checking the mount procedure, I was sure that 16K limit comes from server side.


Google search pointed to one direction, that could help
http://www.spinics.net/lists/linux-nfs/msg07247.html
but unfortunately /proc/fs/nfsd/max_block_size does not exist in the router...

.../broadcom/src/linux/linux-2.6/fs/nfsd/nfs3proc.c
nfsd3_proc_fsinfo...
	u32	max_blocksize = svc_max_payload(rqstp);
...
	resp->f_rtmax  = max_blocksize;
	resp->f_rtpref = max_blocksize;
	resp->f_rtmult = PAGE_SIZE;
	resp->f_wtmax  = max_blocksize;
	resp->f_wtpref = max_blocksize;
	resp->f_wtmult = PAGE_SIZE;
	resp->f_dtpref = PAGE_SIZE;
	resp->f_maxfilesize = ~(u32) 0;
	resp->f_properties = NFS3_FSF_DEFAULT;

.../broadcom/src/linux/linux-2.6/net/sunrpc/svc.c
u32 svc_max_payload(const struct svc_rqst *rqstp)
{
	int max = RPCSVC_MAXPAYLOAD_TCP;

	if (rqstp->rq_sock->sk_sock->type == SOCK_DGRAM)
		max = RPCSVC_MAXPAYLOAD_UDP;
	if (rqstp->rq_server->sv_max_payload < max)
		max = rqstp->rq_server->sv_max_payload;
	return max;
}

Thus it's either RPCSVC_MAXPAYLOAD_UDP or rqstp->rq_server->sv_max_payload.

and header files contain 32K:

.../broadcom/src/linux/linux-2.6/include/linux/sunrpc/svc.h
#define RPCSVC_MAXPAYLOAD       (1*1024*1024u)
#define RPCSVC_MAXPAYLOAD_TCP   RPCSVC_MAXPAYLOAD
#define RPCSVC_MAXPAYLOAD_UDP   (32*1024u)

So it must be sv_max_payload. The origin of it is touched in different places, e.g.

.../broadcom/src/linux/linux-2.6/fs/nfsd/nfssvc.c
int nfsd_create_serv(void)
{
	int err = 0;
	lock_kernel();
	if (nfsd_serv) {
		svc_get(nfsd_serv);
		unlock_kernel();
		return 0;
	}
	if (nfsd_max_blksize == 0) {
		/* choose a suitable default */
		struct sysinfo i;
		si_meminfo(&i);
		/* Aim for 1/4096 of memory per thread
		 * This gives 1MB on 4Gig machines
		 * But only uses 32K on 128M machines.
		 * Bottom out at 8K on 32M and smaller.
		 * Of course, this is only a default.
		 */
		nfsd_max_blksize = NFSSVC_MAXBLKSIZE;
		i.totalram <<= PAGE_SHIFT - 12;
		while (nfsd_max_blksize > i.totalram &&
		       nfsd_max_blksize >= 8*1024*2)
			nfsd_max_blksize /= 2;
	}

I don't know if this function is used or not, but one thing is sure: This algorithm does not make sense for routers where 128 MB RAM is quite a lot.

.../broadcom/src/linux/linux-2.6/include/linux/nfsd/const.h
#define NFSSVC_MAXBLKSIZE RPCSVC_MAXPAYLOAD

Also this thould not give 16K block size so I don't get it...
Does si_meminfo report the correct memory amount? E.g. reporting one page less, could lead exactly to the 16K NFS block size...

Anyhow what's so bad about this algorithm that it sets the 16K (32K) limit even for TCP, where it should be at least 64K (but more like 256K)...
In PC with lots of processes it may make sense, but not with the router.

The simplest to fix this would be probably to change
int nfsd_max_blksize; -> int nfsd_max_blksize=65536;
in nfsctl.c (the uniniatilised global looks ugly to me anyhow...)

Related is the write_maxblksize and NFSD_MaxBlkSize but as I could not find the file, probably it does not play any role.

[bef]

Hello

In the german forum a problem arised about "non-interactive" ssh-sessions such as subversion over ssh. While a manual login to the router (in my case) using putty as client and dropbear as server the paths set in /opt/etc/profile are applied and i can execute svnserve or any other command. As soon as the ssh-connection is called from a programm (tortoisesvn using the putty plink.exe) or i call the plink manualy with this comand (in win7):

plink.exe @svn svnserve //svn is a putty-session with username and key set.

The answer is always:

sh: svnserve: not found

Has anyone an idea on how to set the paths for autonomious logins?

regards
Benj

[wpte]

Hello

In the german forum a problem arised about "non-interactive" ssh-sessions such as subversion over ssh. While a manual login to the router (in my case) using putty as client and dropbear as server the paths set in /opt/etc/profile are applied and i can execute svnserve or any other command. As soon as the ssh-connection is called from a programm (tortoisesvn using the putty plink.exe) or i call the plink manualy with this comand (in win7):

plink.exe @svn svnserve //svn is a putty-session with username and key set.

The answer is always:

sh: svnserve: not found

Has anyone an idea on how to set the paths for autonomious logins?

regards
Benj

No idea... tho I have a similar problem with openssh and sftp.
As soon as you try to connect with sftp, the special sftp server from openssh can't be found (while it does exist on disk)

[bef]

I think i have found the source for these errors, though i have no idea on how to fix it. If i do the following (from cmd in win7):

plink.exe @svn echo $PATH  //svn is a putty-session with username and key set.

the result is

/usr/bin:/bin

Therefore i think these are the default paths offered from dropbear. I didn't found a way to start dropbear with a path argument. And i can't add a link from any of these directories to the svn commands (read-only :/ )

other approach: set a PATH variable in putty
though this yields

server refused to set environment variable

is it possible to allow the setting of such env variables in dropbear?

regards Benj

[ecaddict]

I've checked this NFS max block size issue a bit more and maybe I've found the cause of why 16K block size is used.
Link to original post.
I've updated the original post to contain all information now.

Please check and fix it if that's indeed the root cause.
My guess is that initialising nfsd_max_blksize will fix this issue.