Re: ether_input question
On Fri, 16 Mar 2007, Aniruddha Bohra wrote: Robert Watson wrote: I can't speak to the details of the above, but can speak generally on the issue of the link layer input path and locking. There is no assumption that the caller will provide serialization, and fully concurrent input from multiple threads is supported. The reason the drivers drop their locks is that the network stack frequently holds locks over calls to driver output routines. As a result, driver locks tend to follow network stack locks in the lock order--at least, for drivers that have a single lock covering both send and receive paths (quite common). As a result, the driver must drop the driver lock before calling into the stack to avoid a lock order reversal. So, if I have a queue shared between ether_input() and another thread, I need to ensure mutual exclusion. In such scenarios, should spinlocks or default mutexes be used? I'm not sure I completely understand the scenario you are suggesting -- could you be specific? Normally, from the perspective of a device driver author, you simply drop your driver-specific locks and call ifp->if_input() to hand the mbuf chain up to the link layer. No locks need to be held around the call to the input routine. On the other hand, if you are modifying the link layer itself (i.e., hooking into it in one of a number of ways), this means that you must provide any synchronization necessary to make your code operate correctly in the presence of concurrency. Many instances of ether_input() may run at the same time on various CPUs -- typically one per input source, since they run in the ithread of the device driver. In general, you should use default mutexes in preference to spin mutexes unless you know your code will run the fast interrupt path (rather than the ithread path). Universally, the network stack assumes it will not run in the fast interrupt path, so unless you're doing something quite low level and special involving a device driver, default mutexes (or rwlocks if you need shared locking) are the right way to go. The driver locks themselves are usually MTX_DEF, whereas in netgraph for example, (the scenario above), a spinlock is used. Is there a rule of thumb, for example, never use blocking locks in the network interrupt path? I am not sure why Netgraph uses spin locks -- it probably shouldn't be doing so. In the kernel we have several different notions of "sleeping", and unfortunately the terminology is not entirely clear. The best way I've found to explain it is using the term "bounded". Sleeping associated with mutexes and rwlocks is bounded sleeping, whereas sleeping associated with condition variables, wait channels, and sx locks is unbounded sleeping. This distinction is important because you don't want, for example, an interrupt thread performing an unbounded sleep waiting on something that may not happen for a very long (unbounded) period of time, such as waiting for keyboard input or disk I/O to return. If you run with INVARIANTS and WITNESS, a debugging kernel should warn you if you try to acquire the wrong type of lock in the wrong context. A locking(9) man page talking about some of the selection choices was recently added to 7-CURRENT, FYI. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Troubleshooting aliases.
Hi folks, Been running into brick walls since last night on this one. Situation is that our server has 6.1-RELEASE on it with four IP addresses. The section of rc.conf is this: ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" For some reason, with no updates or changes both a.a.a.b and a.a.a.c have stopped working properly. a.a.a.a works fine, as does a.a.a.d. Unfortunately, the nameservers for the domains hosted on the server use a.a.a.b and a.a.a.c! So basically I can't figure out what's up as .d works fine..anyone able to help me with some suggestions of where to look for fixing .b and .c? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubleshooting aliases.
On Sat, 17 Mar 2007, Colin Waring wrote: > Hi folks, > Been running into brick walls since last night on this one. > Situation is that our server has 6.1-RELEASE on it with four IP addresses. > > The section of rc.conf is this: > > ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" > ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" > ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" > ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" > > For some reason, with no updates or changes both a.a.a.b and a.a.a.c have > stopped working properly. a.a.a.a works fine, as does a.a.a.d. Sorry if it should be obvious, but stopped working properly in what way? > Unfortunately, the nameservers for the domains hosted on the server use > a.a.a.b and a.a.a.c! > > So basically I can't figure out what's up as .d works fine..anyone able to > help me with some suggestions of where to look for fixing .b and .c? Works fine at doing what, by comparison? Cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubleshooting aliases.
Somewhere around Sat, Mar 17, 2007 at 14:10 , the world stopped and listened as Colin Waring graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: > Hi folks, > Been running into brick walls since last night on this one. > Situation is that our server has 6.1-RELEASE on it with four IP addresses. > > The section of rc.conf is this: > > ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" > ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" > ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" > ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" > For some reason, with no updates or changes both a.a.a.b and > a.a.a.c have stopped working properly. a.a.a.a works fine, as > does a.a.a.d. > > Unfortunately, the nameservers for the domains hosted on the > server use a.a.a.b and a.a.a.c! > So basically I can't figure out what's up as .d works fine..anyone able to > help me with some suggestions of where to look for fixing .b and .c? You showed up your rc.conf. What might be more helpful is the output of 'ifconfig'. Perhaps the aliases have been deleted. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubleshooting aliases.
I'm sure I wrote out some more info than that but apparently not. I must be getting confused as I did a description somewhere else, sorry! Basically, .a and .d respond to pings and pass all traffic .b and .c respond to pings but don't appear to pass any other traffic. IPF is compiled but I've completely turned it off for testing None of the actual configuration has changed though so I wouldn't expect anything to show up in ifconfig any as it was all working like this previously.. em0: flags=8843 mtu 1500 options=b inet6 fe80::215:c5ff:fe5d:f7b7%em0 prefixlen 64 scopeid 0x1 inet a.a.a.a netmask 0xff00 broadcast a.a.a.255 inet a.a.a.b netmask 0x broadcast a.a.a.255 inet a.a.a.c netmask 0x broadcast a.a.a.255 inet a.a.a.d netmask 0x broadcast a.a.a.255 ether 00:15:c5:5d:f7:b7 media: Ethernet autoselect (100baseTX ) status: active Thanks Colin. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x?
On Saturday 17 March 2007 07:38, Alex Povolotsky wrote: > Does anyone have any positive experience with Intel WiFi adapter on > Lenovo R60 with FreeBSD 6.X? That would be the 3945abg part, right? In that case you want the driver from here: http://www.clearchain.com/wiki/Wpi > Native driver or ndis, does not matter. I have heard that ndis doesn't work for this one, but I wouldn't know. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpSeD5ze4MmM.pgp Description: PGP signature
Re: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x?
Max Laier wrote: On Saturday 17 March 2007 07:38, Alex Povolotsky wrote: Does anyone have any positive experience with Intel WiFi adapter on Lenovo R60 with FreeBSD 6.X? That would be the 3945abg part, right? In that case you want the driver from here: http://www.clearchain.com/wiki/Wpi Already wrote to author - it recognize card, but attempt to ifconfig it up results in computer lockup Native driver or ndis, does not matter. I have heard that ndis doesn't work for this one, but I wouldn't know. Yes, for me it did not work. Alex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubleshooting aliases.
On Sat, 17 Mar 2007, Colin Waring wrote: > Basically, .a and .d respond to pings and pass all traffic > .b and .c respond to pings but don't appear to pass any other traffic. > > IPF is compiled but I've completely turned it off for testing If you run one tcpdump on lo0 and another on em0 and try 'other traffic' you should be able to see which packets are/n't getting out, or through. Other things maybe worth checking: # netstat -finet -rna # after pinging all your aliases # arp -an # check address (incl bcast) at MAC on interface # sockstat -4 # which addresses/ports are listening/connected > None of the actual configuration has changed though so I wouldn't expect > anything to show up in ifconfig any as it was all working like this > previously.. > > em0: flags=8843 mtu 1500 > options=b > inet6 fe80::215:c5ff:fe5d:f7b7%em0 prefixlen 64 scopeid 0x1 > inet a.a.a.a netmask 0xff00 broadcast a.a.a.255 > inet a.a.a.b netmask 0x broadcast a.a.a.255 > inet a.a.a.c netmask 0x broadcast a.a.a.255 > inet a.a.a.d netmask 0x broadcast a.a.a.255 > ether 00:15:c5:5d:f7:b7 > media: Ethernet autoselect (100baseTX ) > status: active Did you specify those broadcast addresses on b, c and d? Here I'd see a.a.a.b through a.a.a.d broadcast addresses for those having 0x netmasks (on 5.5-S) but don't know if that's relevant to your problem. Cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Troubleshooting aliases.
Thanks to anyone who had a think about this one. It appears the cause is a bit simpler than thought. Quite simply, the hosting centre have apparantly allocated the IP addresses to someone else so whilst there is something responding, it isn't actually the right machine. Numpties. :) Regards, Colin. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wireshark
Can someone please explain the difference between Wireshark and Wireshark-lite. I would like to install a packet sniffer on my FreeBSD box for CLI only. Thanks, Manuel Ochoa CCNP MCSA MCSE MCDBA I will not fake my way through life! Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireshark
On Saturday 17 March 2007 19:16, [EMAIL PROTECTED] wrote: > Can someone please explain the difference between Wireshark and > Wireshark-lite. I would like to install a packet sniffer on my FreeBSD > box for CLI only. Thanks, What's wrong with tcpdump(8)? Other than that building either the real or the -lite version with "WITHOUT_X11" defined will get you the cli-version. "-lite" seems to just disable a couple of dissectors that have a lot of external dependencies. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp6VwnssPkqC.pgp Description: PGP signature
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Good day. Tue, Mar 13, 2007 at 08:50:29AM +0300, Eygene Ryabinkin wrote: > Sure. And that is why all switches that can bear the IP on their > interfaces have distinct MACs for each interface or/and the only > one interface can have the IP. And that is why I am going to > add the paragraph to the if_bridge(4) describing the current situation > and giving advice on the setting IP for the bridge members and the > bridge itself. Will provide the patch in a day or two. OK, the patch to the if_bridge.4 is attached. It is rather lengthy, but I don't know how to make it clear with less amount of words. Comments are welcome. -- Eygene --- if_bridge.4.origSun Mar 4 15:37:22 2007 +++ if_bridge.4 Sat Mar 17 22:18:52 2007 @@ -219,9 +219,67 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table according to the packet destination address (not the MAC +address). +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. Be prepated to the situation when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). It is not possible +to distinguish between these interfaces using their MAC address, +excluding the case when the packet's destination MAC address is +equal to the MAC address of the interface on which the packet was +entered to the system. In this case the filter will see the incoming +packet on this interface. In all other cases the interface seen +by the packet filter is almost randomly chosen from the list of +bridge members with the same MAC address. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let the MAC address of the incoming packet's destination will be +.Nm nn:nn:nn:nn:nn:nn , +the interface on which packet entered the system is +.Nm vlanX +with the MAC address +.Nm xx:xx:xx:xx:xx:xx +and the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. Then if MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm vlanX +no matter if there are some other bridge members carrying the same +MAC address. But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is some of the +.Nm vlanYn , +but it is not possible to know the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. So if one wants +the filter the locally destined packets based on their interface name, +he should be aware of this implication. Such situation will appear on the +filtering bridges that are doing IP-forwarding; in this case it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireshark
On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Can someone please explain the difference between Wireshark and Wireshark-lite. I would like to install a packet sniffer on my FreeBSD box for CLI only. lite = cli only ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv4, IPv6 and link-layer multicast refcounting in bms_netdev
I have just committed reference counting for multicast structures in p4. Change list number is 116036. This should fix the problems with pfsync and carp since the scalability fixes for IPv4 multicast last September. A further cumulative fix for pfsync is present in this branch. Basic testing with the stock IPv4 and Ethernet code have been performed. Further testing would be much appreciated before the code is merged to HEAD. The refcounting has been implemented in a way so as not to break the 6.x ABI so that it may be merged to STABLE. It would be great to have feedback on how these patches may affect vlan(4) which is the only other consumer of the in_delmulti() KPI. My experience working on this suggests IFF_NEEDSGIANT is a real headache for dealing with ifnets which may potentially go away during the lifetime of the system. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MFCing rev 1.96 of netinet/in.c for Zeroconf
The change itself is very simple; http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.95&r2=1.96 This change is necessary before IPv4 address scope and source selection policy may be implemented. Does anyone see any potential problems with this? It is possible that there are people out there forwarding between LANs with 169.254.0.0/16 subnetted on different interfaces, though this is not RFC compliant behaviour, so I'd like to hear about that before I merge it. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Wireshark
On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote: > On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Can someone please explain the difference between Wireshark > > and Wireshark-lite. I would like to install a packet sniffer > > on my FreeBSD box for CLI only. > > lite = cli only That's not correct. See my previous email. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpWT7cuz3tXL.pgp Description: PGP signature
Re: Wireshark
On 3/17/07, Max Laier <[EMAIL PROTECTED]> wrote: On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote: > On 3/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Can someone please explain the difference between Wireshark > > and Wireshark-lite. I would like to install a packet sniffer > > on my FreeBSD box for CLI only. > > lite = cli only That's not correct. See my previous email. Yep, sorry. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ether_input question
Aniruddha Bohra wrote: Hi, In two drivers, fxp and em, the assumptions about entering the ether_input routine are different. From em_rxeof: #ifdef DEVICE_POLLING EM_UNLOCK() (*ifp->if_input)() EM_UNLOCK() #else (*ifp->if_input)() #endif While in fxp: FXP_UNLOCK() (*ifp->if_input)() FXP_LOCK() My question is : Does ether_input() assume it is the only thread executing the code? If it is the case, what is the reason for dropping the lock in the DEVICE_POLLING case? There is actually no difference between these cases. In the !DEVICE_POLLING case, the em driver does not hold its driver lock when it calls em_rxeof. The call is made from em_handle_rxtx, where you'll see that the driver has not acquired a lock when it calls em_rxeof. Thus, in all cases the if_input function is called without holding the driver lock. John ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc.order wrong (ipfw)
[ Re-locating this thread from -stable. ] Mark Andrews wrote: On Saturday 17 March 2007 03:58, Mark Andrews wrote: nothing goes to this machine because by default everything is blocked until you permit it You're absolutely correct, however your original post seems to have taken many of us by surprise, causing some of us (at least me!) to assume that you've changed the default method to allow. I'm obviously misunderstanding, so I apologise for that, but I hope you can see the reasoning behind my comments with what I knew at the time. :) ipfw needs to be before networking or router discovery fails for IPv6. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 as default any network connection will fail so long as you do not permit it If rtsol fails or is called to early it is an rtsol problem and not an ipfw problem I guess named and ipfw before netif? ip6fw is before networking. ipfw is supposed to be taking over from ip6fw. ipfw and ip6wf should be started at a similar time. rtsol is approximately the equivalent to DHCP. The machine is requesting a address from the network. It doesn't matter if it is a router or a DHCP server that is suppling the address. DHCP only works because it bypasses the firefall. Mark, Currently the order (with some non-networking items removed) is: /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/sppp /etc/rc.d/auto_linklocal /etc/rc.d/pccard /etc/rc.d/netif /etc/rc.d/ip6addrctl /etc/rc.d/atm2 /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/isdnd /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ip6fw /etc/rc.d/network_ipv6 /etc/rc.d/ipsec /etc/rc.d/ipfw /etc/rc.d/nsswitch /etc/rc.d/mroute6d /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/NETWORKING ipfilter starts very early in the "late" section of rcorder, it requires mountcritlocal (the default early_late_divider) and has a BEFORE: netif. Currently ip6fw actually starts after routing (and therefore after netif). Before we move it I think someone who knows more about how rtsol works than I do should comment. AFAICT, network_ipv6 is going to need routing up. If ip6fw's functionality is going to be subsumed into ipfw, then changing ipfw to run before netif now, and nuking ip6fw later is probably sufficient. If it's reasonable to conclude that we want all the firewalls to start before netif, I see two ways to accomplish that. One would be to have netif REQUIRE ipfilter, pf, and ipfw. In some ways I think this is cleaner, but netif already has a pretty long REQUIRE line. The other way would be to add a new FIREWALLS placeholder for the REQUIREs I'm suggesting above, and then have netif REQUIRE that. If on the other hand, there is some reason NOT to start all the firewalls before netif, then things get more complicated. :) The attached patch changes the rcorder to the following: /etc/rc.d/sppp /etc/rc.d/ipfw /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/auto_linklocal /etc/rc.d/serial /etc/rc.d/netif /etc/rc.d/ip6addrctl /etc/rc.d/atm2 /etc/rc.d/isdnd /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ip6fw /etc/rc.d/network_ipv6 /etc/rc.d/ipsec /etc/rc.d/nsswitch /etc/rc.d/mroute6d /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/NETWORKING Thoughts? Doug -- This .signature sanitized for your protection Index: ip6fw === RCS file: /usr/local/ncvs/src/etc/rc.d/ip6fw,v retrieving revision 1.8 diff -u -r1.8 ip6fw --- ip6fw 31 Dec 2006 10:37:18 - 1.8 +++ ip6fw 17 Mar 2007 21:28:18 - @@ -5,7 +5,6 @@ # PROVIDE: ip6fw # REQUIRE: routing -# BEFORE: network_ipv6 # KEYWORD: nojail . /etc/rc.subr Index: ipfilter === RCS file: /usr/local/ncvs/src/etc/rc.d/ipfilter,v retrieving revision 1.26 diff -u -r1.26 ipfilter --- ipfilter31 Dec 2006 10:37:18 - 1.26 +++ ipfilter17 Mar 2007 21:15:21 - @@ -6,7 +6,6 @@ # PROVIDE: ipfilter # REQUIRE: root mountcritlocal -# BEFORE: netif # KEYWORD: nojail . /etc/rc.subr Index: ipfs === RCS file: /usr/local/ncvs/src/etc/rc.d/ipfs,v retrieving revision 1.6 diff -u -r1.6 ipfs --- ipfs7 Oct 2004 13:55:26 - 1.6 +++ ipfs17 Mar 2007 21:15:43 - @@ -6,7 +6,6 @@ # PROVIDE: ipfs # REQUIRE: ipnat -# BEFORE: netif # KEYWORD: nojail shutdown . /etc/rc.subr Index: ipfw === RCS file: /usr/local/ncvs/src/etc/rc.d/ipfw,v retrieving revision 1.14 diff -u -r1.14 ipfw --- ipfw31 Dec 2006 10:37:18 - 1.14 +++ ipfw17 Mar 2007 21:31:21 - @@ -4,8 +4,7 @@ # # PROVIDE: ipfw -# REQUIRE: ppp -# BEFORE: NETWORKING +# REQUIRE: root
Re: ether_input question
The reason the drivers drop their locks is that the network stack frequently holds locks over calls to driver output routines. As a result, driver locks tend to follow network stack locks in the lock order--at least, for drivers that have a single lock covering both send and receive paths (quite common). As a result, the driver must drop the driver lock before calling into the stack to avoid a lock order reversal. Just to further clarify the corollary to this statement - drivers that separately lock their softc, tx, and rx queues don't need to drop the lock across if_input as there is no possibility of lock order reversal between the input and the output path. -Kip ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rc.order wrong (ipfw)
Doug Barton wrote: > > If it's reasonable to conclude that we want all the firewalls to start > before netif, I see two ways to accomplish that. One would be to have > netif REQUIRE ipfilter, pf, and ipfw. In some ways I think this is > cleaner, but netif already has a pretty long REQUIRE line. The other > way would be to add a new FIREWALLS placeholder for the REQUIREs I'm > suggesting above, and then have netif REQUIRE that. > > If on the other hand, there is some reason NOT to start all the > firewalls before netif, then things get more complicated. :) > > I definitely think that firewalls should be started as early as possible, for obvious reasons. I can't speak for ipfw, but removing the REQUIRE: netif for pf might break some setups where the ruleset references a cloned interface that netif creates. Correct me if I'm wrong? Loading a minimal ruleset initially (as OpenBSD and NetBSD do) would solve that problem, at least for pf. The idea has been discussed a few times before but I didn't see it go anywhere. http://lists.freebsd.org/pipermail/freebsd-pf/2007-February/003041.html I'd love to see the rcorder for the firewalls get worked out! :) Kian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Julian, good day. > >+.Pp > >+The packets destined to the bridging host will be seen by the filter > >+on the interface with the MAC address equal to the packet's destination > >+MAC. Be prepated to the situation when some of the bridge members are > >sharing > > prepated to ? > prepared for? ??? You're right, thanks for spotting the error. The corrected patch is attached. -- Eygene --- if_bridge.4.origSun Mar 4 15:37:22 2007 +++ if_bridge.4 Sun Mar 18 08:13:53 2007 @@ -219,9 +219,67 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table according to the packet destination address (not the MAC +address). +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. Be prepared for the situation when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). It is not possible +to distinguish between these interfaces using their MAC address, +excluding the case when the packet's destination MAC address is +equal to the MAC address of the interface on which the packet was +entered to the system. In this case the filter will see the incoming +packet on this interface. In all other cases the interface seen +by the packet filter is almost randomly chosen from the list of +bridge members with the same MAC address. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let the MAC address of the incoming packet's destination will be +.Nm nn:nn:nn:nn:nn:nn , +the interface on which packet entered the system is +.Nm vlanX +with the MAC address +.Nm xx:xx:xx:xx:xx:xx +and the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. Then if MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm vlanX +no matter if there are some other bridge members carrying the same +MAC address. But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is some of the +.Nm vlanYn , +but it is not possible to know the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. So if one wants +the filter the locally destined packets based on their interface name, +he should be aware of this implication. Such situation will appear on the +filtering bridges that are doing IP-forwarding; in this case it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
