Connection not registering

Posted by Shawncplus on Fri 20 Apr 2007 03:42 AM — 12 posts, 34,070 views.

USA #0
I had this problem start a couple days ago. I shutdown the MUD to do some changes and after I compiled and restarted the server it ran fine until I tried to connect. In GMud I get the connection message "%%% Connected to 127.0.0.1 on port 4000."
After that the connection is not registered, the greeting doesn't show up nor does the server actually show me connecting. I have no idea what's causing it, I've tried doing a make clean then recompiling and nada. I've also deleted the executable and remade, nada their either.
Any hints (I've already tried disabling my firewall and everything else with my network settings)?
Amended on Fri 20 Apr 2007 03:43 AM by Shawncplus
USA #1
Infinite loop perhaps? Attach gdb and see what it's doing.
USA #2
Yeah, I've tried getting gdb a number of times today and setup.exe just doesn't like to let me connect so I'll be going without for a while until I get back to my apartment.
USA #3
Well since you're connecting to localhost, it's probably not a firewall issue. Er, what's setup.exe?
USA #4
It's what cygwin uses to get new packages, it has wget but I'm used to using apt-get so I didn't mess with it. GDB isn't installed already. As for the firewall issue it can't be because I've disabled both of my firewalls, Windows and Zonealarm. I can't tell what the change is because I didn't ACTUALLY change anything even remotely dealing with login.
Australia Forum Administrator #5
A loop could be practically anywhere, for example in the output routine, where it tries to send the welcome message but loops processing colour codes or something.

Is the CPU usage on the offending machine very high when you try to connect?
USA #6
I told him to try a normal stock MUD. It still hangs, so it may be a Cygwin problem since I doubt it's a specific problem with that MUD.
Australia Forum Administrator #7
Maybe it is doing a reverse DNS lookup, and taking ages to find a name server.
USA #8
Would that happen using localhost?
USA #9
It isn't using any extra resources, and the DBSaga server had the same problem when I ran it. I've tried changing ports as I've told Zeno and still nothing. I didn't change anything dealing with cygwin so I'm not sure what's happening.
Australia Forum Administrator #10
Is this SMAUG?

Your problem vaguely rang a bell with me, and a bit of research revealed I had a similar problem a while back, however this was with a MUD from Ron Penton's book "MUD Game Programming".

It would compile OK, and start up, but when I connected, nothing happened (however no CPU loop either).

Some lengthy debugging revealed an "out by one" error in the code that handled new connections.

These are the diffs of the change:


diff -c -r Libraries/SocketLib/SocketSet.h Libraries.fixed/SocketLib/SocketSet.h
*** Libraries/SocketLib/SocketSet.h     2005-12-07 13:22:58.000000000 +1100
--- Libraries.fixed/SocketLib/SocketSet.h       2005-12-07 13:19:18.000000000 +1100
***************
*** 39,46 ****
              #ifdef WIN32
                  return select( 0, &m_activityset, 0, 0, &t );
              #else
!                 if( m_socketdescs.size() == 0 ) return 0;
!                 return select( *(m_socketdescs.rbegin()), &m_activityset, 0, 0, &t );
              #endif
          }

--- 39,46 ----
              #ifdef WIN32
                  return select( 0, &m_activityset, 0, 0, &t );
              #else
!               if( m_socketdescs.size() == 0 ) return 0;
!                 return select( *(m_socketdescs.rbegin()) + 1, &m_activityset, 0, 0, &t );
              #endif
          }


Now if this is stock SMAUG it won't help much, however it might help to put some debugging displays around where it does the select.

Effectively what is happening here is that the new connection triggers off a call to the part that checks which sockets have connected, but the select call does not check enough of them. From "man select":


       int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
       struct timeval *timeout);



And the explanation of "n" is:


       n  is the highest-numbered descriptor in any of the three sets, plus 1.


The code I had was giving the highest numbered descriptor, so I added 1 so it would be "plus 1".

Maybe that won't help. But maybe if someone is trying to get Ron Penton's MUD working, it might. :)
Amended on Fri 20 Apr 2007 05:47 AM by Nick Gammon
USA #11
Yeah it's SmaugFUSS. I was thinking it was something with the code but if another base is having the same problem I'm thinking it's something with cygwin. I probably wont be able to figure it out until Sunday or Monday when I actually get my cable connection back and get the GDB package.