Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I configure my Wireless network on start up (wpa_supplicant & dhclient), the connection is fine until I launch OpenVPN.

At which point the wireless interface disassociates (not until the tunnel is established) and I have to bring it back up manually by either restarting networking or doing ifdown/ifup. Which does work but is a real pain.

dmesg reports:

ADDRCONF(NETDEV_CHANGE) wlan0: link becomes ready
wlan0: disassociating from 00:00:00:00:00:00 by local choice (reason=3)
cfg80211: Calling CRDA to update world regulatory domain
ADDRCONF(NETDEV_CHANGE) wlan0: link is not ready

OpenVPN doesn't throw any error messages apart from not being able to reach the server once the WiFi goes down.

I have tried creating both tun/tap devices without OpenVPN and this is perfectly fine, they can be assigned IP addresses.

wpa_supplicant and wpa_cli is still running once the interface goes down, so I have to run

ifdown --force wlan0

I have stripped my OpenVPN config to the minimal sample config and the same problem is still occuring.

I have also tried it with both rt2800 and rtl8187 devices, both experience the same behavior.

My config files are as follows, but I haven't had a problem with them until trying to get OpenVPN to work.

Interfaces File

auto wlan0
iface inet wlan0 manual
    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
    wpa-driver wext

iface inet default dhcp





After debugging for a little while I have determined it is something to do with the wpa-roam option, changing this to wpa-conf solves the problem (wpa_cli is not launched). I will update again when I have narrowed it down to the specific signal causing the issue.


I have updated wpa_supplicant from 1.0 to 2.0 and the same problem still occurs, the WiFi is simply disassociating from the AP when an openvpn tunnel forms, the wireless interface is not actually taken down (pre,down,post are not called when this happens)

share|improve this question
Rich, when you log into the original account with which you posted this question (Rich), you can edit the question yourself without the need of the community to approve the edits. – BloodPhilia Mar 15 '13 at 13:33

The question is in a slightly different context, but the answer is here...

Debian eth0 to wlan0 forwarding, with openvpn

Basically ifplugd is taking down the WiFi interface. As only one roaming interface is supposed to be active at once.

When this is called:

/etc/ifplugd/action.d/action_wpa tun0 up

The script loops disconnecting any wpa-roaming devices...

for CTRL in /var/run/wpa_supplicant/*; do

    [ -S "${CTRL}" ] || continue


    # skip if ifplugd is managing this interface
    if [ "${IFPLUGD_IFACE}" = "${IFACE}" ]; then

    if wpa_action "${IFACE}" check; then
        wpa_cli -i "${IFACE}" "${COMMAND}"

This script needs to be extended to check other interfaces that are being managed by ifplugd not just the one that is called with the script.

share|improve this answer
please do not use links as answers. it is advised to paste relevant content here instead and use the link as reference. if the link ever gets broken, so does your whole answer. – Lorenzo Von Matterhorn Mar 15 '13 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .