use of select() limits to max FD_SETSIZE=1024 - putting a low upper limit on tunnels #276
Description
Describe the bug
When ulimit -n is set > 1024, this can happen:
*** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated
With ulimit -n 1024, we run into "Unable to allocate PPPoL2TP socket." as a result of socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP); (in xl2tpd.c in our case) returning -1 with errno=EMFILE (according to strace).
Yes, we run a LOT of tunnels.
To Reproduce
Steps to reproduce the behavior:
- ulimit -n 16384 (example, should just be >1024).
- Start xl2tpd (xl2tpd -c /etc/xl2tpd/xl2tpd.conf -D)
- Initiate hundreds of incoming tunnels
- See error: *** bit out of range 0 - FD_SETSIZE on fd_set ***: terminated
Expected behavior
I expect it to handle thousands of connections successfully.
l2tp detail:
- x2ltpd version: 1.3.18 + Pass remotenumber to pppd. #248 + xl2tpd: Close calls when underlying pppd terminate. #261
xl2tpd.conf
[global] ; Global parameters:
port = 1701
auth file = /etc/xl2tpd/l2tp-secrets
rand source = dev
[lns default]
exclusive = no
assign ip = no
pass peer = yes
pppoptfile = /etc/ppp/options.l2tpd
** analysis **
The only place where this error can come from is when building the fdset in build_fdset():
network.c:396: FD_SET (tun->udp_fd, readfds);
network.c:415: FD_SET (call->fd, readfds);
network.c:438: FD_SET (server_socket, readfds);
network.c:441: FD_SET (control_fd, readfds);
select() is hard limited to file descriptors <FD_SETSIZE, which is 1024 and cannot be changed.
Ideally this should be switched to epoll() but portability is crap, which just leaves poll(). Unless we only care about Linux?