[OpenWrt-Devel] openconnect does not remove default routes [was: Some OpenConnect observations]

[Gottfried Haider]

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 <nmav at gnutls.org> wrote:
> On Mon, Jan 5, 2015 at 8:00 AM, Gottfried Haider
> <gottfried.haider at gmail.com> 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
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel