I am a new user (presently using Hamachi) testing NeoRouter with a 64-bit computer running Ubuntu as the server and two clients, both 32-bit computers running Win XP. All I want from NeoRouter is simple file sharing from one server to a few remote computers. Yesterday, one XP client could see and could modify the shared files on the Ubuntu server. Today, however, I added a second client but the two XP clients see the Ubuntu computer as "offline". They see themselves and each other as "online".

On the Ubuntu computer, nrserver and smbd are both running. I checked my router, port 32976 is forwarded to 192.168.1.100 (the Ubuntu machine) just like yesterday. What do I do to get the server online today? It was working fine yesterday. Seems to work fine today for everything but NeoRouter. I am using the Ubuntu machine to post this query.

Is this related--on the Ubuntu server, I tried running nrclientcmd (CLI). It lets me log in, but then shows nothing, no computer list, nothing. All I can do is quit, which it accepts and quits. So nrclientcmd on the server is useless/inoperative also. I installed both the server and the client components on the Ubuntu machine yesterday.

There must be a simple answer to this, which I cannot find in the User Manual.

Thanks for any help,

David E. aka bluejay41

Found out how to get the nr SERVER "online" from an "offline" status by thrashing around for a couple of hours in init.d and elsewhere. You have to (as root) manually run a shell file in init.d which starts the nr SERVICE. I am not making this up.

Shouldn't this be in the User Manual? Maybe it is and I just didn't see it?

The questions now are, why does the nrservice routine die? How often does it die? What can be done to keep it running? Have I got it misconfigured somehow? Please don't tell me I have to run a cron job that executes the restart every 2 minutes or so, in case it's gone down in the last 2 minutes?!?

If so, might as well restart the nrserver routine also. Just in case. What else has to be kept running in order to keep file sharing working?

Thanks.

hi David,

Welcome and thank you for using NeoRouter!
nrservice is a daemon that should be always running in the background. The init.d shell script should be executed when OS starts and kick off nrservice. Because it is automatic, we did not include the details in the user's manual.
I do not know why nrservice is not running. It's possible that it had crashed. If you do not have time to debug the cause, adding a cron is not a terrible idea. use "/etc/init.d/nrservice.sh start" command because it checks for existing nrservice instance.
If you can help enable core dump, maybe we can capture a core file and debug the issue. Another way to figure out things is to enable NeoRouter log (http://www.neorouter.com/wiki/index.php ... og_file.3F).

Thanks,
Luke

Hi Luke, Thanks for replying. I will try the NeoRouter log, see what that shows. I am not sure it is a NeoRouter bug, it could be a Ubuntu bug.

Ubuntu definitely has bugs, bugs in C code, syntax errors in startup scripts, you name it. Oddly (or not so oddly), when I run Hamachi with a Ubuntu file server and Windows XP clients, I have a similar problem to this NeoRouter problem: the Hamachi daemon on the server (never the clients) dies at random times: 5 minutes after starting, an hour after starting, and so on.

I get around this with a cron job that restarts both the Hamachi daemon and also smbd which also must be running for file sharing to work. That problem is the chief reason I am investigating NeoRouter--Logmein hasn't seemed interested in improving the Linux or Mac OS versions since they purchased Hamachi.

Enabled logging as Luke suggested. Log looks normal to me, less than a dozen lines, nothing resembling an error message. BUT...now cannot start nrservice.sh AT ALL!

That's right, "sudo /etc/init.d/nrservice.sh stop" worked (I got the stopping service message and nrservice.sh disappeared from ps aux output) BUT "sudo /etc/init.d/nrservice.sh start" did not work (I got the starting service message and saw the new PID file in /var/run/ BUT nrservice.sh never appeared in ps aux output and a client computer sees the file sharing computer as "offline").

Same thing with nrserver--can stop it but cannot start it again!

This seems so zany that I could not believe it. Rebooted the computer, and neither nrserver nor nrservice came up, and I could not start them manually.

Renamed the Log.ini file to Log.ini.old (effectively disabling logging), rebooted, and all was normal again.

Renamed the Log.ini.old file to Log.ini again, rebooted, and the system is crazy again. nrserver.sh and nrservice.sh were both up immediately after rebooting but nrservice.sh stopped seconds later, and could not be manually started!

Your shell files seem designed for Sys V style bootups. Debian has a new Upstart system for controlling daemons, said to be backwardly compatible with Sys V style. But are your scripts running afoul of Debian's new system? And what could the Log.ini file possibly have to do with it?

I am running Ubuntu 10.04 LTS, Lucid Lynx.

hi bluejay41,

Let's try starting starting nrservice directly and you can get more error information.
First kills existing instance using "sudo killall nrservice". Then launch new instance using command "sudo /usr/bin/nrservice". If successful, the command should not return. If failed, you should see an error code. please send us the error code.

Thanks,
Luke

Hi Luke,

sudo killall nrservice - got "nrservice: no process found" which is reasonable, since nrservice.sh was not running at that time.

sudo /usr/bin/nrservice - got a small formatted dump, backtrace followed by memory map. The first line of the dump said "*** stack smashing detected ***: /usr/bin/nrservice terminated".

The formatted dump cannot be redirected to a file--is it being written directly to the screen?? Only two lines got redirected into a file:

NeoRouter Free [Version 1.5.0.2810]
Copyright (C) 2011 NeoRouter Inc.

Is it possible that the daemon that actually runs the nrservice is being called with bad arguments, or with arguments which are then being badly handled internally, with buffer overruns resulting? Is it possible that one of the troublesome arguments is the log file's name? That could explain why nrserver dies from time to time, and in particular explains why running with logging could act very differently from running without logging.

Second question: is Version 1.5.0.2810 thought to be reasonably stable, or is it known to be highly unstable? Is there a more stable version of NeoRouter that I can try in our unit (which is engaged in non-profit medical research)?

Thanks,

Bluejay41

Hi Luke,
Here is the backtrace I get from invoking /usr/bin/nrservice. Is this saying it was in a libstdc++ subroutine when it crashed? Must be bad arguments to the call. Can you tell which particular subroutine without recompiling?

--------------------------------------------------------------------------------------------------------------------
NeoRouter Free [Version 1.5.0.2810]
Copyright (C) 2011 NeoRouter Inc.

*** stack smashing detected ***: /usr/bin/nrservice terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f9adbb91217]
/lib/libc.so.6(__fortify_fail+0x0)[0x7f9adbb911e0]
/usr/bin/nrservice[0x4e93cc]
/usr/bin/nrservice[0x4eabda]
/usr/bin/nrservice[0x4b8598]
/usr/bin/nrservice[0x40a426]
/usr/bin/nrservice[0x40aae9]
/usr/bin/nrservice[0x40837d]
/usr/bin/nrservice[0x406c54]
/usr/bin/nrservice[0x406337]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f9adbab0c4d]
/usr/bin/nrservice(__gxx_personality_v0+0x239)[0x405f29]
======= Memory map: ========
00400000-006ca000 r-xp 00000000 08:06 411415 /usr/bin/nrservice
008ca000-008d8000 rwxp 002ca000 08:06 411415 /usr/bin/nrservice
008d8000-00ffc000 rwxp 00000000 00:00 0
028d7000-02931000 rwxp 00000000 00:00 0 [heap]
7f9adba92000-7f9adbc0c000 r-xp 00000000 08:06 688962 /lib/libc-2.11.1.so
7f9adbc0c000-7f9adbe0b000 ---p 0017a000 08:06 688962 /lib/libc-2.11.1.so
7f9adbe0b000-7f9adbe0f000 r-xp 00179000 08:06 688962 /lib/libc-2.11.1.so
7f9adbe0f000-7f9adbe10000 rwxp 0017d000 08:06 688962 /lib/libc-2.11.1.so
7f9adbe10000-7f9adbe15000 rwxp 00000000 00:00 0
7f9adbe15000-7f9adbe2b000 r-xp 00000000 08:06 688207 /lib/libgcc_s.so.1
7f9adbe2b000-7f9adc02a000 ---p 00016000 08:06 688207 /lib/libgcc_s.so.1
7f9adc02a000-7f9adc02b000 r-xp 00015000 08:06 688207 /lib/libgcc_s.so.1
7f9adc02b000-7f9adc02c000 rwxp 00016000 08:06 688207 /lib/libgcc_s.so.1
7f9adc02c000-7f9adc0ae000 r-xp 00000000 08:06 688967 /lib/libm-2.11.1.so
7f9adc0ae000-7f9adc2ad000 ---p 00082000 08:06 688967 /lib/libm-2.11.1.so
7f9adc2ad000-7f9adc2ae000 r-xp 00081000 08:06 688967 /lib/libm-2.11.1.so
7f9adc2ae000-7f9adc2af000 rwxp 00082000 08:06 688967 /lib/libm-2.11.1.so
7f9adc2af000-7f9adc3a5000 r-xp 00000000 08:06 412124 /usr/lib/libstdc++.so.6.0.13
7f9adc3a5000-7f9adc5a5000 ---p 000f6000 08:06 412124 /usr/lib/libstdc++.so.6.0.13
7f9adc5a5000-7f9adc5ac000 r-xp 000f6000 08:06 412124 /usr/lib/libstdc++.so.6.0.13
7f9adc5ac000-7f9adc5ae000 rwxp 000fd000 08:06 412124 /usr/lib/libstdc++.so.6.0.13
7f9adc5ae000-7f9adc5c3000 rwxp 00000000 00:00 0
7f9adc5c3000-7f9adc5c5000 r-xp 00000000 08:06 688966 /lib/libdl-2.11.1.so
7f9adc5c5000-7f9adc7c5000 ---p 00002000 08:06 688966 /lib/libdl-2.11.1.so
7f9adc7c5000-7f9adc7c6000 r-xp 00002000 08:06 688966 /lib/libdl-2.11.1.so
7f9adc7c6000-7f9adc7c7000 rwxp 00003000 08:06 688966 /lib/libdl-2.11.1.so
7f9adc7c7000-7f9adc7cb000 r-xp 00000000 08:06 688266 /lib/libuuid.so.1.3.0
7f9adc7cb000-7f9adc9ca000 ---p 00004000 08:06 688266 /lib/libuuid.so.1.3.0
7f9adc9ca000-7f9adc9cb000 r-xp 00003000 08:06 688266 /lib/libuuid.so.1.3.0
7f9adc9cb000-7f9adc9cc000 rwxp 00004000 08:06 688266 /lib/libuuid.so.1.3.0
7f9adc9cc000-7f9adc9e4000 r-xp 00000000 08:06 688987 /lib/libpthread-2.11.1.so
7f9adc9e4000-7f9adcbe3000 ---p 00018000 08:06 688987 /lib/libpthread-2.11.1.so
7f9adcbe3000-7f9adcbe4000 r-xp 00017000 08:06 688987 /lib/libpthread-2.11.1.so
7f9adcbe4000-7f9adcbe5000 rwxp 00018000 08:06 688987 /lib/libpthread-2.11.1.so
7f9adcbe5000-7f9adcbe9000 rwxp 00000000 00:00 0
7f9adcbe9000-7f9adcc09000 r-xp 00000000 08:06 688206 /lib/ld-2.11.1.so
7f9adcde9000-7f9adcdee000 rwxp 00000000 00:00 0
7f9adce05000-7f9adce08000 rwxp 00000000 00:00 0
7f9adce08000-7f9adce09000 r-xp 0001f000 08:06 688206 /lib/ld-2.11.1.so
7f9adce09000-7f9adce0a000 rwxp 00020000 08:06 688206 /lib/ld-2.11.1.so
7f9adce0a000-7f9adce0b000 rwxp 00000000 00:00 0
7fffcfc25000-7fffcfc3a000 rwxp 00000000 00:00 0 [stack]
7fffcfcc8000-7fffcfcc9000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
--------------------------------------------------------------------------------------------------------

What's next? Please don't say "Go back to Hamachi"!
Thanks,

Bluejay41

hi bluejay41,

I understand now why enabling log causes problems. We introduced a bug in v1.5 that affects Linux x64 builds when logging is enabled. It does not affect other builds in this release.
Please try installing our previous Free release v1.3. http://www.neorouter.com/downloads_nrfree_2526.html. It should not crash when you turn on logging.
Thank you for your patience.

Thanks,
Luke

Thanks, Luke, I will install that slightly older version first thing tomorrow!

Bluejay41