Bug #4392
closedOpenVPN daemon crashing with ath(4) card installed
0%
Description
I have OpenVPN with tunnels between 3 locations. Almost every day Ill look at the dashboard and it will show one on the tunnels as down and says unable to contact daemon, service not running? When I look at the system logs this is what I see:
Feb 8 20:24:02 php-fpm8648: /vpn_openvpn_server.php: OpenVPN ID server1 PID 22206 still running, killing.
Feb 8 20:23:30 kernel: sonewconn: pcb 0xfffff80003d893c0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
Restarting the process doesnt work..the process will never actually stop is what the logs indicate. Only solution is to reboot the box.
Updated by Chris Buechler almost 10 years ago
is it the same instance that's affected every time?
The log "OpenVPN ID server1 PID 22206 still running, killing" means something was trying to restart OpenVPN, but OpenVPN got hung up and didn't respond to a TERM and had to be sent a KILL. The only circumstance where I'd heard of that prior to this was where an OpenVPN client couldn't resolve the hostname of its server and when it's in that circumstance it doesn't respond to TERM. Adding the KILL that generates that log message fixed the root problem there (OpenVPN wouldn't stop, then was started a second time, which broke things). That wasn't applicable to servers though.
What's in your OpenVPN log just prior to that happening? And anything in your system log from that time period which might indicate what triggered OpenVPN to be restarted.
Updated by Chris Buechler almost 10 years ago
- Category set to OpenVPN
- Status changed from New to Feedback
- Affected Version set to 2.2
to get that log it has to be 2.2-something, I presume this is 2.2-RELEASE.
Updated by Adam Esslinger almost 10 years ago
the same instance is not always affected...its 2 of the 3 that have the issue. So I would log into the GUI and notice that one of the VPN tunnels showed as down...I would do and ping to verify that the tunnel was really down. I would then use the GUI to restart the service for the specific tunnel and that's when the logs would start to fill with the PID still running, killing. Yesterday I changed 3 things...system logging (Bug #4393), memory allocation for Snort (from AC-STD AC-BNFA), and some kernel hardware tunables for my Atheros Wifi card. So far I haven't seen the issue. Ill have to do some more testing to see which may have caused the issue.
Updated by Adam Esslinger almost 10 years ago
I just had this happen again..Here is what I'm seeing. The Service status dashboard shows the Daemon is running, but the OpenVPN peer to peer status dashboard shows the connection as Unable to contact daemon Service not running? When I try to ping the remote site pings fail. Here is what I see in the system log
Feb 13 11:11:08 kernel: sonewconn: pcb 0xfffff80003d1a0f0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
Feb 13 11:07:14 kernel: sonewconn: pcb 0xfffff80003d1a0f0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
OenVPN logs show that my client VPN connection got dropped and reconnected.
Feb 13 11:04:31 openvpn: user 'xxxx' authenticated
Feb 13 11:01:41 openvpn25877: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 192.168.101.1 192.168.101.2'
Feb 13 11:01:41 openvpn25877: WARNING: 'tun-ipv6' is present in local config but missing in remote config, local='tun-ipv6'
Feb 13 10:04:30 openvpn: user 'xxxx' authenticated
When I then use service status dashboard to restart the service I see this in the logs.
Feb 13 11:17:00 php-fpm84710: /status_services.php: OpenVPN ID server2 PID 25685 still running, killing.
Feb 13 11:16:59 php-fpm84710: /status_services.php: OpenVPN ID server2 PID 25685 still running, killing.
Feb 13 11:16:59 php-fpm84710: /status_services.php: OpenVPN ID server2 PID 25685 still running, killing.
Feb 13 11:16:58 php-fpm84710: /status_services.php: OpenVPN ID server2 PID 25685 still running, killing.
Feb 13 11:16:58 kernel: sonewconn: pcb 0xfffff80003d1a0f0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
The only solution I have found is to reboot the box.
Updated by Adam Esslinger almost 10 years ago
I just had this happen again. I have noticed that this appeared again in the logs.
Feb 15 11:57:57 kernel: sonewconn: pcb 0xfffff80003d2b4b0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
Feb 15 11:56:17 kernel: sonewconn: pcb 0xfffff80003d2b4b0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
Feb 15 11:54:34 kernel: sonewconn: pcb 0xfffff80003d2b4b0: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences)
Updated by Adam Esslinger almost 10 years ago
to answer your previous question yes this is running 2.2-RELEASE (amd64)
Updated by David Masshardt almost 10 years ago
This error also occurs almost every minute on my pfSense firewall since the update to 2.2. Is there a any solution to this problem yet or can I provide some more information to help solving this problem?
Updated by Adam Esslinger over 9 years ago
This appears to be a bug related to the drivers for the AR9350 WiFi Card. Once I removed it from my system these issues went away. This seems to be a BSD driver issue with Atheros cards.
Updated by Chris Buechler over 9 years ago
Adam Esslinger wrote:
This appears to be a bug related to the drivers for the AR9350 WiFi Card. Once I removed it from my system these issues went away. This seems to be a BSD driver issue with Atheros cards.
That's odd. Have you tried 2.2.1 or newer? The wireless bits and Atheros driver are all updated to latest from FreeBSD -CURRENT, which fixed a variety of ath problems on 2.2x pre-2.2.1.
Updated by Chris Buechler almost 9 years ago
- Subject changed from OpenVPN daemon crashing? to OpenVPN daemon crashing with ath(4) card installed
- Status changed from Feedback to Closed
unable to replicate. guessing it was probably fixed in ath driver update in newer 2.2.x versions