13 Feb, 2007, Kal wrote in the 1st comment:
Votes: 0
All right, I finally managed to get it working. In case someone else has this problem, here's what finally seemed to work.
    use imcconfig serveraddr <ip number> to change the DNS info to the IP number
    hotboot the mud
    *may be optional* It didn't auto connect for me, so I used imcconnect


It seems to be working perfectly, now.

Thank you, everyone, for your help.

Kal said:
Okay. I'm officially stumped. I've loaded up and compiled SmaugFUSS 1.7 on my server. Everything runs fine. I decided to join IMC2, so I filled out the form on the site here, and setup my config file. I tried to connect, and go the DNS error in the log file (IMC: imc_connect_to: Cannot resolve server hostname). I decided to try the IP instead.

It seemed to work fine, according to the log, but I can't do anything once it connects. I cannot issue any commands to the mud (and the mud was still running, according to the proccess list). I even tried disabling SHA256, but that didn't seem to help anything. According to the server/client list from IMC (checking from Talon), my mud shows up (smdev. I think I screwed something up because it's on two servers) as having connected last night. I keep trying to rack my brain, and come up with a reason for this, but I can't think of anything.

This is my current imc config file:
$IMCCONFIG

# IMC2 Freedom CL-2.1a SmaugFUSS 1.7 config file.
# This file can now support the use of tildes in your strings.
# This information can be edited online using the 'imcconfig' command.
LocalName smdev
Autoconnect 1
MinPlayerLevel 0
MinImmLevel 0
AdminLevel 65
Implevel 65
InfoName SpellMudDev
InfoHost 66.218.49.114
InfoPort 8800
InfoEmail raistlin.spellmud@yahoo.com
InfoWWW http://spellmud.arthmoor.com
InfoBase SmaugFUSS 1.7
InfoDetails SpellMud is currently in development. More information will be made available at a later date.

# Your server connection information goes here.
# This information should be available from the network you plan to join.
ServerAddr server02.intermud.us
ServerPort 9000
ClientPwd <EDITED OUT>
ServerPwd <EDITED OUT>
#SHA256 auth: 0 = disabled, 1 = enabled
SHA256 0
End

$END

Thank you for any help you can give me.


Edit: Don't post passwords.
13 Feb, 2007, Omega wrote in the 2nd comment:
Votes: 0
server02 is down at the moment. :(

atleast thats the last i heard. i'd recommend using another one of the servers.
13 Feb, 2007, Guest wrote in the 3rd comment:
Votes: 0
Use the IP address instead. The intermud.us domain is still held up in registrar problems. Server02 is definitely not down right now.
13 Feb, 2007, Kal wrote in the 4th comment:
Votes: 0
I've tried to use the IP. That's when the mud… um, I don't know how to describe it, other than it's like continuous lag. There is no response from any command sent to the mud. I'm sorry, my Config file is miss-leading in this regard. I had to change it back to the DNS name in order to restart the mud, and have access to it.
16 Feb, 2007, Conner wrote in the 5th comment:
Votes: 0
I seem to be having the same problem today. I lost imc at 15:44 EST and at 17:50 EST I tried to reconnect after changing which server (by IP, not domain name since I can't reach any of the intermud domains currently at all) we're using and it sent the mud into a continuous loop. I had to kill the mud and edit the imc.config file so the mud wouldn't try to auto-connect before I could restart the mud without the continuous loop. :sad:
17 Feb, 2007, kiasyn wrote in the 6th comment:
Votes: 0
Server02 seems down. Server01 and Server03 seem to be functioning normally.
17 Feb, 2007, Conner wrote in the 7th comment:
Votes: 0
When I set my mud to use server02 (it's norm) it can't connect, it's when I try to switch it to server01 or server03 that it locks up on me. :(
17 Feb, 2007, Kayle wrote in the 8th comment:
Votes: 0
It doesn't seem to matter which one I use. MW hangs and won't do a damn thing until I kill it. GDB shows that the last thing it manages to do before hanging is ucache data, which if I remember correctly was a server side problem involving a password when I was working on that SWFotE base for that friend. I didn't GDB Server01 or 03. but that's only because I'm supposed to be on vacartion and not working on anything MUD Related. :tongue:
17 Feb, 2007, Conner wrote in the 9th comment:
Votes: 0
Sounds like what was happening to me too, Kayle. Though we got back up last night when Samson got Server02 back up. Best we can tell, since I hadn't tried to backtrace the continuous loop while it was happening, is that it was connecting and the mud was waiting on the server to respond with the ucache confirmations and server01/03 were waiting on server02 to respond, but server02 was down. Samson has asked Kiasyn to write a server-side patch so the imc servers will notify each other if one stops responding so that the other two can effectively pick up the slack and continue operations without the need for the one that's down.
20 Feb, 2007, Kayle wrote in the 10th comment:
Votes: 0
Sounds good. I'll be back sometime next week. :tongue:
21 Feb, 2007, Kayle wrote in the 11th comment:
Votes: 0
Maybe not. I check while I was sitting here in class, and MWDev is connected, but MalevWhisp is still going into the infinite loop when trying to connect. Maybe someone else has some ideas? or maybe I should just ask Samson to purge the Info for MalevWhisp from the server and see if it allows it to connect? I'll attempt to do some stuff when I get home, but I'm not expecting very good results.
21 Feb, 2007, Guest wrote in the 12th comment:
Votes: 0
Honestly I have no idea why it would be in an infinite loop. That might be because nobody has bothered to expand on that, leaving me to speculate your mud must be caught in a temporal vortex from which there is no escape. Or perhaps it's being continuously abducted by aliens who delight in making you think it never started up. I couldn't say. Some kind of something would be incredibly helpful in narrowing this down to a terrestrial problem.
21 Feb, 2007, Conner wrote in the 13th comment:
Votes: 0
Ok, should the problem strike my mud again, I'll try to see if I can catch a backtrace for you.
22 Feb, 2007, Kayle wrote in the 14th comment:
Votes: 0
I'll see if I can get you a backtrace ina bit after Venia leaves for work and I can actually get on there to work. >.>
22 Feb, 2007, Kayle wrote in the 15th comment:
Votes: 0
Alright, here's the backtrace for the loop.

(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.
0x40104b36 in recv () from /lib/libc.so.6
(gdb) bt
#0 0x40104b36 in recv () from /lib/libc.so.6
#1 0x0806c44d in imc_read_socket () at imc.c:3370
#2 0x0806c7b0 in imc_loop () at imc.c:3465
#3 0x081288f5 in game_loop () at comm.c:939
#4 0x08127ac2 in main (argc=2, argv=0xbffffb34) at comm.c:551
#5 0x4004254d in __libc_start_main () from /lib/libc.so.6
(gdb) frame 0
#0 0x40104b36 in recv () from /lib/libc.so.6
(gdb) frame 1
#1 0x0806c44d in imc_read_socket () at imc.c:3370
3370 nRead = recv( this_imcmud->desc, this_imcmud->inbuf + iStart, sizeof( this_imcmud->inbuf ) - 10 - iStart, 0 );
(gdb) list
3365
3366 for( ;; )
3367 {
3368 int nRead;
3369
3370 nRead = recv( this_imcmud->desc, this_imcmud->inbuf + iStart, sizeof( this_imcmud->inbuf ) - 10 - iStart, 0 );
3371 iErr = errno;
3372 if( nRead > 0 )
3373 {
3374 iStart += nRead;
(gdb) info locals
nRead = 0
iStart = 37
iErr = 2
begin = 0 '\0'
(gdb) frame 2
#2 0x0806c7b0 in imc_loop () at imc.c:3465
3465 if( !imc_read_socket( ) )
(gdb) list
3460 return;
3461 }
3462
3463 if( FD_ISSET( this_imcmud->desc, &in_set ) )
3464 {
3465 if( !imc_read_socket( ) )
3466 {
3467 if( this_imcmud->inbuf && this_imcmud->inbuf[0] != '\0' )
3468 {
3469 if( imc_read_buffer( ) )
(gdb) info locals
in_set = {__fds_bits = {128, 0 <repeats 31 times>}}
out_set = {__fds_bits = {128, 0 <repeats 31 times>}}
last_time = {tv_sec = 1172187384, tv_usec = 973046}
null_time = {tv_sec = 0, tv_usec = 0}
(gdb)


Now, Here's GDB of the startup, me logging in, and typing imcconnect.
Thu Feb 22 17:41:15 2007 :: IMC: Loading IMC2 command table…
Thu Feb 22 17:41:15 2007 :: IMC: Loading IMC2 network data…
Thu Feb 22 17:41:15 2007 :: IMC: Loading IMC2 help file…
Thu Feb 22 17:41:15 2007 :: IMC: Loading IMC2 color table…
Thu Feb 22 17:41:15 2007 :: IMC: Loading IMC2 who template…
Thu Feb 22 17:41:15 2007 :: IMC: imcfread_word: EOF encountered on read.
Thu Feb 22 17:41:15 2007 :: IMC: IMC2 network data loaded. Autoconnect not set. IMC2 will need to be connected manually.
Thu Feb 22 17:41:15 2007 :: Malevolent Whispers ready on port 1070.
Thu Feb 22 17:41:16 2007 :: Sock.sinaddr: 99.999.99.999, port 2545.
Thu Feb 22 17:41:16 2007 :: Preloading player data for: Kayle (15K)
Thu Feb 22 17:41:17 2007 :: Loading player data for: Kayle (15K)
Thu Feb 22 17:41:17 2007 :: Kayle (c-99-999-99-999.hsd1.pa.comcast.net) has connected.
Thu Feb 22 17:41:24 2007 :: IMC: Loading IMC2 network data…
Thu Feb 22 17:41:24 2007 :: IMC: IMC2 network data loaded.
Thu Feb 22 17:41:24 2007 :: IMC: IMC2 Network Initializing…
Thu Feb 22 17:41:24 2007 :: IMC: Connecting to server.
Thu Feb 22 17:41:24 2007 :: IMC: Loading channels…
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:icode as icode
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:igame as game
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:i3chat as i3
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:i2chat as i2
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:irc as irc
Thu Feb 22 17:41:24 2007 :: IMC: configured Server02:inews as inews
Thu Feb 22 17:41:24 2007 :: IMC: configured Server01:ichat as ichat
Thu Feb 22 17:41:24 2007 :: IMC: configured Server01:pchat as pchat
Thu Feb 22 17:41:24 2007 :: IMC: configured Server01:ibuild as ibuild
Thu Feb 22 17:41:24 2007 :: IMC: Loading ban list…
Thu Feb 22 17:41:24 2007 :: IMC: Loading ucache data…

Program received signal SIGINT, Interrupt.
0x40104b36 in recv () from /lib/libc.so.6
(gdb) k
Kill the program being debugged? (y or n) y
(gdb) quit


I dunno what to make of it, maybe you can.
23 Feb, 2007, kiasyn wrote in the 16th comment:
Votes: 0
Unsure but I -think- this may be the offending code.
if( connect( desc, ( struct sockaddr * )&sa, sizeof( sa ) ) < 0 )
{
if( errno != EINPROGRESS )
{
imclog( "%s: Failed connect: Error %d: %s", __FUNCTION__, errno, strerror( errno ) );
perror( "connect" );
close( desc );
return -1;
}
}


EINPROGRESS said:
The socket is non-blocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure).
11 Mar, 2007, Kasji wrote in the 17th comment:
Votes: 0
I just set up IMC2 on my SWR 1.2 FUSS, and I am getting this exact same problem as shown in the gdb and mud logs above. I've also tried replacing the server domain address with the server IP address. This is happening to me on server01. It seems the code gets stuck trying to read a blocked socket. Only problem is, it never receives anything to read.

Edit: Oh, I'm using the IMC2 Freedom CL-2.1a.
11 Mar, 2007, Guest wrote in the 18th comment:
Votes: 0
What mud name did you attempt to connect with? We can't really do much without at least minimal information. We don't need your whole config, just the localname you set the mud to, and what server you tried to connect to.
11 Mar, 2007, Conner wrote in the 19th comment:
Votes: 0
FWIW, I find the best results with server02 myself.
11 Mar, 2007, Kasji wrote in the 20th comment:
Votes: 0
LocalName: SWGalaxyCore
ServerAddr: server01.intermud.us (and also tried 209.190.9.170)
ServerPort: 5000
SHA256: 1
0.0/32