RE: recent change to ifconfig breaks OpenVPN?

I will look into it.

-- Qing


> -----Original Message-----
> From: owner-freebsd-current_at_freebsd.org [mailto:owner-freebsd-
> current_at_freebsd.org] On Behalf Of Stefan Bethke
> Sent: Thursday, July 30, 2009 9:46 AM
> To: Qing Li; Bjoern A. Zeeb
> Cc: Matthias Andree; FreeBSD Current
> Subject: Re: recent change to ifconfig breaks OpenVPN?
> 
> Am 30.07.2009 um 08:40 schrieb Stefan Bethke:
> 
> > Am 30.07.2009 um 01:46 schrieb Matthias Andree:
> >
> >> Hi everybody,
> >>
> >> If that is the case, then we should go quickly to either make it go
> >> into 8-CURRENT's ports or OpenVPN 2.1, or both.
> >>
> >> I'm not sure I have sufficient context or time to read up to
> >> determine my own role here (I haven't been following -current for
> >> lack of time); can someone summarize the issue for me?
> >
> > I can try to summarize; I don't think I'll have time to come up with
> > a patch this weekend.
> >
> > The problem appears to be that OpenVPN invokes ifconfig with
> > incorrect (but previously working) parameters, namely "ifconfig tun0
> > local_ip local_ip" instead of "ifconfig tun0 local_ip remote_ip".
> > The problem does not appear to be the SIOCAIFADDR but the RT_ADD
> > that ifconfig does.  When I drafted a replacement OpenVPN --up
> > script yesterday, I also noticed that the parameters passed to the
> > script are wrong (netmask instead of remote ip), and environment
> > variables are partially not set (ifconfig_remote is empty).
> >
> > This issue appears to affect tun-mode connections; tap-mode
> > connections appear to continue to work.
> >
> > I'm not sure if that is a more general problem with OpenVPN (at
> > least in --topology subnet mode), or a specific problem in the
> > FreeBSD-specific code.  I just looked at a Linux box connected to
> > the same OpenVPN server, and their ifconfig invocation looks
> > different from ours, so the FreeBSD-specific code at least plays
> > some role.
> >
> > I'd still like to know whether the change to the routing code is
> > intentional or a regression.
> 
> I did at least have time to figure out the commit that changed it:
> 195914
> 
> > Author: qingli
> > Date: Mon Jul 27 17:08:06 2009
> > New Revision: 195914
> > URL: http://svn.freebsd.org/changeset/base/195914
> >
> > Log:
> >  This patch does the following:
> >
> >      - Allow loopback route to be installed for address assigned to
> >        interface of IFF_POINTOPOINT type.
> >      - Install loopback route for an IPv4 interface addreess when
the
> >        "useloopback" sysctl variable is enabled. Similarly, install
> >        loopback route for an IPv6 interface address when the sysctl
> > variable
> >        "nd6_useloopback" is enabled. Deleting loopback routes for
> > interface
> >        addresses is unconditional in case these sysctl variables
were
> >        disabled after an interface address has been assigned.
> 
> 
> Setting net.link.ether.inet.useloopback=0 does not restore the
> previous behavior.
> 
> 
> Stefan
> 
> --
> Stefan Bethke <stb_at_lassitu.de>   Fon +49 151 14070811
> 
> 
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscribe_at_freebsd.org"