View previous topic :: View next topic |
Author |
Message |
AaylaSecura Tux's lil' helper
Joined: 09 Jun 2011 Posts: 122
|
Posted: Mon Jul 01, 2013 6:48 pm Post subject: Unmount network share before VPN connection is closed? |
|
|
Greetings! I have set up a VPN connection using pptpclient-1.7.2-r3 and I mount a share on the remote network using mount -cifs. It works great, apart from when I lose internet connection. The VPN connection is terminated, but my share is not unmounted. I can write a script that will monitor if I have connection and unmount the share if i don't, trouble is if the share is unmounted after the tunnel is closed, it refuses to mount once the VPN is established again (it does not give any error whatsoever). If I leave the share mounted while the tunnel is not open, all filesystem monitoring apps freeze (including the terminal if I try to list the contents of the parent directory where the share is mounted). Is there any way I can tell pptpclient to unmount the share before it brings down the connection (/etc/ppp/ip-down is executed after the connection is closed) ? |
|
Back to top |
|
|
Small_Penguin Tux's lil' helper
Joined: 27 May 2005 Posts: 140
|
Posted: Tue Jul 02, 2013 5:17 am Post subject: |
|
|
Symlink /etc/init.d/net.ppp0 to net.lo and configure it in /etc/conf.d/net. See net.example coming with openrc. You can define pre_up/pre_down functions in the conf file that does what you want.
BTW: The freezes resolve themselves after some CIFS timeout has been reached. This takes from a few seconds up to a minute or so. I never found out how to work around that. |
|
Back to top |
|
|
AaylaSecura Tux's lil' helper
Joined: 09 Jun 2011 Posts: 122
|
Posted: Tue Jul 02, 2013 8:03 pm Post subject: |
|
|
Hi and thanks for replying! I tried your suggestion, but it didn't work. The predown() function is executed before ppp0 dies, but it is still executed after pptpclient closes this tunnel (before it brings down the whole interface).
This freezing does indeed resolve itself (provided I lazily unmount the share) after quite some time though. Is there a way I can set this timeout to some smaller value or is that governed by the remote network's settings? |
|
Back to top |
|
|
Small_Penguin Tux's lil' helper
Joined: 27 May 2005 Posts: 140
|
Posted: Tue Jul 02, 2013 9:00 pm Post subject: |
|
|
AaylaSecura wrote: | Hi and thanks for replying! I tried your suggestion, but it didn't work. The predown() function is executed before ppp0 dies, but it is still executed after pptpclient closes this tunnel (before it brings down the whole interface). |
Then you will need to handle this (the unmounting) in /etc/init.d/net.lo directly, perhaps in the stop() function. A bit more hackish, but you can check for the interface name using the proper variable. Or even better redefine the stop function in /etc/conf.d/net if ${IFACE}== ppp0, copying the needed parts from the original function defined in /etc/init.d/net. This way you're less likely to run into problems when you update openrc.
AaylaSecura wrote: | This freezing does indeed resolve itself (provided I lazily unmount the share) after quite some time though. Is there a way I can set this timeout to some smaller value or is that governed by the remote network's settings? |
I know of none. I've searched for that some months ago but gave up and made my script work around it. IIRC, you would have to patch the kernel module, e.g. see http://samba.2283325.n4.nabble.com/Timeout-waaay-too-long-td2517551.html. Not sure if that information is still up-to-date, though. |
|
Back to top |
|
|
AaylaSecura Tux's lil' helper
Joined: 09 Jun 2011 Posts: 122
|
Posted: Tue Jul 02, 2013 10:10 pm Post subject: |
|
|
I looked at the stop() function and predown() is called at the very beginning (I even tried placing the umount command explicitly at the beginning), but the share still hangs and refuses to unmount. How come net.lo does not handle this and pptpclient gets to close its tunnels before sending a notification it's about to go down? |
|
Back to top |
|
|
Small_Penguin Tux's lil' helper
Joined: 27 May 2005 Posts: 140
|
Posted: Wed Jul 03, 2013 7:16 am Post subject: |
|
|
Ok, I've missed a bit you've said in the beginning: "It works great, apart from when I lose internet connection."
If connection is lost, that is all out of control of pptp-client or openrc net. It's already too late to close/unmount any connection, no communication takes place with the server. You have to look for a solution to fix the long timeout, or handle the remounting more gracefully. CIFS tries to reconnect automatically IIRC. Try unmount options -l -f. If it's feasible, you might try to reconnect with pptp, then unmount, then disconnect again. Really ugly, but it could work and speed things up for reconnect. |
|
Back to top |
|
|
AaylaSecura Tux's lil' helper
Joined: 09 Jun 2011 Posts: 122
|
Posted: Wed Jul 03, 2013 8:49 am Post subject: |
|
|
Oops, that was my bad - I did not mention in my latest post that when I was testing all of this, I was closing the tunnel with poff <tunnel_name> instead of disconnecting from the internet (as if I lose connection). Only now did I realise that this is closing the tunnel directly (that is why net has no control) and is not necessarily bringing the ppp0 interface down (it's brought down, afterwards, cause there was only one open tunnel). So I should have brought the interface down with ifdown instead and let it close all the tunnels.
But that would not solve the issue if I actually lose connection.
I wrote a script that is running constantly and pinging a url every 5s, so if I lose connection it unmounts the share (with the -l option, cause the -f option keeps returning that the share is in use) and closes the tunnel. This solves the freeze after the first timeout (whereas if I don't unmount it at all, it keeps trying to connect and freezes). It's not very efficient, so I will keep looking for another way.
I am wondering why force unmouting it does not work, I thought the -f option was precisely for offline network shares, yet it keeps complaining the share is in use, but there is no process using it... |
|
Back to top |
|
|
|