edge: *** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated

[HMKnapp]

First of all, thanks for n2n, I love it for being such an easy to use, no nonsense solution that "just works".

Today I switched to edge TCP -S2 because my ISP currently has issues and UDP became unusable.

Since then I noticed frequent crashes which did not occur before. I must add I have no evidence this is strictly related to TCP mode, could be a coincidence or also related to my ISP's network issues, huge packet loss.

23/Mar/2024 20:05:24 [edge_utils.c:3564] adding supernode = o-arch-24G-200:7777
23/Mar/2024 20:05:24 [edge.c:1072] WARNING: switching to AES as key was provided
23/Mar/2024 20:05:24 [edge.c:1112] starting n2n edge 3.1.1 Jan 29 2023 21:01:43
23/Mar/2024 20:05:24 [edge.c:1115] using OpenSSL 3.2.1 30 Jan 2024
23/Mar/2024 20:05:24 [edge.c:1118] using compression: lzo1x.
23/Mar/2024 20:05:24 [edge.c:1119] using AES cipher.
23/Mar/2024 20:05:24 [edge_utils.c:399] number of supernodes in the list: 1
23/Mar/2024 20:05:24 [edge_utils.c:401] supernode 0 => o-arch-24G-200:7777
23/Mar/2024 20:05:24 [edge_utils.c:490] successfully created resolver thread
23/Mar/2024 20:05:24 [edge_utils.c:495] successfully created port mapping thread
23/Mar/2024 20:05:24 [edge.c:1143] use manually set IP address
23/Mar/2024 20:05:24 [edge.c:1258] created local tap device IP: 192.168.111.3, Mask: 255.255.255.0, MAC: 6A:22:5B:3C:F1:02
23/Mar/2024 20:05:24 [edge.c:1330] dropping privileges to uid=65534, gid=65534
23/Mar/2024 20:05:24 [edge.c:1356] edge started
23/Mar/2024 20:05:24 [edge_utils.c:2508] [OK] edge <<< ================ >>> supernode
23/Mar/2024 20:05:26 [n2n_port_mapping.c:212] UPnP added TCP port mapping: 0.0.0.0:36515 -> 192.168.0.237:36515
23/Mar/2024 20:05:26 [n2n_port_mapping.c:222] UPnP added UDP port mapping: 0.0.0.0:36515 -> 192.168.0.237:36515
*** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated
Aborted

(compression on or off made no difference)

For reference:

UDP mode (has never crashed, uptime several days)

--- 192.168.111.1 ping statistics ---
50 packets transmitted, 13 received, 74% packet loss, time 49581ms
rtt min/avg/max/mdev = 20.533/26.358/40.860/6.088 ms

TCP mode saves the day during ISP issues, but crashes randomly

--- 192.168.111.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19206ms
rtt min/avg/max/mdev = 24.106/1806.716/6678.278/1958.051 ms, pipe 7

[hamishcoleman]

Are you able to retest this against the recently released fork n3n and raise a ticket there if it is still happening? Whilst there has been less testing with the TCP mode, we still want to make sure it is working as part of that new project.

[HMKnapp]

I only now became aware of your fork. I will test it and likely switch over to n3n when my ISP starts losing UDP packets again and I have to use the TCP mode. Until then I abide by never change a running system.

N3N will likely show the same issue, see [1]. It may be an easy fix though, not sure. [2]

[1] https://github.com/n42n/n3n/blob/f94e148de6854281752d8a2430a4be9fc696831f/src/n2n_port_mapping.c#L327 [2] https://stackoverflow.com/a/27065458

[hamishcoleman]

Makes sense to me - changing something working always has its own risks.

The error message you are seeing may not be nearby the line number of the log message, but we can try and debug that over on a n3n issue if you discover this happening again.

[nkxingxh]

Are you able to retest this against the recently released fork n3n and raise a ticket there if it is still happening? Whilst there has been less testing with the TCP mode, we still want to make sure it is working as part of that new project.

I also had this problem, but unfortunately it only reproduced on one of my machines (debian 12), and again no problem on the others (debian 11 and rockylinux 8). I now suspect that there is something wrong with the system environment on this machine as well

version: n3n 3.3.3 (n3n_3.3.3-1_amd64.deb)