Browsers show blank page on Linux based distros
Hey!
I've looked everywhere for a solution and couldn't find anything so here goes. We have the following situation: We have two wi-fi networks from two separate ISPs and the issue occurs on both. Any number of windows PCs can connect to cPanel/WHM with no issues. However, only one computer running a Linux distro at a time can reach the cPanel/WHM interface. When the second (or third) one tries to connect, it just shows a blank page. Ping and mtr show no issues, but the browser just remains in an infinite loading loop. We've reproduced the issue on both wi-fi networks, using multiple Linux distros.
And after the first connection is made from the first linux distro laptop, the second connection doesn't even reach the server, as nothing appears in access or error logs
The issue has also been reproduced by one of our clients, also on Linux PCs.
We have tested this through a mobile hotspot connection and everything worked fine.
Any ideas guys?
-
Hello, To clarify, are these computers connecting from the same network? Do you notice any error messages in /usr/local/cpanel/logs/login_log or /usr/local/cpanel/logs/error_log when this happens? Thank you. 0 -
Hello! Yes, these computers are connected to the same network. It's been tested with wi-fi, cable and wi-fi + cable. The error_log shows nothing and the login_log only displays the one successful connection. 0 -
Hello, Are you using any firewalls on the local machines or on the cPanel/WHM server? If so, does the issue persist when they are temporarily disabled? Thank you. 0 -
Hello, It wasn't iptables nor CSF + LFD. The problem resided in an IPv4 tuning we did some years ago in /etc/sysctl.conf. The problematic tuning was the IPv4 tuning done below: # Kernel sysctl configuration file for Red Hat Linux # # For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and # sysctl.conf(5) for more details. # Controls IP packet forwarding net.ipv4.ip_forward = 0 # Controls source route verification net.ipv4.conf.default.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Controls the System Request debugging functionality of the kernel kernel.sysrq = 0 # Controls whether core dumps will append the PID to the core filename. # Useful for debugging multi-threaded applications. kernel.core_uses_pid = 1 # IPv4 tuning net.core.netdev_max_backlog = 10000 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_rmem = 10240 87380 12582912 net.ipv4.tcp_wmem = 10240 87380 12582912 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_sack = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_probes=9 net.ipv4.tcp_keepalive_intvl=30 net.core.wmem_max = 12582912 net.core.rmem_max = 12582912 # Controls the default maxmimum size of a mesage queue kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296
We put another version of the sysctl.conf without the IPv4 part (the default cPanel one), but to actually apply the settings, we had to reboot the server, as sysctl -p wasn't actually applying any modifications from the new sysctl.conf and we still couldn't connect. Just as a reminder, the only users affected by this were Linux distros using the same wireless. Only one of them could connect and use the server (WHM, sites located on that server, FTP, etc.). Hope this helps somebody if they have the same issue. Thank you.0 -
I am happy to see the issue is now resolved. Thank you for updating us with the outcome. 0
Please sign in to leave a comment.
Comments
5 comments