CFR: FIB handling improvements
Hi, I'm working to port forward to FreeBSD/head, improvements made to FIB handling by my colleagues Alan Somers and Justin Gibbs. Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff This patch includes fixes for several issues relating to FIBs: * Use of dhclient with non-zero FIBs. With this patch, it is possible to use DHCP on a specific interface with a non-zero FIB and have it work correctly with this rc.conf snippet: ifconfig_em1="SYNCDHCP" dhclient_fib_em1=1 This part of the patch includes a XXX, because I am not sure whether the dhclient rc.d script should manually set the FIB on the given interface, or if it should be inferred via some other mechanism. * Always add loopback routes for non-zero FIBs, for both IPv4 and IPv6. Arguably, this could be a policy issue, but it is currently less-than-trivial to specify (in rc.conf) that a route needs to be applied to every FIB. * Having two or more FIBs whose interfaces share the same prefix and netmask. This involves adding fibnum arguments to ifa_ifwithnet() and ifa_ifwithdstaddr(), and checking it within. * Setting the FIB on a network interface. rtinit1() looks it up via the current process context, so we must be calling setfib(2) from within ifconfig. * Creating & deleting loopback routes now works correctly for non-default FIBs, by using the interface's FIB instead of always 0. Commits would be made on each of these issues separately, but since they are all related, I thought it would be easier for others to evaluate them with context. Thanks! --Will. ___ 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: CFR: FIB handling improvements
On Wed, Aug 21, 2013 at 12:20 PM, Hiroki Sato wrote: > wi> * Always add loopback routes for non-zero FIBs, for both IPv4 and > wi> IPv6. Arguably, this could be a policy issue, but it is currently > wi> less-than-trivial to specify (in rc.conf) that a route needs to be > wi> applied to every FIB. > > I am not sure why this is needed. Are the loopback host routes > installed into all of the FIBs automatically when lo0 is initialized? > > Even if it is required, get_fibmod() is not necessary. The following > should work: > > # route add -inet 127.0.0.1/8 -iface lo0 -fib all Other places in rc.d/routing can make use of 'all' in that case. No, loopback host routes are not installed into all FIBs, only FIB 0. This is with rt_add_addr_allfibs == 0 (see rtinit1()), which probably explains why. We could add an override for lo0 addresses, but perhaps this is something that should be configurable? i.e. allow the administrator to specify in rc.conf which FIBs lo0's host route should be placed on? --Will. ___ 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: "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages
On Fri, Nov 5, 2010 at 4:47 PM, Ask Bjørn Hansen wrote: > I agree that it was pretty dumb of the OpenBSD developers to just stomp on > another protocol ID for their (and ours in FreeBSD ...) implementation. Actually, in this particular case I think it was justified. The IANA refused to allocate a separate protocol number for CARP. Given that, and the fact that CARP and VRRP serve generally the same purpose, it makes sense that they use the same number. Using an "unused" number runs the risk of conflicting with a different unregistered protocol, or one that was registered after the number was chosen. FreeBSD could require administrators to configure the number on all participating hosts on a given network, but that may be non-trivial to implement in a particular network stack. With the recent changes to CARP in FreeBSD, however, it could be made to attach to a different protocol number relatively easily. FreeBSD could allow configuring CARP to silently ignore invalid packets. That would definitely be trivial to implement, but it doesn't solve the issue that a particular network segment might be running fussy VRRP hosts. --Will. ___ 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: Generating SYN packets.
On Fri, Mar 09, 2001 at 08:03:58AM -0800, Walter Goralski wrote:
> The missing piece has been DOS SYN attacks. I have the really common
> "synk4.c" source that is all over the Web, but I get errors when I try to
> compile it ("it's the linux includes" someone told me). Now, I last used my
They're most likely right. Try changing "#include " to
"#include " or "#include ". Linux has this weird
idea that raw sockets headers should be under . Apparently they
are the only OS that supports such behavior. ;)
--
wca
PGP signature
MFC of if_lagg flowid changes (r272386)?
Hi, Please see: https://svnweb.freebsd.org/base?view=revision&revision=272386 This change removes sysctl nodes that were added during lacp_attach(), which causes a lock order reversal (sleepable lock while holding non-sleepable). These sysctl nodes arrived in: https://svnweb.freebsd.org/base?view=revision&revision=253687 Here is a bug report about the LOR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188997 I propose to MFC r272386 to eliminate the bug. However, it also eliminates sysctl nodes that were added to control lagg behavior. My understanding is that these sysctls weren't intended to be publicly used, and consequently they aren't documented anywhere. Any objections? Thanks! -- wca pgp1HdAmfcZIF.pgp Description: PGP signature
Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7
The following reply was made to PR bin/118987; it has been noted by GNATS. From: Will Andrews To: bug-follo...@freebsd.org Cc: Subject: Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 Date: Sat, 31 Jan 2009 03:29:52 -0700 --001636c5986450f9c20461c4cdef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is a patch that fixes this problem (it also fixes the problem for address families besides "ether"). I'm not sure if the method used is the best approach for "ether", but it does at least match some other usage within ifconfig. Unfortunately I don't seem to be able to attach patches correctly for GNATS, so here's a link: http://firepipe.net/ifconfig.c.118987-diff2.txt --Will. --001636c5986450f9c20461c4cdef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is a patch that fixes this problem (it also fixes the problem for addr= ess families besides "ether"). I'm not sure if the meth= od used is the best approach for "ether", but it does at least ma= tch some other usage within ifconfig. Unfortunately I don't seem = to be able to attach patches correctly for GNATS, so here's a link: http://firepipe.net/ifconfig.c.118987-diff2.txt";>= http://firepipe.net/ifconfig.c.118987-diff2.txt --Will. --001636c5986450f9c20461c4cdef-- ___ 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"
CARP as a module; followup thoughts
Hello,
I've written a patch (against 8.0-CURRENT as of r191369) which makes
it possible to build, load, run, & unload CARP as a module, using the
GENERIC kernel. It can be obtained from:
http://firepipe.net/patches/carp-as-module-20090421.diff
Having written this patch, I have some thoughts. First of all, this
patch follows the same pattern of function pointers used by if_lagg,
if_vlan, ng_ether, bpf, and if_bridge. While it works, this approach
(along with that used by the other interfaces) is a hackish way to
implement the interfaces as kernel modules.
It appears that each one needs to have its hooks inserted at a
specific point in the packet processing. So it seems to me that a
better way to do this would be to implement a generic network protocol
interface and have everything that processes packets register its
hooks with that interface. Which if_* seems to do to an extent, but
not enough to meet the requirements of the above-mentioned network
protocols.
More to the point, netinet/in_proto.c & netinet6/in6_proto.c use
hardcoded protocol definition structures. Until this diff introduced
in{6,}_proto_{un,}register(), there was no way to define hooks for any
other protocols without hacking these files or compiling with
different options (like DEV_CARP).
I envision a struct ifnet_hooks array that includes hooks that can be
registered by any protocol for packet processing at any point,
including: pre-input, input, post-input, pre-output, output,
post-output, link state change, route, etc. Then each struct ifnet
would contain a list of these pointers, to be configured in a given
order depending on the administrator's needs. The interface would run
through the list for a given stage and run the protocol specific
function pointer to perform its processing at that stage.
Of course, that is probably a much too simplistic idea (there are a
lot of special cases it seems). And the reality is, there is already
something in FreeBSD that makes arbitrary packet processing hook order
possible - netgraph. So why is it FreeBSD allows these modules when
there are netgraph equivalents for all of them (currently, except
CARP)? More to the point, why isn't netgraph used for most (if not
all) packet processing?
Has anyone tried to build a kernel without INET? It's not pretty, and
demonstrates the biases the stack has towards IPv4 vs. other protocols
like IPv6. In other words, there's lots of code that looks like this:
#ifdef INET6
#endif
It would be nice if the stack didn't assume any particular protocol
base; making all protocols optional (except as explicitly defined by
direct dependency) seems a worthy goal.
I think it also might be useful to third party developers if they
didn't have to modify anything in the base kernel to insert a new
protocol in the stack.
I'm sure most of this sounds like rambling from a crazed lunatic or
something, but I'm also sure most who understand my patch agree that
it isn't the nicest of ways to make it possible to load carp (or any
other protocol) as a module.
Regards,
--Will.
___
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: CARP as a module; followup thoughts
On Wed, Apr 22, 2009 at 6:47 AM, Bruce M. Simpson wrote: > Hi, > > Will Andrews wrote: >> >> Hello, >> >> I've written a patch (against 8.0-CURRENT as of r191369) which makes >> it possible to build, load, run, & unload CARP as a module, using the >> GENERIC kernel. It can be obtained from: >> >> http://firepipe.net/patches/carp-as-module-20090421.diff >> > > There's no need to implement the in*_proto_register() stuff in that patch, > you should just be able to re-use the encap_attach_func() functions. Look at > how PIM is implemented in ip_mroute.c for an example. > > Other than that it looks like a good start... but would hold off on > committing as-is. the more general case of registering a MAC address on an > interface should be considered. Thank you very much for your feedback. I have implemented your suggestion as follows: http://firepipe.net/patches/carp-as-module-20090503-2.diff This version doesn't reinvent the wheel as far as registering the protocol goes. Personally, I think that notwithstanding your other objection, this should get committed, since it is a step in the right direction (perhaps minus the netinet6/in6_proto.c change that adds spacers). One step at a time! carp_encapcheck() is simplistic, but probably suffices (maybe also check to see if the vh MAC matches). This patch does work fine with my test setup, one system using GENERIC+if_carp and the other using a static build without the patch. I also found a "memory leak" in the original code, where it calls free(cif, M_IFADDR), which is wrong, it should be free(cif, M_CARP), since the original malloc uses M_CARP -- this fix is also included in the patch above. I've looked at the general case of registering a MAC address. I was going to try to include that change in this patch, but after reading the interface code for a while, I realized there isn't a general way to do that that seems settled. So it appears there needs to be a discussion on how to accomplish this. So, in struct ifnet, there is a field called if_addrhead which is a list of struct ifaddr's. This appears to be used for the general case of all addresses registered to a particular interface (AF_LINK aka lladdr's, plus AF_INET, AF_INET6, etc.). Now, we could use this with TAILQ_INSERT()'s for each virtual AF_LINK, and replace the applicable checks for "IF_LLADDR(ifp)" with a function that searches ifnet.if_addrhead for all AF_LINK entries and comparing the addresses to determine a match. Problem is, that's more O(n) than O(1), which is probably not acceptable. Perhaps a better way would be to replace ifnet.if_addrhead with a hash table for O(log n) search complexity, and possibly having separate hash tables for AF_LINK vs. other address families? Or maybe even one for each address family. That's probably overkill. There does seem to be a need to distinguish physical AF_LINKs from virtual though, since each physical interface driver uses IF_LLADDR(ifp) to refer to its physical address. Possibly ifaddr.ifa_flags could be used to make this distinction (though it seems to be used mainly for routing flags), but probably leave ifnet.if_addr as is for that purpose. Another way would be to have a separate list/hash table for virtual lladdr's (ifnet.ifvirt_lladdrhead?). I considered that but it seems better and more general to simply upgrade ifnet.if_addrhead. Regards, --Will. ___ 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: CARP as a module; followup thoughts
On Mon, May 4, 2009 at 10:04 AM, Bruce Simpson wrote: > I'll have to take your word for that as I'm not using CARP just at the > moment. I had to touch the mcast setup for the IPv6 SSM implementation. All > compiles OK, but I haven't tested the code other than loading it. Only IPv6 > multicast group setup should be affected. > > Does your patch apply against these revisions OK? It should. I am using git to develop these patches. I just did another sync (to r191794) and the diff from svn to my local git branch is the same as the patch I posted last night, so I presume it will apply to a fresh svn checkout of -current as of that revision. > Great stuff. > Can this bug fix be merged separately, i.e. before other code is committed? > That way it can get merged back to -STABLE more quickly, once RELENG_7 is > unfrozen. Yes, I can generate a separate patch for that one. If I were able to commit it myself, I'd certainly be doing it the way you suggest. I'd also suggest a more aggressive MFC timing for the free() bug fix than for the module feature (perhaps 3 days vs. 1-2 months, as 7.2R is now out). I am going to backport this patch to RELENG_7. Because of the way it is implemented, I believe it should be safe to MFC. > It would be good to have a more general code path for stuff like this to > benefit from using the perfect hash filters in modern NICs, the main thing > is that everything continues to work with no regressions :-) > > Thanks for the effort you've put into this, it will certainly help a lot of > folk to be able to ship a CARP-capable GENERIC kernel. Indeed, regressions will be difficult to prevent. I'm planning to work on virtual lladdrs for a bit to see if I can find a suitable solution for the problem. If nothing else, I think it provides a reasonable method for getting rid of carp_forus(), and possibly for implementing carpdev. Thanks, --Will. ___ 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: CARP on FreeBSD 7,2
On Fri, May 8, 2009 at 10:09 PM, Sam Wan wrote: > The following command also failed: > > test:~ # ifconfig carp1 vhid 1 pass password 192.168.2.144/24 up > ifconfig: ioctl (SIOCAIFADDR): Can't assign requested address > >> >> Hi, >> >> I tried to setup CARP in FreeBSD 7.2, but seems not able to assign IP to >> the carp interfaces. >> >> Here is my rc.conf file: >> >> hostname="test.ip6.com.au" >> ifconfig_fxp0="inet 192.168.1.248 netmask 255.255.255.0" >> sshd_enable="YES" >> >> pf_enable="YES" >> pf_rules="/etc/pf.anti-spam.conf" >> pf_flags="" >> pflog_enable="YES" >> pflog_logfile="/var/log/pflog" >> pflog_program="/sbin/pflogd" >> pflog_flags="" >> pfsync_enable="NO" >> pfsync_syncdev="" >> pfsync_ifconfig="" >> >> cloned_interfaces="carp1" >> ifconfig_carp1="up 24.214.165.129/25 vhid 2 pass privatepassword" >> >> >> test:~ # ifconfig >> fxp0: flags=8843 metric 0 mtu 1500 >> options=8 >> ether 00:13:20:65:ad:bd >> inet 192.168.1.248 netmask 0xff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> plip0: flags=108810 metric 0 mtu >> 1500 >> lo0: flags=8049 metric 0 mtu 16384 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff00 >> pflog0: flags=141 metric 0 mtu 33204 >> pfsync0: flags=0<> metric 0 mtu 1460 >> syncpeer: 224.0.0.240 maxupd: 128 >> carp1: flags=9 metric 0 mtu 1500 >> carp: INIT vhid 1 advbase 1 advskew 50 >> >> What have I missed? Hi, Currently, the only way to assign an IP address for CARP is to use an IP that is in the same subnet as the physical interface you intend to handle its packets. In other words, since neither 192.168.2.144/24 nor 24.215.165.129/25 are in 192.168.1.248/24, they cannot be assigned to any CARP interface. Eventually, this should be fixed by introducing carpdev, which allows explicitly associating a CARP interface with a physical interface, but it's not there yet. Regards, --Will. ___ 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"
Bridging in FreeBSD without one side being blocked?
Hello (please cc: me as I am not subscribed, thanks), I was wondering if anyone has managed to set up bridge in such a way that hosts on both sides will be able to access the machine doing the bridging. The reason I need this is because I need to join two media types (10baseT/100baseTX and 1000baseSX), and both sides of the bridge need access to the machine in question. I'd prefer to do it like this instead of buying another switch with the necessary media ports or a media converter just for this. As far as I can tell, it does not seem like FreeBSD's BRIDGE is capable of doing this sort of thing. Does someone know if ng_bridge can do it, or if it could be made to with some slight modifications? I could not find any documentation about someone that has done something like this. I should note.. later I may add an Atheros card to the bridge, configured in 802.11a host AP mode. Same conditions apply. :) Seems to me that if a packet is destined for an IP associated with any of the bridge's child interfaces, the code should recognize that the packet can be delivered directly to it, as opposed to simply dropping it. Thanks in advance! -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Differential] [Changed Subscribers] D1881: Allow Illumos code to co-exist with nv(9)
will added a subscriber: will. will added a comment. What testing has been done with this change? REVISION DETAIL https://reviews.freebsd.org/D1881 To: rstone, jfvogel Cc: will, emaste, pjd, freebsd-net ___ 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"
[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)
will added a comment. >>! In D1881#9, @rstone wrote: > The primary testing that I did was to ensure that a kernel with "device zfs" > would still link. However, I suppose that doesn't exclude the possibility of > their being an zfs source file that is built wrong and doesn't include this > header. Is there a zfs test suite that I could run? Not yet, unfortunately. It's in the zfsd project branch, but needs some work so it can be pushed into head. It'd probably be sufficient to load zfs and create pools/filesystems, and a few other basic tests. Are the userland bits covered (and tested) with this change? This is a overload (effectively), which may be pulled into the userland zfs builds. REVISION DETAIL https://reviews.freebsd.org/D1881 To: rstone, jfvogel Cc: will, emaste, pjd, freebsd-net ___ 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"
[Differential] [Accepted] D1881: Allow Illumos code to co-exist with nv(9)
will accepted this revision. will added a reviewer: will. will added a comment. Ok, LGTM. Thanks for your effort! REVISION DETAIL https://reviews.freebsd.org/D1881 To: rstone, jfvogel, will Cc: will, emaste, pjd, freebsd-net ___ 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"
