On Thu, Dec 29, 2016 at 4:47 PM, Selva Nair <[email protected]> wrote:
> On Thu, Dec 29, 2016 at 4:22 PM, Gert Doering <[email protected]> wrote: > >> >> On Thu, Dec 29, 2016 at 04:12:06PM -0500, Selva Nair wrote: >> [..] >> > But to test this bug report I did use the same adapter (still using >> > --dev-node adapter-name..) and changed the remote and couldn't reproduce >> > it. But I do see something similar as this report (DHCP fails to set >> IP) if >> > I remove the --dev-node line and let it pick an adapter that was >> previously >> > used with a different IP. Can't reproduce it consistently, though. >> >> But it seems we have some work to do here... >> >> Maybe "--ip-win32 ipapi" is the answer? >> >> (How do we set IPv4 addresses if the iservice is in use? Still using >> DHCP, or always? sometimes? via iservice / ipapi? I never cared too much >> for v4 and am too lazy to look right now, apologies :-) ) > > > If i'm not mistaken, we never use the service to set ipv4 address on the > adapter. Its either dhcp or netsh or ipapi. So unless ip-win32 is set to > something specific like ipapi (or adaptive + dhcp disabled on the > interface), dhcp is used > > Its easy to test whether manually setting an ip works when connection > completes without ip being set as in the OP's post. I'll give it a try if I > get to reproduce the behaviour. > OK, removed --dev-node, and tried two remotes in a succession a few times and got this failure for second remote (as in the original bug report): Route: Waiting for TUN/TAP interface to come up... repeated several times for 15 seconds, current routing table dumped to the logs and finally CONNECTED,ERROR,.... which the GUI interprets as successfully connected (urgh..) Relevant client log attached. In this state, tried to set the IP manually using netsh but that failed saying object already exists as if the IP is already set (in some partially set state?). I did not try with ip-win32 ipapi as that requires to run openvpn/GUI as admin. In any case statically setting ip (using netsh or ipapi) on dhcp failure is not a proper solution as that will disable dhcp on the adapter. In subsequent connections netsh will try to re-enable dhcp and fail without admin rights. Currently we don't delegate such tasks to iservice (though we should). On setting the remote back to the previous one the connection works. Selva
test.log
Description: Binary data
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
