Connecting to server inside LAN and staying there!

Musti · Post by **Musti** » Thu May 19, 2005 8:21 pm

My problem is not really connecting to server.
It works well. From both inside and outside.
Problem is that sometimes only me if i connect from inside LAN get software caused connection abort or i ping out.

I know best way would be to use proxy outside server and come back to server so i could use router for out and in traffic only it seems to work pretty well.
Problem just is there aint really proxy servers much to spare.

Anyone had simultaneous problems and have solution for this?
I must go and pay for proxy bouncher to connect to my own server?

aquanight · Post by **aquanight** » Fri May 20, 2005 3:03 am

Most likely there's a problem with your LAN. Anytime your internet connection is more stable than your LAN, you have a problem with your LAN. Fix the problem and the droppage should go away.

Suchiara · Post by **Suchiara** » Fri May 20, 2005 2:44 pm

Musti: I was having the IDENTICAL problem since beta17 version (beta14 was fine). They did something in the code and it is ircd's problem, not your lan's.

btw, what is your unrealircd's configuration? Is it ssl compile or not?

There are several ways of fixing that:

1. the most quick/efficient way is to use another ircd (bahamut worked fine without any problems for me).
2. try di recompile without SSL if you have it enabled, but it is only abou ~50% chance that it will help.
3. Increase your 'users' class pingfrequency to 400 or something similar like that.

Good luck.

If you get solved your problem with one of these ways, plseace PrivateMessage me, thanks.

Matridom · Post by **Matridom** » Fri May 20, 2005 2:49 pm

Suchiara wrote:Musti: I was having the IDENTICAL problem since beta17 version (beta14 was fine). They did something in the code and it is ircd's problem, not your lan's.

btw, what is your unrealircd's configuration? Is it ssl compile or not?

There are several ways of fixing that:

1. the most quick/efficient way is to use another ircd (bahamut worked fine without any problems for me).
2. try di recompile without SSL if you have it enabled, but it is only abou ~50% chance that it will help.
3. Increase your 'users' class pingfrequency to 400 or something similar like that.

Good luck.

If you get solved your problem with one of these ways, plseace PrivateMessage me, thanks.

I've been connecting to an internal Unreal server for about 2 years now, the only time i get disconnected is when my wireless acts up.

connection aborts are more often caused by screwy windows or a network connection. Just cause you have a similar problem to someone else does not mean the program is at fault. Think of the hundreds/thousands of servers out there that are NOT having a problem?

I also notice no comments on what system is running the server (is it windows, linux?) no comment on how you connect internaly to the server (wired wireless, 10/100/1000?) What OS the connection computer is using(windows/linux?)

and for the record, i connect using ssl internaly exclusively. from a windows workstation to a linux server running through a linksys router.

Suchiara · Post by **Suchiara** » Fri May 20, 2005 3:11 pm

ok.. I know, but how could be explained that:
*If a user connects from the internet, not from my lan, it is ok--no ping timeout/software abort for more than a week
*if I lauch beta14 on the same server, no problem for lan users. But if I lauch beta17 or later-problem is back
*if I increase the pingfreq value on a new version of Unreal, problem is gone
*if I lauch another ircd on the same machine-no problems for lan users.

The problem happened when a users leaves his pc to idle. Not all users use windows and mirc--some of them (well, pretty much) use freebsd + xchat, others bitchx and some other clients (who use windoze) use some other chat program. trillian for example. mirc is used by ~55% of users. However, all of them had the same problems--if they left their pc to idle (not to talk in chat) for more than ~1 hour, they got ping timeout'ed.

My system is running Linux debian 2.6 kernel. It is a LAN, not WAN, 100 mbps (and a few parts 1000).

we don't use any routers on lan -- just a machine/router for internet sharing.

Matridom · Post by **Matridom** » Fri May 20, 2005 3:40 pm

Suchiara wrote:ok.. I know, but how could be explained that:
*If a user connects from the internet, not from my lan, it is ok--no ping timeout/software abort for more than a week
*if I lauch beta14 on the same server, no problem for lan users. But if I lauch beta17 or later-problem is back
*if I increase the pingfreq value on a new version of Unreal, problem is gone
*if I lauch another ircd on the same machine-no problems for lan users.

The problem happened when a users leaves his pc to idle. Not all users use windows and mirc--some of them (well, pretty much) use freebsd + xchat, others bitchx and some other clients (who use windoze) use some other chat program. trillian for example. mirc is used by ~55% of users. However, all of them had the same problems--if they left their pc to idle (not to talk in chat) for more than ~1 hour, they got ping timeout'ed.

My system is running Linux debian 2.6 kernel. It is a LAN, not WAN, 100 mbps (and a few parts 1000).

we don't use any routers on lan -- just a machine/router for internet sharing.

and if that one ping get's lost on the net (By all means, not unheard of) the client get's timed out. If you are actively chating, then you have a LOT more data to keep that connection open.

even a 1% packet loss is enough to cause software abortion errors and ping timeouts on idle people.

If it's truly the IRC, connect from local host and see what happens.

Suchiara · Post by **Suchiara** » Fri May 20, 2005 3:45 pm

it never times out the client from localhost machine

anyway, as I said, I solved that by increasing pingfreq up to 400

Matridom · Post by **Matridom** » Fri May 20, 2005 3:57 pm

Suchiara wrote:it never times out the client from localhost machine

if it never times out when you take the network away, does it mean the IRCD is NOT at fault?

and it is a common thing to do, increase the ping time, to lower disconnections because of a bad connection. (less pings, less chance of a ping getting lost)

Suchiara · Post by **Suchiara** » Fri May 20, 2005 4:32 pm

well, not going to argue cause I'm not a specialist on ircds

Matridom · Post by **Matridom** » Fri May 20, 2005 4:43 pm

Suchiara wrote:well, not going to argue cause I'm not a specialist on ircds

neither am i, but i do have a lot of specializiation in networking.

In all honesty, i would suspect a flacky nic or bad drivers on the IRCD server, i had that problems years ago when i was using a no-name NIC, upgraded to a 3com, they went away.

Musti · Post by **Musti** » Mon May 23, 2005 6:23 pm

Lets see.
[21:15] -irc.example.com- *** Notice -- Client exiting: Nick ([email protected]) [No route to host]
[21:15] *** Quits: Nick (No route to host)

I dont know why that happens. thats really what happens.
Another comp stayed online from same lan.
Sometimes it goes another way around.

I think problem is router not IRCD.
It just cant support too much traffic to simultaneously to LAN and to internet.
maby.

Server is Linux Fedora core 2.
Ping freq is 400.

LAN works fine on all machines and internet too...
I can SSH connect server from comp that gets no route to host, give it commands and upload and download stuff.
And no its not reason why it gets no route to host.

Weird stuff.

Best solution would be to find some proxy that works.
Or pay for one it seems.

Stealth · Post by **Stealth** » Mon May 23, 2005 10:18 pm

I have seen "No Route to Host" sometimes in place of a peer.

Winbots · Post by **Winbots** » Wed May 25, 2005 6:51 am

no route to host means that it is unable to find that ip... therefore unable to route the packet there....
peer means that it got the packet there.... but the client rejected the packet...
and ping means that the client didnt respond to the ping with a pong...

w00t · Post by **w00t** » Sun May 29, 2005 10:36 am

Increasing ping times can actually cause other problems, in terms of Software Caused Connection Abort (the error of d00m.)

As Winbots pointed out, that error means it can't find the addressed machine, I'd guess you have some faulty NIC or cable on your LAN somewhere - we had a problem at work a while back where one NIC was constantly sending ACKs out giving the rest of the machines HELL!.