GNOME Bugzilla – Bug 638909
openconnect does not set the right env variables for the dispatcher script
Last modified: 2011-04-26 20:27:07 UTC
I created a /etc/NetworkManager/dispatcher.d/22showenv script, executable, with this content: #!/bin/sh exec > "/tmp/nm-$1-$2.log" echo "Args: $*" echo "Env:" env | sort exit 0 I have a system with a wired eth0 interface managed by NM, that uses DHCP to obtain information and lives on the 172.31.1.0/24 subnet with a gateway and DNS proxy server living on 172.31.1.1. After adding the above script, I brought up my openconnect VPN connection via NM, and I saw that the above script created a file "/tmp/nm-tun0-vpn-up.log" which seemed OK, but the content was all wrong: it contained all the information about my eth0 connection, and nothing related to the new VPN tun0 connection. A slightly edited listing of the output file is: # cat /tmp/nm-tun0-vpn-up.log Args: tun0 vpn-up Env: CONNECTION_UUID=<uuid> DHCP4_BROADCAST_ADDRESS=172.31.1.255 DHCP4_DHCP_LEASE_TIME=86400 DHCP4_DHCP_MESSAGE_TYPE=5 DHCP4_DHCP_REBINDING_TIME=71811 DHCP4_DHCP_RENEWAL_TIME=39411 DHCP4_DHCP_SERVER_IDENTIFIER=172.31.1.1 DHCP4_DOMAIN_NAME=localnet DHCP4_DOMAIN_NAME_SERVERS=172.31.1.1 DHCP4_EXPIRY=1294411827 DHCP4_HOST_NAME=hostname DHCP4_IP_ADDRESS=172.31.1.105 DHCP4_NETWORK_NUMBER=172.31.1.0 DHCP4_ROUTERS=172.31.1.1 DHCP4_SUBNET_MASK=255.255.255.0 IP4_ADDRESS_0=172.31.1.105/24 172.31.1.1 IP4_DOMAINS=localnet IP4_NAMESERVERS=172.31.1.1 IP4_NUM_ADDRESSES=1 IP4_NUM_ROUTES=0 PWD=/ However, the correct information is set in /etc/resolv.conf etc. Not sure if this is really an openconnect bug; not sure who is responsible for setting this information and invoking the dispatcher scripts.
I don't think this is the fault of the NM-openconnect code; I'm not aware of any way I could have screwed this up for myself. Assigning it to NetworkManager core to see if dcbw contradicts me...
Not openconnect specific, this is a bug in NM itself. *** This bug has been marked as a duplicate of bug 648382 ***