Synchronet hangs before login prompt reddit / bbs ---------------------------------------------------------------------- FozzTexx · 2015-03-24 16:45 Trying to get Synchronet running on my Linux box so I can migrate off the IIgs. I compiled it all from scratch, and when I launch it and try to telnet in, the telnet session hangs. It prints out Synchronet BBS for Linux Version 3.16 Connection from: 10.4.0.197 and then just sits there. On the console if I get a node list it says Node 1: At logon prompt via telnet Node 2: Waiting for connection Node 3: Waiting for connection Node 4: Waiting for connection but no login prompt is ever printed. If I try to quit synchronet from the console it gets stuck trying to kill whatever is managing the telnet session and I have to kill -9. Added Mar 29: I've even connected via ssh and the exact same results, synchronet prints the banner and then hangs. The sbbs server says that it's waiting for login and when I try to quit sbbs it gets stuck saying Terminal Server thread still running Terminal Server thread still running Terminal Server thread still running Terminal Server thread still running over and over and I have to kill -9 it. Even if nothing ever connects and I quit as soon as I start it does that. It's starting to look like maybe Synchronet doesn't work under a 32bit distro. ---------------------------------------------------------------------- RealDeuce · 2015-03-24 19:41 Run "make" in the exec directory to compile the BAJA scripts. Also, there's a /r/synchronet now! ---------------------------------------------------------------------- FozzTexx · 2015-03-24 20:25 > Run "make" in the exec directory to compile the BAJA scripts. Already did that. ---------------------------------------------------------------------- RealDeuce · 2015-03-25 01:01 Did it work? Do you have the .bin files for all the .src files in there? ---------------------------------------------------------------------- FozzTexx · 2015-03-25 01:06 No it did not work. The bin files were already there. ---------------------------------------------------------------------- samalex01 · 2015-03-25 03:49 What distribution are you running? Also do you install all the prereqs? I just installed 3.16 on Linux Mint 16 two nights ago and it installed without any issues once I had all the required packages installed. http://wiki.synchro.net/install:nix:prerequisites ---------------------------------------------------------------------- FozzTexx · 2015-03-25 04:25 Yes all the prerequisites are installed, it won't compile without them. ---------------------------------------------------------------------- RealDeuce · 2015-03-25 04:46 What does data/error.log say? Also, what errors did you get when the make didn't work? EDIT: Also, what telnet client are you using? ---------------------------------------------------------------------- FozzTexx · 2015-03-25 05:08 The make worked fine, I thought you were asking if it solved my problem, which it did not since everything was already built. I'm using telnet for the telnet client. It connects to sbbs but sbbs hangs after printing the banner. data/error.log is empty. ---------------------------------------------------------------------- RealDeuce · 2015-03-25 05:13 And no errors are printed on the console? Can you try connecting to an IPv4 address instead of a hostname if you weren't before? ie: 127.0.0.1 for localhost. ---------------------------------------------------------------------- FozzTexx · 2015-03-25 14:30 That makes no difference. ---------------------------------------------------------------------- RealDeuce · 2015-03-25 19:56 Check your logs for errors. /var/log/messgaes ir whatever your distro uses. Try a different telnet client. "telnet" isn't a telnet client, and you never answered the question regarding the distro you use, so I can't find out what telnet you use. If there's options to disable auto-login and/or encryption, try that. ---------------------------------------------------------------------- [deleted] · 2015-03-25 20:26 [deleted] ---------------------------------------------------------------------- FozzTexx · 2015-03-25 20:29 telnet isn't a telnet client? Really? > man telnet TELNET(1) BSD General Commands Manual TELNET(1) NAME telnet — user interface to the TELNET protocol SYNOPSIS telnet [-468ELadr] [-S tos] [-b address] [-e escapechar] [-l user] [-n tracefile] [host [port]] DESCRIPTION The telnet command is used for interactive communica‐ tion with another host using the TELNET protocol. It begins in command mode, where it prints a telnet prompt ("telnet> "). If telnet is invoked with a host argument, it performs an open command implicitly; see the description below. I don't know why you're obsessed with my telnet client anyway, the problem isn't there. The problem is in the sbbs software which hangs after it gets a connection. It hangs so hard that I have to do a kill -9 on sbbs to get it to die because it's not able to clean up after itself. ---------------------------------------------------------------------- RealDeuce · 2015-03-25 23:57 If you know what the problem is, why are you asking for help? [Here](http://wiki.synchro.net/howto:support) is the right way to get Synchronet support. I'll be sure to not try and help you there since you are ignoring steps such as "check your log for errors" so that you can have an argument instead. It looks like you're using an old fork of a BSD telnet client. What codebase "telnet" is built from varies widely by various OSs. Windows telnet.exe is not the same code as the FreeBSD /usr/bin/telnet which is not the same as the RedHat /usr/bin/telnet and Debian distributes both the inetutils telnet as well as the netkit telnet, both of which can be ran as /usr/bin/telnet but this is through the alternatives system... they install with different names. I was hoping to help you find a set of flags that would indicate the problem, but you're not providing the information you're asked for so you're on your own perusing that avenue. If you ever check your logs and post them here, I may have other suggests. Enabling debug logging may also help. Not responding to information requests and instead trying to have an argument will not help. ---------------------------------------------------------------------- mro_1337 · 2015-03-27 04:22 check the console. ie the bbs console to see if it's shitting out any errors ---------------------------------------------------------------------- FozzTexx · 2015-03-27 04:29 Nothing on the console, nothing in any logs. ---------------------------------------------------------------------- mro_1337 · 2015-03-28 21:41 visit your bbs via telnet and then take a screenshot of the sbbs console and post it here please. ---------------------------------------------------------------------- FozzTexx · 2015-03-28 21:43 http://i.imgur.com/JrwLfDo.png ---------------------------------------------------------------------- chairmanmow · 2015-03-29 10:13 dude, a piece of advice as someone who's fairly handy with synchronet is that you're lucky you've got deuce on the line. i'm not sure he knows what your problem is based on the information you're providing or if he's going down the right path, but he will figure it out. if something were actually wrong with synchronet, he'd probably be the one to wind up changing the source. he's not just 'some guy' with an opinion who runs a synchronet bbs. that's most of everyone else in comparison to deuce. deuce and digitalman are the only two people who get a pass in my book to run a stock synchronet install and not be lamers. He was asking what your telnet client was to use it to help you debug your Synchronet install from the client, not implying that was the problem. He seems to be being fairly patient with you as well. If you're still having the problem or even if you aren't, and are still interested in running Synchronet, why not turn this conversation in the other direction a bit? ---------------------------------------------------------------------- mro_1337 · 2015-03-29 13:59 yeah, you're right doesnt show much. nuke it and recompile again. make sure your permissions are set correctly just incase. could be a fluke. also what linux distro are you using? ---------------------------------------------------------------------- FozzTexx · 2015-03-29 14:27 I've wiped it and rebuilt from scratch a couple of times, hasn't made any difference. Distro is Debian 7.8. ---------------------------------------------------------------------- mro_1337 · 2015-03-29 16:32 well it's working for other people, so that probably means you are the weak link in the chain, here. double check what you are doing and see if you didnt miss something. perhaps your os is damaged, perhaps your build didnt compile entirely. ---------------------------------------------------------------------- digitlman · 2015-04-04 00:19 After printing the "Connection from: " to the remote terminal, Synchronet will (optionally, but by default) resolve the hostname of the client's IP address. You can disable this behavior by adding the "NO_HOST_LOOKUP" option in your ctrl/sbbs.ini (i.e. in [BBS] Options). That said, if this is where the hang was occurring, I would expect to see "Resolving hostname..." on the terminal output, but that was not reported. Here is the relevant code (from main.cpp): sbbs->bprintf("Connection from: %s\r\n", host_ip); struct hostent* h; if(startup->options&BBS_OPT_NO_HOST_LOOKUP) h=NULL; else { sbbs->bprintf("Resolving hostname..."); h=gethostbyaddr((char *)&client_addr.sin_addr ,sizeof(client_addr.sin_addr),AF_INET); sbbs->putcom(crlf); } After that, Synchronet looks in the text/host.can for blocked IP addresses. Building a debug build and using gdb to break into the running code would certainly pinpoint exactly where the problem is, but I suspect it could be isolated just through judicious evaluation of log and console output (if one cares enough). A CPU utilization report of sbbs and its named-threads (e.g. using 'top -H') may also help provide some clue. Of course Synchronet normally works "under 32bit distro" and this is just a uniquely reported sighting. I'd be curious to get to the root cause of it, but it'll require some additional assistance from the reporter (FozzTexx). ---------------------------------------------------------------------- FozzTexx · 2015-04-04 00:45 I disabled the host lookup thinking that was where the problem was, but it was not and made no change. I considered pulling it up in gdb, but debugging threads in gdb is such a pain in the ass. I'm happy to do a debug build if you can tell me how. ---------------------------------------------------------------------- digitlman · 2015-04-04 11:26 The instructions for making a debug build are here: http://wiki.synchro.net/install:nix#notes Another possible help would be the output of 'lsof | grep sbbs' at the time of the hang. The contents of your ctrl/sbbs.ini file could be helpful as well. ---------------------------------------------------------------------- FozzTexx · 2015-04-04 19:15 [Here's the config](http://pastebin.com/cLi23kay) Here's what the sbbs process has open: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME Main 25019 bbs cwd DIR 0,15 4096 6414682 /sbbs/ctrl (10.4.0.1:/clients/mux/) Main 25019 bbs rtd DIR 0,15 4096 6144004 / (10.4.0.1:/clients/mux/) Main 25019 bbs txt REG 0,15 166077 8175638 /sbbs/src/sbbs3/gcc.linux.exe.release/sbbs (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 217016 6350893 /var/cache/nscd/group (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 217016 6350805 /var/cache/nscd/passwd (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 9844 6150928 /lib/i386-linux-gnu/libdl-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 245780 6147296 /usr/lib/i386-linux-gnu/libnspr4.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 17928 6147344 /usr/lib/i386-linux-gnu/libplc4.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 13800 6147392 /usr/lib/i386-linux-gnu/libplds4.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 1364104 6150925 /lib/i386-linux-gnu/libc-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 114788 6145230 /lib/i386-linux-gnu/libgcc_s.so.1 (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 148992 6150929 /lib/i386-linux-gnu/libm-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 938600 6148290 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.17 (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 116748 6150920 /lib/i386-linux-gnu/libpthread-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 86737 7880709 /sbbs/src/sbbs3/gcc.linux.lib.release/libservices.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 150346 7880708 /sbbs/src/sbbs3/gcc.linux.lib.release/libmailsrvr.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 124360 7880710 /sbbs/src/sbbs3/gcc.linux.lib.release/libwebsrvr.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 117990 7880707 /sbbs/src/sbbs3/gcc.linux.lib.release/libftpsrvr.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 7042991 7880705 /sbbs/src/sbbs3/gcc.linux.lib.release/libsbbs.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 9800 6151093 /lib/i386-linux-gnu/libutil-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs mem REG 0,15 117960 6150922 /lib/i386-linux-gnu/ld-2.13.so (10.4.0.1:/clients/mux/) Main 25019 bbs 0u CHR 136,3 6 /dev/pts/3 Main 25019 bbs 1u CHR 136,3 6 /dev/pts/3 Main 25019 bbs 2u CHR 136,3 6 /dev/pts/3 Main 25019 bbs 3r CHR 1,8 2392 /dev/random Main 25019 bbs 4u IPv4 68892 TCP *:9601 (LISTEN) Main 25019 bbs 5u IPv4 68897 TCP *:9622 (LISTEN) Main 25019 bbs 6u REG 0,15 60 8273983 /sbbs/ctrl/node.dab (10.4.0.1:/clients/mux/) Main 25019 bbs 7u REG 0,15 60 8273983 /sbbs/ctrl/node.dab (10.4.0.1:/clients/mux/) Main 25019 bbs 8r CHR 1,8 2392 /dev/random I haven't even connected to it yet and it refuses to quit because the terminal server thread won't die. I have to kill -9 sbbs. ---------------------------------------------------------------------- digitlman · 2015-04-04 20:48 No "Aha" moment yet. Your sbbs.ini looks fine. You are running sbbs as this 'bbs' user in the 'bbs' group, which is generally a good idea, but if sbbs was installed as a different user, that could introduce permissions issues. I suspect this might have something to do with permissions. The only actual *files* that sbbs has open at this stage appears to be the ctrl/node.dab, so it might be a good idea to take a good look at the permissions of that directory and file. And maybe even try running sbbs as root, as a test. You could also experiment with the exec/node utility and see if you can modify the node.dab using that tool while logged in as 'bbs'. If you can't (e.g. experience a similar hang as you see with sbbs), then I think that would very much narrow it down. -Rob ---------------------------------------------------------------------- FozzTexx · 2015-04-04 21:04 The whole thing was built in an empty /sbbs dir under the bbs user, there's no permissions problems. Everything is owned by bbs and has read/write for the bbs user. Running as root changes nothing, it still hangs in the same way. I'm able to get status with exec/node and mark nodes as down. ---------------------------------------------------------------------- digitlman · 2015-04-05 04:04 Then I guess the next step is to break into the hung process using gdb (and a debug build of sbbs). There on instructions on how to use gdb with sbbs here: http://wiki.synchro.net/howto:gdb -Rob ---------------------------------------------------------------------- digitlman · 2015-04-10 00:32 Or the problem will just go unresolved. You could create a user account on your Debian system for Deuce or I and we could likely get it working in short order. I run Debian myself and obviously haven't seen this particular issue. I imagine the solution will be a simple one once the cause is determined. ---------------------------------------------------------------------- FozzTexx · 2015-04-10 02:15 I got it compiled for debug but trying to deal with threads in gdb is where I gave up. I've always hated trying to deal with threads in gdb. Giving you access isn't the easiest because the computer is behind my firewall. Let me see what I can do. ---------------------------------------------------------------------- digitlman · 2015-04-10 20:15 Break into the process with gdb (e.g. "gdb /sbbs/exec/sbbs "), then type "info threads" and paste the output here. That'll give us a good start. If you're going to run a publicly accessible BBS, then you'll have to figure out how to configure firewall exceptions and possibly NAT port- forwarding anyway. :-) ---------------------------------------------------------------------- FozzTexx · 2015-04-10 20:43 0xb6e15037 in select () from /lib/i386-linux-gnu/libc.so.6 (gdb) info threads Id Target Id Frame 6 Thread 0xb6c89b70 (LWP 6569) "Signal Handler" 0xb6fd2cf8 in do_sigwait () from /lib/i386-linux-gnu/libpthread.so.0 5 Thread 0xb6489b70 (LWP 6570) "BBS" 0xb6e15037 in select () from /lib/i386-linux-gnu/libc.so.6 4 Thread 0xb5c89b70 (LWP 6571) "Services" 0xb6fd1d71 in read () from /lib/i386-linux-gnu/libpthread.so.0 3 Thread 0xb4c89b70 (LWP 6573) "Node Output" 0xb6fcf3a4 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i386-linux-gnu/libpthread.so.0 2 Thread 0xb4489b70 (LWP 6574) "BBS" 0xb6fd1d71 in read () from /lib/i386-linux-gnu/libpthread.so.0 * 1 Thread 0xb6cf58e0 (LWP 6568) "Main" 0xb6e15037 in select () from /lib/i386-linux-gnu/libc.so.6 ---------------------------------------------------------------------- digitlman · 2015-04-10 22:27 It's blocking trying to read a random number (4-bytes) from /dev/random. Synchronet reads from /dev/random to seed the random number generator and for some reason your system doesn't have enough entropy to provide a random number, so the read() call is blocking. You can reproduce this yourself by just trying to 'hd /dev/random'. Normally, this will return random data in a trickle. For some reason, on your system, it hangs indefinitely. Deuce is working on a patch to avoid this blocking read in sbbs (he's more familiar with the *nixy RNG stuff), but you should investigate why your system isn't providing random numbers. Other security or cryptographic software may have similar issues until this is resolved (at a system level). ---------------------------------------------------------------------- FozzTexx · 2015-04-10 23:01 Is there some reason you aren't using /dev/urandom? ---------------------------------------------------------------------- digitlman · 2015-04-10 23:05 We do use /dev/urandom, just not there. Deuce can answer more accurately, but I believe the reason urandom is not used for seeding the RNG is because urandom does not return cryptographically strong random numbers (in the words of the man page "theoretically vulnerable to a cryptographic attack"). ---------------------------------------------------------------------- FozzTexx · 2015-04-10 23:07 Since there's nothing cryptographic about telnet, I'm not sure why that matters. [Also this.](http://www.2uo.de/myths-about-urandom/) ---------------------------------------------------------------------- FozzTexx · 2015-04-10 23:17 Rebuilt it with your fixes, still hangs. Also tried switching everything to /dev/urandom, still hangs. Edit: rebuilt the debug version again and it's now working! YAY! I can finally run the BBS on the right box. ---------------------------------------------------------------------- digitlman · 2015-04-10 23:22 We use random numbers for all sorts of things that are not Telnet- specific, for example, generating random passwords. Telnet uses passwords. ---------------------------------------------------------------------- digitlman · 2015-04-11 00:20 Cool, good to hear. The random number stuff is on the to-do list for an overhaul in the near future and this will provide a lesson to be considered at that time: sometimes, on some systems, /dev/random actually will block... for a long time... perhaps forever. :-) ---------------------------------------------------------------------- FozzTexx · 2015-04-11 00:45 Yah it looks like it's some kind of kernel bug. If it ever makes it all the way down to 0, nothing will fix it except for a reboot. And I can't upgrade the kernel because at some point the support for the ISA Boca 2016 16 serial port card got borked and newer kernels just don't work. ---------------------------------------------------------------------- RealDeuce · 2015-04-11 01:05 Regading that: > I'm mostly talking about reasonably recent Linux systems, not other UNIX-like systems. Synchronet is not "a Linux program", it's cross-platform, so any discussion which excludes most systems is of less use. The whole random infrastructure in Synchronet is slated for an overhaul after the next release. Likely moving to arc4random() for platforms which support it, and whatever alternative exists for those that don't. We also have Cryptlib now, which includes various random function which it may make sense to use for all of the cryptographic stuff, not just SSL and SSH. As for telnet, there's nothing about telnet which uses random numbers either. This is not about telnet in any way. ---------------------------------------------------------------------- FozzTexx · 2015-04-11 02:10 > This is not about telnet in any way. And yet you wouldn't listen to me when I tried to tell you that earlier and all you wanted to do was find flags that would make my telnet client work. :-P ---------------------------------------------------------------------- RealDeuce · 2015-04-11 02:39 You were talking about a hang when you made a telnet connection, it was a logical place to look.