Proxy ARP for address behind tun link does not work in 8
I have a small vpn (OpenVPN) setup. To make the configuration easy the remote client gets an address from "main" network and the remote client is announced via proxy arp. This worked well and reliably for FreeBSD until (and including) version 7.x. My new server uses FreeBSD 8.2-STABLE-r223473 and this setup does not longer work: The ethernet interface for the internal network has an usual private address range: net0: ether 90:e6:ba:73:ca:f2 inet 192.168.50.10 netmask 0xff00 broadcast 192.168.50.255 A subnet is routed via the tun interface: tun3: inet 192.168.50.161 netmask 0xffe0 broadcast 192.168.50.191 This routing works well between the remote client, the vpn server and hosts in other networks. But to reach the remote client from hosts in my local network I need a proxy arp entry. When I try to insert a proxy arp entry I get an error: # arp -s 192.168.50.166 90:e6:ba:73:ca:f2 pub only cannot intuit interface index and type for 192.168.50.166 The error message is generated in arp.c, because the address 192.168.50.166 has type IFT_PPP and not IFT_ETHER (or other). I thought this was an oversight and added the type IFT_PPP to arp.c's valid_type() routine. But I had no luck, now I get "arp: writing to routing socket: Invalid argument" and the kernel writes in the log "lla_rt_output: RTM_ADD publish (proxy only) is invalid" So my questions come: Is this a configuration error or a regression in proxy arp processing? Why is there a check for the IP address type? Should we allow to use any address? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Problem with new source address selection (was Anyone interested in jail patches?)
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 26 Nov 2008 23:56:
> If you are interested in a new set of jail patches... anyone?;-)
Yes, but about jail specific things I'll write later, in another mail
and on another list.
> 2b) for RELENG_7:
> http://people.freebsd.org/~bz/bz_jail7-20081126-02-at153644.diff
With this patch I received a new source selection implementation, I
believe the same as announced for HEAD. Here I found a problem.
One of my machines tunnels a private subnet via IPSEC (esp/tunnel).
Lets assume my private subnet is 192.168.90.0/24 and the "foreign"
subnet is 192.168.200.0/24. When I send packets via this tunnel I
must ensure the right source address, because the machine has several
interfaces. (BTW: this is so easy with openvpn and real routing, but
sometimes other people decide..) An easy solution was for me
ifconfig lo2 inet 192.168.90.254/32
route add -net 192.168.200.0/24 -iface lo2
The route is a "dummy" route only, because the IPSEC SPD determines
the packet flow.
This worked well in the past, but not with your patch. On connect(2)
call for the tunneled subnet I receive always "Network unreachable".
The following _wild hack_(tm) solves the problem _for me_, it is only
to show the problem to you:
--- sys/netinet/in_pcb.c.orig 2008-11-27 14:57:25.887082927 +0100
+++ sys/netinet/in_pcb.c2008-11-27 14:29:28.918257601 +0100
@@ -697,6 +697,9 @@ in_pcbladdr(struct inpcb *inp, struct in
ia = ifatoia(ifa_ifwithnet(sintosa(&sain)));
if (cred == NULL || !jailed(cred)) {
+// FB2008-11-27
+ ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa;
+// FB
if (ia == NULL) {
error = ENETUNREACH;
goto done;
Can you provide a patch to solve the connect problem?
Is there a better solution to setup source address selection for
IPSEC tunnels?
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new source address selection
Bjoern, thanks for your fast answer. Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 14:53: > Yes I know that hack though I never actually used it with a loopback > as the loopback case is *uhm* gross. You know you are telling the > kernel to actually send the packets to yourself which so far has just > worked more or less out of luck in my eyes. IMHO here we see again the main problem of IPSEC. Suddenly packets disappear in kernel, are tunneled with ipsec and appear on other end. A gif-like device with routes instead of SPD entries would have some advantages. > So is your 192.168.90.0/24 on any other interface but the lo2? > Is it the only network on that interface or are there aliases? For this machine the simplified setup is: - an ethernet interface for private net with address 192.168.90.1/24 and additional aliases for external addresses - several tun devices with external and private addresses and routes - lo0 as real loopback device with 127.0.0.1/8 - lo1 with private jail addresses Now I want to tunnel between my 192.168.90.0/24 and a foreign 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created a static route. > From the code down I take it that the connect(2) call happens outside > any jail and not within a jail, right? Yes, this is outside a jail. With jails I had no problems, every jail has currently one ipv4 and one ipv6 address. > Let me answer those later; in case you cannot reveal your network > setup in public; contact me offlist. If desired I could send you the complete interface and routing table. But I believe you should be able to see the problem with my example above. Thanks for sour support, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new source address selection
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 16:47: > I am running out the door but ... will check again tonight. Thanks! > So if you don't mind to go out with a source address of 192.168.90.1 > instead of .254, what about this hack. What happens if you change the > route to > route change -net 192.168.200.0/24 192.168.90.2 > (assuming the .2 is not on your local machine). Hm, looks fine. I thought there must be another way for address selection. :-) Thanks for your idea, I'll test this and report. -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new source address selection
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 27 Nov 2008 16:47: > > Now I want to tunnel between my 192.168.90.0/24 and a foreign > > 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created > > a static route. > > So if you don't mind to go out with a source address of 192.168.90.1 > instead of .254, what about this hack. What happens if you change the > route to > route change -net 192.168.200.0/24 192.168.90.2 > (assuming the .2 is not on your local machine). That works for the router, but for incoming packets on the internal interface (from -net 192.168.90.0/24) the machine will send an ICMP redirect to new router 192.168.90.2. Of course that is a black hole. When I use the route to own interface address (route change -net 192.168.200.0/24 192.168.90.1) it works, but also for every incoming packet an ICMP redirect is sent. So that solution is a workaround for short time only. Does anybody have a better solution for source address selection? Am I the only one with an IPSEC tunnel? -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new source address selection
Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 3 Dec 2008 11:03: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > That works for the router, but for incoming packets on the internal > > interface (from -net 192.168.90.0/24) the machine will send an ICMP > > redirect to new router 192.168.90.2. Of course that is a black hole. > > When I use the route to own interface address > > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > > for every incoming packet an ICMP redirect is sent. So that solution > > is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect This is the workaround I made in the meantime. I believe icmp redirects are for a working network not necessary, they are only an optimization. > > Does anybody have a better solution for source address selection? Am > > I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. Hm, is this so easy? I thought address selection for outgoing connections is made by the OS? One of my test cases is bind/named. I don't know how to configure _multiple_ bind addresses for outgoing connections dependent from destination network. As I mentioned earlier I believe the main problem is IPSEC itself, where we don't have an interface for tunneled connections. So I made a workaround with a dummy loopback device. So I have a question to the network specialists: Is there no other solution? Am I the only stupid man, who wants to tunnel a subnet with private address range via IPSEC? > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). Thanks, I will try this. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with new source address selection
Bjoern A. Zeeb wrote on 8 Dec 2008 21:02: > Did you try the patch and did it work for you as expected? If so I'll > add it to my repo and the next jail patch. Meanwhile I can confirm that your patch works well for me on an up-to- date RELENG_7 kernel. Thanks! Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: NTP - default /etc/ntp.conf
Edwin Groothuis wrote on 5 Jun 2009 22:44: > After pondering at conf/58595, I came with this text. > > The ntpd is not enabled by default, so the fact that the servers > are commented out should not be an issue. >... > +# server pool.ntp.org > +# server pool.ntp.org > +# server pool.ntp.org Isn't it better to use different entries? server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org To be sure that the IP addresses are different. See http://www.pool.ntp.org/en/use.html -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE
The following reply was made to PR bin/114081; it has been noted by GNATS. From: "Frank Behrens" <[EMAIL PROTECTED]> To: "Bjoern A. Zeeb" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE Date: Thu, 28 Jun 2007 13:39:10 +0200 Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote on 28 Jun 2007 8:54: > On Thu, 28 Jun 2007, Remko Lodder wrote: > > > Synopsis: [patch] ppp(8) should be able to set ethernet address for PPPoE > >... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114081 > > I have more complete patches since 2004 in my private tree for exactly > the same DTAG reason;-) :-) Unfortunately I did not find them before. I believe we need in offical FreeBSD documention a link list to users patch directories. ;-) > The very early versions are still around here: > http://sources.zabbadoz.net/freebsd/patchset/ > 10005-10008* I think. But they are highly outdated. > > I can upload newer versions somewhen the next days. Fine. Do you believe, that this functionality can go into FreeBSD sources? > BTW: are you putting your NIC into promisc mode using ifconfig? I > cannot see how you would receive the packets for a different MAC else? Hm, interesting question. *I* did not bring the NIC into promisc mode, but it seems to be. For PPPoE I use a vlan interface, and parent and sibling are marked PROMISC. I don't know, where it comes from: dhcpd, rtadvd, ...? Conclusions? 1. My patch may not work, because it may require PROMISC mode. I will test this. 2. Should we create a patch for mpd? (See discussion on freebsd-net). Thanks for your answer. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6 patch [Re: pf 4.1 Update available for testing]
Max Laier <[EMAIL PROTECTED]> wrote on 25 Jul 2007 1:35: > now available at: http://people.freebsd.org/~mlaier/PF41/ with > instructions how to build. Thanks! I tested it, because I have some trouble with pf > Please test if possible and provide me with feedback. The build has following problems: - libexec/Makefile has still reference to ftp_proxy, removing that line helped - usr.sbin/Makefile has still reference to ftp_proxy, removing that line helped - sbin/ifconfig misses ifgroup.c, fetching from HEAD helped I made not many tests, but this version seems to work in general. Unfortunately it does not fix the bug I described in another thread (pf eates syn packet? on freebsd-pf@). Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_6 patch [Re: pf 4.1 Update available for testing]
Max Laier <[EMAIL PROTECTED]> wrote on 2 Aug 2007 17:13: > On Thursday 02 August 2007, Frank Behrens wrote: > > The build has following problems: > > - libexec/Makefile has still reference to ftp_proxy, removing that line > > helped > > That's in the patch, did you have a libexec/Makefile.rej? Sorry, I should better read, what I have on screen: I believe it complained about "tftp-proxy" and that's not here. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/113359: panic sbdrop after ICMP6, packet too big
The following reply was made to PR kern/113359; it has been noted by GNATS. From: "Frank Behrens" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/113359: panic sbdrop after ICMP6, packet too big Date: Sun, 26 Aug 2007 14:26:35 +0200 The bug is probably a duplicate of PR 99779 and was fixed on RELENG_6 with src/sys/kern/uipc_socket.c: 1.280. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dualstack IPv4/IPv6 ADSL PPPoE configuration?
Steve Bertrand <[EMAIL PROTECTED]> wrote on 23 Oct 2007 22:03: > >> The only IPv6 related info I have from the ISP is the address of the > >> subnet. > > > > To implement dual-stack PPPoE setup you can use ppp or net/mpd4. Can't > > say for sure about ppp, but with mpd all you need to do is to enable > > ipv6cp protocol. After this daemon except IPv4 will also negotiate IPv6 > > link-level addresses. All you need to do after that is to somehow > > configure interface with your real IPv6 addresses using some daemon or > > statically. > > Does anyone have a working config that is capable of what the OP asked > (dual stack IPv6 and IPv4) in a PPPoE environment? I had no problems with user-ppp: in ppp.conf: enable ipv6cp in ppp.linkup: add! default HISADDR add! default HISADDR6 in rc.conf, where ::: is my subnet ipv6_enable="YES" ipv6_network_interfaces="net0 tun0 lo0" ipv6_ifconfig_net0="::: prefixlen 64 eui64 autoconf" ipv6_gateway_enable="YES" rtadvd_enable="YES" rtadvd_interfaces="net0" Do you see any problems with this setup? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
When IPv6 temporary addresses are regenerated?
I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. Does anybody know, when this address is expected to be regenerated? My current interface configuration is vlan0: flags=8843 mtu 1500 inet xxx.xxx.xx.xx netmask 0xff00 broadcast xxx.xxx.xxx.xxx inet6 fe80::211:::%vlan0 prefixlen 64 scopeid 0x5 inet6 2xxx:::: prefixlen 64 anycast inet6 2xxx:::0:211:2fff:: prefixlen 64 inet6 2xxx:::0:54b:5960:: prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995 I use FreeBSD 6.2-PRERELEASE-200611090613. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: When IPv6 temporary addresses are regenerated?
As nobody made a reply I will reply myself. ;-) Frank Behrens <[EMAIL PROTECTED]> wrote on 25 Jan 2007 14:09: > I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I > used "sysctl > net.inet6.ip6.use_tempaddr=1". The temporary address is generated and > meanwhile expired. > > Does anybody know, when this address is expected to be regenerated? Short answer after digging in the sources: A new temporary address is regenerated, when there is another address configured with flag "autoconf" (and temporary address is deprecated). The specification says, the temporary addresses should be generated for interfaces setup with stateless address autoconfiguration. What for a setup do I have? My FreeBSD router is connected via PPP, so I inserted the assigned _prefix_ in rc.conf. Now I have a half autoconfiguration, the prefix is assigned statically combined with IEEE identifiers. You see that in my current config: > inet6 2xxx:::0:211:2fff:: prefixlen 64 > inet6 2xxx:::0:54b:5960:: prefixlen 64 deprecated > autoconf temporary pltime 0 vltime 509995 But we can change the autoconf interface attribute with the undocumented ifconfig(8) flag with same name. In that case all works as expected. To achieve this as simple as possible I changed my rc.conf from ipv6_prefix_vlan0="2xxx:xxx::x" to ipv6_ifconfig_vlan0="2xxx:xxx::x:: prefixlen 64 eui64 autoconf" The site effect is, that there is now no automatic assigment of a 64 bit anycast address for this interface, but that does not matter in my setup. So my problem is solved, maybe someone can document the behaviour. Gruß, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tap(4) should go UP if opened
I want to diskuss the tap(4) behaviour before I create a PR:
The tap(4) interface does not go automatically in UP state (IFF_UP) when opened
by a
process. Therefore an additional command "ifconfig tapx up" is necessary, which
can
execute root only. On the other site the interface goes down automatically when
closed.
I propose that tap(4) is set to UP when opened by an user process. This can be
achieved
with the following patch (on FreeBSD 6.2-STABLE-200703081613):
--- sys/net/if_tap.c.orig Thu Mar 8 19:10:59 2007
+++ sys/net/if_tap.cFri Mar 9 10:05:57 2007
@@ -501,6 +501,7 @@
s = splimp();
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
+ ifp->if_flags |= IFF_UP;
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
How does tun(4) handle this? tun(4) is also set to down, when closed. It is not
set to up, when
ist is opened, but when an address is assigned by the user process. This is
fine, because it
needs always an ip address. tap(4) as layer 2 tunnel device does not need an ip
address, so
setting it up on open is IMHO the best solution.
Sound this reasonable or how should I handle the tap(4) open by an user
process, when this
process does not run as root?
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tap(4) should go UP if opened
Bruce, thanks for your answer!
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 9 Mar 2007 12:30:
> Frank Behrens wrote:
> > How does tun(4) handle this? tun(4) is also set to down, when closed. It is
> > not set to up, when
> > ist is opened, but when an address is assigned by the user process. This is
> > fine, because it
> > needs always an ip address. tap(4) as layer 2 tunnel device does not need
> > an ip address, so
> > setting it up on open is IMHO the best solution.
> >
> This isn't consistent with the other software cloneable interfaces which
> emulate certain layer 2 semantics, e.g. bridge, trunk, vlan; see below.
May be, but we have for tap(4) the possibility to attach a non root user
process.
> I recently committed Landon Fuller's code which makes tap and tun
> cloneable interfaces which may then be created via 'ifconfig tap0 create'.
I appreciate that. :-) It was the reason to build a new 6.2 kernel and to try
to run the attached
process not as root.
> Automatically setting the interface to IFF_UP is not consistent with the
> semantics for other network interfaces; it requires specific privileges
> (usually super-user or PRIV_NET_SETIFFLAGS in -CURRENT) to do.
My idea is to set it to IFF_UP when the process _opens_ the interface. It can
happen only if
1. the process has root provileges OR
2. net.link.tap.user_open=1 AND special rights are set on /dev/tapx
> A more involved patch is needed to do this right for all cases -- we
> should not do this by default.
But when it is useful to open a tap device by a non root process, when the tap
is not IFF_UP?
May be my patch had not enough context to see immediately, where it fits into
the game. To
make it easier for the reviewers I show the complete function:
/*
* tapopen
*
* to open tunnel. must be superuser
*/
static int
tapopen(struct cdev *dev, int flag, int mode, struct thread *td)
{
struct tap_softc*tp = NULL;
struct ifnet*ifp = NULL;
int error, s;
if (tapuopen == 0) {
error = suser(td);
if (error != 0)
return (error);
}
if ((dev2unit(dev) & CLONE_UNITMASK) > TAPMAXUNIT)
return (ENXIO);
tp = dev->si_drv1;
mtx_lock(&tp->tap_mtx);
if (tp->tap_flags & TAP_OPEN) {
mtx_unlock(&tp->tap_mtx);
return (EBUSY);
}
bcopy(IFP2ENADDR(tp->tap_ifp), tp->ether_addr, sizeof(tp->ether_addr));
tp->tap_pid = td->td_proc->p_pid;
tp->tap_flags |= TAP_OPEN;
ifp = tp->tap_ifp;
mtx_unlock(&tp->tap_mtx);
s = splimp();
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
ifp->if_flags |= IFF_UP;/* --- new line -- */
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
return (0);
} /* tapopen */
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Assign IP address to which interface when using if_bridge(4)?
I see some problems with if_bridge(4) and want to investigate this further. But before I make further tests I want to be sure to have the right setup. I could not find any hints in the documentation including FreeBSD handbook. I have an ethernet device xl0 and want to create a if_bridge(4) to tap(4): ifconfig bridge0 create ifconfig bridge0 addm xl0 addm tap0 up Now I have 3 interfaces, to which of them should I assign the ip address? When searching for information I found both possibilities: 1. Assign the IP address to child interface (e.g. xl0) and use this also for routing setup. 2. Assign the address to bridge interface (bridge0) and use this as reference interface. I assume 1. is the right solution, because the bridge0 does not even create link-local addresses. Am I right? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tap(4) should go UP if opened
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 9 Mar 2007 12:30:
> However, we also support the creation of tap/tun instances by
> non-super-users, so there is motivation for the change. Configuring a
> tap interface to up by a non-superuser should only be permitted if the
> interface itself was created by a non-superuser, and if
> net.link.tap.user_open is set to 1.
>
> A more involved patch is needed to do this right for all cases -- we
> should not do this by default.
After thinking about the problem I agree with you and propose the following
patch:
--- sys/net/if_tap.c.orig Thu Mar 8 19:10:59 2007
+++ sys/net/if_tap.cWed Mar 14 12:35:58 2007
@@ -501,6 +501,8 @@
s = splimp();
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
+ if (tapuopen)
+ ifp->if_flags |= IFF_UP;
splx(s);
TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
Rationale:
For transmitting packets via tap(4) device (at least) two conditions have to
met:
1. The control device must be opened by an process.
2. The ethernet interface must be UP.
For 1. we allow non-root processes the access, when
a) sysctl net.link.tap.user_open=1 AND
b) /dev/tapx has sufficient permissions
If we have no possibility to mark the interface as UP for the non-root process
the
net.link.tap.user_open=1 is useless, because we can not transmit any packets.
With the
patch the interface goes UP only, when the administrator allowed non-root user
access.
Regards,
Frank
--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tap(4) should go UP if opened
Bruce, many thanks for your fast response. Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 14 Mar 2007 13:09: > The conditional in the second patch is a no-op as the open will be > forbidden if the user did not have privilege to open the tap. Bringing No. A process running with root rights can always open the tap. > the interface up by default potentially violates POLA, so this should > not happen by default. Ok, I see that the behaviour changes. I wonder who used the "tap user open" sysctl, when additional root rights are necessary to bring the interface UP? I can't imagine a setup where this could be used, somebody else? > Please try the attached patch, which puts this behaviour under a sysctl. Fine! This should work without problems. I agree with this solution, sounds good. I'll test it and report the result. Regards and thanks for your support, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tap(4) should go UP if opened
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 14 Mar 2007 13:09: > Please try the attached patch, which puts this behaviour under a sysctl. It works well as expected. Many thanks! I created a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=110383 with the hope the patch will be commited. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
