# [Solved] Lots of disconnects from IRC

## ALF__

Hello,

So thought I would give the old IRC a go after many years.

So I'm using irssi to connect o libera chat.

It works, however, i often get disconnected, 2-3 times per hour which is not acceptable.

I have no idea whats causing this. I even attempted to use efnet for a while just to diagnose, it is the same thing.

My router is a vanilla Pfsense setup. First i thought it was the local DHCP server lease time that was to short, so I upped it to 24 hours, however it is the same.

I have also tried to connect via plain text (not secure connection) and that results in the same thing.

When the disconnect happen, I can see the lag value in irssi rise, and during that time I can for example ping libera chat from a separate terminal.

I have not noticed any other services that is experiencing this, when it happens I can still ping around the world and streaming works fine etc.

The only idea still left is that my ISP is using a CGNAT, but i would be surprised if that was it?

This has probably nothing to do with Gentoo it self, but maybe someone has any ideas?Last edited by ALF__ on Fri Sep 16, 2022 6:29 pm; edited 1 time in total

----------

## ALF__

Just did a pcap of it,

Not showing to much, especially since this session was secure.

But it seems like my client is attempting the ping, as a package with this length is appering quite a lot.

After that I get several packages with "re-transmission"

But nothing much more..

----------

## Banana

did you try it with an alternative client?

----------

## ALF__

Good idea  :Very Happy: 

I just emerged "hexchat".. Lets see how that one is doing after a while.

If it is client bound it will be very interesting to know why to say the least..

----------

## ALF__

Yep, same behavior with hexchat. Disconnects after 90 seconds of no ping response..

So it is not tied to the client then and not server apparently since it is happening both on two different networks..

Any other ideas?

----------

## NeddySeagoon

ALF__,

Are you in any channels with me?

I will have your connect/disconnect messages in my logs.

----------

## ALF__

Hey!

I'm in #gentoo on liberachat. known as alf__ currently

I guess you will only see that i left due to ping timeout or such?

----------

## allcode

Hey!

contact with customer care executive.

----------

## eccerr0r

Likely it's one of the routers between you and the IRC server, likely either your on-premise router or your isp router does not like long idle TCP connections and decides to drop them.  Yes if someone is in the channel with you, seeing idle timeout or connection resets are clues.

Options are

1. Increase timeout before dropping connections on the routers if you're in control of the router that's dropping connections.  This will increase memory utilization of the router and make it more likely you're going to run out of NAT ports if you're using NAT.  But this works only if you control the router that's dropping connections.

2. Do not use NAT.  This is a rarely helpful option as many people are forced to use NAT.

3. Fake activity that looks like a human to the IRC server every so often, but it needs to be random - some ISPs detect constant rate pings and assumes it's a robot and disconnects you.

4. Find a session-holding IRC bouncer on a host that has a stable, non-NAT connection.

5. IPV6, so you can avoid NAT.

There are probably more... I thought of another one but forgot.

----------

## logrusx

Are you using WiFi or a wire?

What's your network adapter?

Do you have stable ping delays to/from your router? What about to/from other network devices?

Regards,

Georgi

----------

## ALF__

Hello everyone,

Thank you for your input.

After somewhat deep investigation including pcaps both on my routers end and my client, I was able to see my client traffic being transmitted and with no reply from the server, getting re-transmitted.

Further digging showed that sometimes when this occured my routers state-table still had the state as "established" but in the same time the firewall was blocking the traffic incoming.

This indicated to us that the CGNAT used by the ISP to save ipv4 adresses probably dropped the state.

Furthermore, this was more apparent during high peak hours as in the afternoon, and almost never happened during night time.

I called up my ISP and got to talk to a very knowledgeable person that appreciated the troubleshooting already done on my side and they shifted me over to a public IP instead.

The error went away instantly and connection is super stable.

Again, thanks for all your input as always!

Special thanks to NeddySeagoon that helped me check some stuff on the IRC side.

Best regards,

alf__

----------

## eccerr0r

lucky you can get a public IP and get rid of NAT just like that, wish more ISPs would do that without being charged an additional fee...  they do NAT specifically because they ran out of IPv4 addresses.

I ssh to my home machines from my phone frequently.  When connecting via IPv4, I get dropped very frequently, usually within 15 minutes or so.  When using IPv6 that does away with NAT, I've seen very long duration connections, seen connections for hours quite frequently, once I forgot and it's been maintained for almost a day.

----------

