Printable View
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.
Updated 2010-05-08: vsftpd & IPv6 works for me in r1538Quote:
Originally Posted by ecaddict
Can you please send your (a working) vsftpd.conf?Quote:
Originally Posted by lly
It seems to run, however when I try to connect a FIN comes nearly immediatelly (after SYN, SYN, ACK):
Code:netstat -a | grep ftp
tcp 0 0 :::ftp :::* LISTEN
Code:lsof | grep vsftpd
...
vsftpd 653 admin 3u IPv6 4396 0t0 TCP *:ftp (LISTEN)
works for me as well...Quote:
Originally Posted by ecaddict
Code: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
Wow, really nice system utilization monitor:D
Thanks, it works for me as well now. It was not the listen_ipv6 (as it was listening on IPv6) but some other parameter.Quote:
Originally Posted by wpte
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?Quote:
Originally Posted by ecaddict
Made the mount as usual:Quote:
Originally Posted by lly
started a file copy and monitored the traffic with Wireshark.Code: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
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.
the modules should be exactly the same as from the separate modules: ftp://core.dumped.ru/rt-n/1547/Quote:
Originally Posted by ecaddict
They come from exactly the same patched kernel and I didn't change any settings of those modules;)
I thought that modules are taken from flash. I don't know what's wrong:
Attachment 6401
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.
Attachment 6439
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...
Code:.../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;
Thus it's either RPCSVC_MAXPAYLOAD_UDP or rqstp->rq_server->sv_max_payload.Code:.../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;
}
and header files contain 32K:
So it must be sv_max_payload. The origin of it is touched in different places, e.g.Code:.../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)
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.Code:.../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;
}
.../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.
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):
The answer is always:Code:plink.exe @svn svnserve //svn is a putty-session with username and key set.
Has anyone an idea on how to set the paths for autonomious logins?Code:sh: svnserve: not found
regards
Benj
No idea... tho I have a similar problem with openssh and sftp.Quote:
Originally Posted by bef
As soon as you try to connect with sftp, the special sftp server from openssh can't be found:confused: (while it does exist on disk)
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):
the result isCode:plink.exe @svn echo $PATH //svn is a putty-session with username and key set.
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 :/ )Code:/usr/bin:/bin
other approach: set a PATH variable in putty
though this yields
is it possible to allow the setting of such env variables in dropbear?Code:server refused to set environment variable
regards Benj
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.