Re: Network Card
On 2009-Apr-21 14:02:38 -0700, Barney Cordoba wrote: >On all of the MBs that I have, the slot NIC appears before the onboard >ports in the pciconf -l listing. Its certainly not for sure. As a datapoint to add to the uncertainty, the SunFire V440 has 4 motherboard NICs - two come before the PCI slots and two after (so adding a PCI-based Cassini nic moves ce2 from the MB to the plugin). Even slot numbering on larger boxes (with multiple physical PCI buses) can be non (or counter) intuitive. Also note that FreeBSD has also changed its PCI probe order at least once in the past (effectively re-numbering devices). -- Peter Jeremy pgpmwIOlUjC3E.pgp Description: PGP signature
Re: IPFW missing feature
Chris Cowart wrote: KES wrote: , Lowell. ?? ?? 16 ?? 2009 ?., 15:22:31: LG> KES writes: The tablearg feature provides the ability to use a value, looked up in the table, as the argument for a rule action, action parameter or rule option. This can significantly reduce number of rules in some configura- tions. If two tables are used in a rule, the result of the second (des- tination) is used. The tablearg argument can be used with the following actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto action parameters: tag, untag, rule options: limit, tagged. Why tablearg cannot be used with setfib? LG> Because tables are a feature of IPFW, and the FIB isn't. setfib is also feature of ipfw. see man: setfib fibnum The packet is tagged so as to use the FIB (routing table) fibnum in any subsequent forwarding decisions. Initially this is limited to the values 0 through 15. See setfib(8). Processing continues at the next rule. There is no any difficulties to use 'tablearg' as 'fibnum' ipfw add 3 setfib 2 all from 192.168.0.0/16 to any in recv ipfw add 3 setfib tablearg all from table() to any in recv but now this is not mistake to write 'setfib tablearg'. IPFW just replace tablearg in rule with 0 It seems like a bug. because of it MUST work in proper way or DO NOT work at all. IMHO I use tablearg with netgraph. For example, ipfw add netgraph tablearg all from 'table(9)' to any in When I run ipfw show, I see: 02380 408 60358 netgraph tablearg ip from any to table(9) in KES, do you mean to say that when you run `ipfw show' the rule is echoed back to you as: setfib 0 all from table() to any in recv instead of tablearg? If that's the case, it sounds like ipfw is parsing the rule incorrectly. If tablearg isn't supported by setfib, I would expect a syntax error to be thrown and not a different rule being inserted into your ruleset. If this is the behavior you're seeing, you should run it by the folks on the -net mailing list. That would also be a good place to ask about future plans to support this feature. Unfortunately 'tablearg' is not implemented in the code as a generic thing, but rather needs to be implemented separately for each place where it may be used. In this case I simply didn't think of it when I added setfib. It does make sense to allow it and I will consider adding this in the future as it would be useful for policy routing. ___ 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: IPFW missing feature
KES wrote: > , Lowell. > > ?? ?? 16 ?? 2009 ?., 15:22:31: > > LG> KES writes: > >>> The tablearg feature provides the ability to use a value, looked up in >>> the table, as the argument for a rule action, action parameter or rule >>> option. This can significantly reduce number of rules in some >>> configura- >>> tions. If two tables are used in a rule, the result of the second >>> (des- >>> tination) is used. The tablearg argument can be used with the >>> following >>> actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto >>> action parameters: tag, untag, rule options: limit, tagged. >>> >>> >>> Why tablearg cannot be used with setfib? > > LG> Because tables are a feature of IPFW, and the FIB isn't. > > setfib is also feature of ipfw. see man: > > setfib fibnum > The packet is tagged so as to use the FIB (routing table) fibnum > in any subsequent forwarding decisions. Initially this is limited > to the values 0 through 15. See setfib(8). Processing continues > at the next rule. > > There is no any difficulties to use 'tablearg' as 'fibnum' > > ipfw add 3 setfib 2 all from 192.168.0.0/16 to any in recv > ipfw add 3 setfib tablearg all from table() to any in recv > > but now this is not mistake to write 'setfib tablearg'. IPFW just > replace tablearg in rule with 0 > It seems like a bug. because of it MUST work in proper way or DO NOT > work at all. IMHO I use tablearg with netgraph. For example, ipfw add netgraph tablearg all from 'table(9)' to any in When I run ipfw show, I see: 02380 408 60358 netgraph tablearg ip from any to table(9) in KES, do you mean to say that when you run `ipfw show' the rule is echoed back to you as: setfib 0 all from table() to any in recv instead of tablearg? If that's the case, it sounds like ipfw is parsing the rule incorrectly. If tablearg isn't supported by setfib, I would expect a syntax error to be thrown and not a different rule being inserted into your ruleset. If this is the behavior you're seeing, you should run it by the folks on the -net mailing list. That would also be a good place to ask about future plans to support this feature. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley ___ 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
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. cheers, BMS ___ 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: Network Card
Kaushal Shriyan wrote: ... so there is no such command line utility to get to know about that information on Free BSD ? There is no sure fire way to get that information anywhere, unless you're working with a system which has implemented PCI geographical addressing. Some of this is present in hotplug support. If someone pays for the feature, I'm sure it can get done... Having said that you should be able to make educated guesses about where something is, just by looking at the bus hierarchy (e.g. using devinfo or similar tool). This is no different from anywhere else that implements PCI. thanks, BMS ___ 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
Will Andrews wrote: 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. Not at all. It is a mess to be sure. One of the criticisms of Netgraph is that it is poorly understood outside of its immediate developer community. The BSD networking stack has a number of textbooks written for it, Netgraph does not, and it probably factored into the decision of Itronix to sponsor a from-scratch implementation of Bluetooth for NetBSD -- netgraph has been considered 'a bridge too far', to score a cheesy pun. It has also been criticised for performance, although I am not in a position to judge either way at the moment, I simply don't have all the information to hand, and am busy doing other things often. I don't have time to look at your patch right now, unfortunately, but can try to make time when less pressed. When I last looked at the CARP hooks, during the ether_input() cleanup, all that was really missing was the ability to register soft MAC addresses in the perfect hash filter entries other than the one programmed into the card (or configured via ifconfig(8) mechanisms). cheers BMS ___ 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"
