Hello openwrt-devel, Here's some more debugging information:
The issue is that disconnecting from a openconnect VPN doesn't clean up all routes (on a recent snapshot): Before default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0.2 192.168.0.0 * 255.255.255.0 U 0 0 0 br-lan 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0.2 During default * 0.0.0.0 U 0 0 0 vpn-MYVPN (MYVPN IP) 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0.2 192.168.0.0 * 255.255.255.0 U 0 0 0 br-lan 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0.2 192.168.3.0 * 255.255.255.0 U 0 0 0 vpn-MYVPN After (MYVPN IP ) 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0.2 192.168.0.0 * 255.255.255.0 U 0 0 0 br-lan 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0.2 Following, the log output for running "ifdown MYVPN". I put in some logger statements at the beginning of openconnect.sh and vpnc-script to see when these would be invoked. (vpnc-script quite late btw.. looks like netifd already did everything at this point?) Mon Jan 5 17:40:36 2015 user.notice openconnect: called openconnect.sh Mon Jan 5 17:40:37 2015 user.notice openconnect: bringing down openconnect Mon Jan 5 17:40:37 2015 daemon.info openconnect[1245]: Send BYE packet: Aborted by caller Mon Jan 5 17:40:37 2015 daemon.notice netifd: Network device 'vpn-MYVPN' link is down Mon Jan 5 17:40:37 2015 daemon.notice netifd: Interface 'MYVPN' is now down Mon Jan 5 17:40:37 2015 user.notice openconnect: called vpnc-script Mon Jan 5 17:40:40 2015 daemon.info dnsmasq[1082]: reading /tmp/resolv.conf.auto Mon Jan 5 17:40:40 2015 daemon.info dnsmasq[1082]: using local addresses only for domain lan Mon Jan 5 17:40:40 2015 daemon.info dnsmasq[1082]: using nameserver 192.168.1.1#53 I don't know enough about netifd internals, but I looked a bit at openconnect's side of things: ifdown MYVPN -> ... -> proto_openconnect_teardown -> proto_kill_command (sets action 2) -> _proto_notify -> (ubus) (ubus) -> ... -> netifd_iface_notify_proto -> proto_shell_notify -> proto_shell_kill_command -> kill(openconnect's pid, SIGINT) The SIGINT quits openconnect's main loop, sends a goodbye to the server, -> os_shutdown_tun -> script_config_tun. This forks and execl()s the vpnc-script in a shell. The parent seems to wait for the script to finish, closes the tun device, and exits with code 0. The vpnc-script in turn is trying to call proto_init_update (sets action 0), proto_send_update -> _proto_notify -> (ubus). _But_, I have the feeling that this is somehow too late and that the interface is already cleaned up at this point, as per ordering of the log lines above? (Not sure if this at all relevant though.) Not sure what is triggering the "link down" and "interface down" in netifd.. could it perhaps be that the server, upon receiving the BYE, closes the connection fast enough before we have a chance to gracefully clean up? Thanks in advance Gottfried On Mon, Jan 5, 2015 at 9:31 AM, Nikos Mavrogiannopoulos <[email protected]> wrote: > On Mon, Jan 5, 2015 at 8:00 AM, Gottfried Haider > <[email protected]> wrote: >>> It seems that you use openconnect to set a default route, and that's why >>> I couldn't reproduce it. I don't think that openconnect handles default >>> routes differently, so it could be an issue in netifd. As I see default >>> routes are registered using proto_add_ipv4_route, and should have been >>> automatically removed when proto_kill_command is called in >>> openconnect.sh. >>> Most probably you'll have to check the log (readlog), and possibly add >>> some additional logging in: >>> /lib/netifd/netifd-proto.sh >>> /lib/netifd/proto/openconnect.sh >>> >>> Sorry for not being able to help more. Maybe someone in the >>> openwrt-devel list will be able to help with that. >> Thanks for those pointers. I could follow the execution all the way to >> vpnc-script, so openconnect gets called with SIGINT and cleanly closes >> the connection. In the disconnect case in vpnc-script, I only see >> calls to proto_init_update and proto_send_update, whereas in connect >> the script did the heavy lifting to setup those routes... where do >> these calls go, do you happen to know? (primarily trying to figure out >> whether its openconnect or some part of netfid that I should look >> into) > > My understanding is that they are rpc, go to netifd daemon, which > calls openconnect.sh shortly after that. > > regards, > Nikos _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
