Re: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC
Yar Tikhiy wrote:
My proposed check for IFF_DRV_RUNNING is by no means a priority
task. I can add it by myself after you finish your great current
project regarding ether_input() and friends.
Just committed in p4:
//depot/user/bms/netdev/sys/net/if_ethersubr.c#6 -
/home/bms/p4/netdev/sys/net/if_ethersubr.c
--- /tmp/tmp.11470.0Tue Mar 6 15:45:08 2007
+++ /home/bms/p4/netdev/sys/net/if_ethersubr.c Tue Mar 6 15:45:01 2007
@@ -511,6 +511,13 @@
m_freem(m);
return;
}
+#ifdef DIAGNOSTIC
+ if ((ifp->if_flags & IFF_DRV_RUNNING) == 0) {
+ if_printf(ifp, "discard frame at !IFF_DRV_RUNNING\n");
+ m_freem(m);
+ return;
+ }
+#endif
Thanks!
BMS
___
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
Eygene Ryabinkin wrote: I am awfully sorry, but you're seem to be mistaken: Thanks for clarifying this. That'll be because I didn't read if_bridge that far. ;^) In my original message I was just looking at if_ethersubr.c. I need to make sure any changes which are made to if_bridge to deal with vlan problems are incorporated into bms_netdev so that after I commit M_PROMISC, it does the right thing. if_bridge calls the ipfw directly only for the L2 filtering (when the net.link.bridge.ipfw is set to 1). This is processed by the block in if_bridge just above to the 'ipfwpass' label. In bms_netdev, the behaviour of ether_demux() is unchanged. ip_dn_claim_rule() is called to determine if there is an IPFW (usually dummynet) rule for the input frame at ethernet level, if-and-only-if net.link.ether.ipfw is non-zero. I just committed some comments to clarify this and styled it the same as the check in ether_output_frame(). However -- the IPFW check in ether_demux() is *skipped* in bms_netdev if M_PROMISC is set. This is because we might drop packets which are destined for vlan_input() which flow in because the interface is IFF_PROMISC. Strictly speaking this bends the rules of dummynet, because if you have frames coming in due to promiscuous mode, which the rest of the stack doesn't expect, they won't be filtered by Dummynet pipes. But the L3 filtering is done fully by the pfil hooks, as I understand the code. Moreover, I am using 'pf' in my case, not the ipfw. Yes, this is always the case for the upper layers. 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: [PATCH] Ethernet cleanup; 802.1p input and M_PROMISC
Julian Elischer wrote: When we added netgraph we split both the input and output parts so that they would provide 'natural' entrypoints for a bridge. Consider where a bridge wants to put packets. In bms_netdev, bridge_input() is entered directly from ether_input(). It may potentially re-enter, so M_PROMISC is cleared on frames thus handed off to if_bridge(4). Same for ng_ether(4). Since the split however other code has made use of those entrypoints at different times. I'm not sure at the moment whether other code does so now. According to KScope on -CURRENT, the only other places which call the split ether_demux() are dummynet_send() and ng_ether_rcv_upper(). 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: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Ok, since no one want to provide an explanation I'll to do it myself.
Lets assume that we have two interfaces that are joined to bridge.
I'll call them as A and B. Both has a distinct MACs.
Now we have two cases for behaviour of filtering. The first case that
we will behave like real hub between the physical interfaces and its
virtual logical representation. The packet will arise on logical interface
for which it is intended for (according to dst MAC). That is how it
is implemented now. So now we can filter packets treating dst interface
as incoming, but not the interfaces it comes through physically.
The second variant to do visa versa, e q filter packets according interfaces
they physically come in, and do not take in to account the dst MAC.
Both variant have bad sides and good sides. Both are not wrong from the
filtering point of view. So I do not want to discuss which one is correct.
Now about the problem. Lets assume that we also have a C interfaces,
but with VLANs or anything that will bring the same situation. I'll call
VLANs C1,C2...CN.
Now we can't implement the first case without a problems, cause all Cx
will have the same MAC, MAC of the C interface. In current implementation
we will take the first interface on the list, which would be the last added
to the bridge. This problem could be fixed. Be patient, I'll describe
all cases,
but not at once. Read till the end of the letter.
If I understand right the Eygene's patch solves problem by introducing the
second behaviour. It is not quite good cause it will change the old known
behaviour. Here is the patch itself:
--- if_bridge.c.orig Fri Mar 2 18:23:56 2007
+++ if_bridge.c Sat Mar 3 05:04:38 2007
@@ -2122,7 +2122,11 @@
LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) {
if (bif2->bif_ifp->if_type == IFT_GIF)
continue;
-/* It is destined for us. */
+/* It is destined for us. We should not rely on the
+ * found interface's MAC as the interface identifier,
+ * because vlanX interfaces are sharing their MAC
+ * with the parent. Moreover, we do know the interface
+ * the packet is coming from. So we're using it. */
if (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost,
ETHER_ADDR_LEN) == 0
#ifdef DEV_CARP
@@ -2133,7 +2137,7 @@
if (bif->bif_flags & IFBIF_LEARNING)
(void) bridge_rtupdate(sc,
eh->ether_shost, bif, 0, IFBAF_DYNAMIC);
-m->m_pkthdr.rcvif = bif2->bif_ifp;
+m->m_pkthdr.rcvif = ifp;
BRIDGE_UNLOCK(sc);
return (m);
}
I suggest to fix this problem in the other way, by checking if the
physical interface
is the dst interface by MAC. Eq if we got packet from Ci, it will be
market as received
from Ci, not from Cj. Yes it will add double checking for this interface
it is not the
dst with some probability, but will optimize the case the dst is the
current one cause
we will not check the list. This will keep the old behaviour eq case 1
and will do the
same trick for cases like VLANs. Here my variant of the patch:
+/* Give a chance for ifp at first priority. This will help in case we
+ * the packet comes through the interface with VLAN's and the same
+ * MACs on several interfaces in a bridge. Also will save some circles
+ * in case dst interface is the physical input interface (eq ifp).
+ */
+if (ifp->if_type == IFT_GIF
+&& (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost,
+ETHER_ADDR_LEN) == 0
+#ifdef DEV_CARP
+|| (bif2->bif_ifp->if_carp
+&& carp_forus(bif2->bif_ifp->if_carp, eh->ether_dhost))
+#endif
+)) {
+if (bif->bif_flags & IFBIF_LEARNING)
+(void) bridge_rtupdate(sc,
+eh->ether_shost, bif, 0, IFBAF_DYNAMIC);
+m->m_pkthdr.rcvif = ifp;
+BRIDGE_UNLOCK(sc);
+return (m);
+}
LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) {
if (bif2->bif_ifp->if_type == IFT_GIF)
continue;
/* It is destined for us. */
if (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost,
ETHER_ADDR_LEN) == 0
#ifdef DEV_CARP
|| (bif2->bif_ifp->if_carp
&& carp_forus(bif2->bif_ifp->if_carp, eh->ether_dhost))
#endif
) {
if (bif->bif_flags & IFBIF_LEARNING)
(void) bridge_rtupdate(sc,
eh->ether_shost, bif, 0, IFBAF_DYNAMIC);
m->m_pkthdr.rcvif = bif2->bif_ifp;
Re: mpd success stories, anyone?
We're running PPPoE services with mpd 4.1 on FreeBSD 6.2-STABLE without any flaws for about 3 weeks. Opened ng interfaces: 2048 Avg usage: 500 Still migrating.. usage will grow soon. The hardware is: 2 x Intel Xeon 5110 with 1 Gig Memory and nics Intel Pro/1000 (em) the machine is a gateway to several other networks and is currently performing at ~80% idle CPU and ~10% Interrupt. Performance information from the users will be available soon :) _ From: Alexander Motin [mailto:[EMAIL PROTECTED] To: Alex Povolotsky [mailto:[EMAIL PROTECTED] Cc: freebsd-net@freebsd.org Sent: Thu, 22 Feb 2007 19:15:45 +0200 Subject: Re: mpd success stories, anyone? Alex Povolotsky wrote: > After disabling windowing and setting net.graph's, mpd4 refuses to work > and no ng interfaces ever created > > lowering both tunables to 128000 solved the problem, will look more. Oops! I have missed kern.ipc.maxsockbuf=1048576 , which is required before those two tunes. But as I have said that options is not required for mpd itself. It's just usefull for 'ngctl list' command. -- Alexander Motin [EMAIL PROTECTED] Optima Telecom ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
what is wrong with ipv6_defaultrouter ?
(FreeBSD 6.2-RELEASE) I have two ipv6 related lines in my /etc/rc.conf: ifconfig_em0_alias0="inet6 XXX::2/48" ipv6_defaultrouter="XXX::1" When I boot like this, I do not get a default ipv6 route in my routing table. 'netstat -rn' shows me a default route for ipv4, but no default route for ipv6. I am forced to manually type in: route add -inet6 default XXX::1 and then everything works and I have a default ipv6 route. My question is, what have I done wrong in rc.conf and how can I get a ipv6 default route at boot time from an rc.conf directive ? Thanks. TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is wrong with ipv6_defaultrouter ?
If memory serves me right, Jason Arnaute wrote: > (FreeBSD 6.2-RELEASE) > > I have two ipv6 related lines in my /etc/rc.conf: > > ifconfig_em0_alias0="inet6 XXX::2/48" > ipv6_defaultrouter="XXX::1" > > When I boot like this, I do not get a default ipv6 > route in my routing table. 'netstat -rn' shows me a > default route for ipv4, but no default route for ipv6. You probably want to replace that first line with: ipv6_ifconfig_em0="XXX::2/48" Also make sure to set ipv6_enable="YES". Bruce. signature.asc Description: OpenPGP digital signature
Re: what is wrong with ipv6_defaultrouter ?
--- "Bruce A. Mah" <[EMAIL PROTECTED]> wrote: > If memory serves me right, Jason Arnaute wrote: > > (FreeBSD 6.2-RELEASE) > > > > I have two ipv6 related lines in my /etc/rc.conf: > > > > ifconfig_em0_alias0="inet6 XXX::2/48" > > ipv6_defaultrouter="XXX::1" > > > > When I boot like this, I do not get a default ipv6 > > route in my routing table. 'netstat -rn' shows me > a > > default route for ipv4, but no default route for > ipv6. > > You probably want to replace that first line with: > > ipv6_ifconfig_em0="XXX::2/48" > > Also make sure to set ipv6_enable="YES". But the ipv6 ifconfig and the ipv6 networking all work fine without either of those changes. I'd prefer not to fix anything that isn't broken ... Are you suggesting that one or both of those changes will cause the ipv6_defaultrouter declaration to suddenly begin working ? Do you use that same ipv6_defaultrouter declaration in your rc.conf ? Thanks. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is wrong with ipv6_defaultrouter ?
If memory serves me right, Jason Arnaute wrote: > --- "Bruce A. Mah" <[EMAIL PROTECTED]> wrote: > >> If memory serves me right, Jason Arnaute wrote: >>> (FreeBSD 6.2-RELEASE) >>> >>> I have two ipv6 related lines in my /etc/rc.conf: >>> >>> ifconfig_em0_alias0="inet6 XXX::2/48" >>> ipv6_defaultrouter="XXX::1" >>> >>> When I boot like this, I do not get a default ipv6 >>> route in my routing table. 'netstat -rn' shows me >> a >>> default route for ipv4, but no default route for >> ipv6. >> >> You probably want to replace that first line with: >> >> ipv6_ifconfig_em0="XXX::2/48" >> >> Also make sure to set ipv6_enable="YES". > > > But the ipv6 ifconfig and the ipv6 networking all work > fine without either of those changes. I'd prefer not > to fix anything that isn't broken ... Not having a default route isn't what I'd call "working fine". :-) ipv6_ifconfig_em0 is the documented, supported mechanism for specifying an IPv6 address for your em0 interface at system startup time. The fact that you were able to do this by specifying an interface alias is a happy accident but it's not supported. > Are you suggesting that one or both of those changes > will cause the ipv6_defaultrouter declaration to > suddenly begin working ? Yes. Note that as of 6.2-RELEASE if you don't set ipv6_enable="YES" you might not get a link-local address on any of your network interfaces. This will cause some problems. (This change was made deliberately in order to avoid assigning IPv6 link-local addresses on systems that weren't explicitly configured to enable IPv6.) > Do you use that same ipv6_defaultrouter declaration > in your rc.conf ? Yes. Please read through the rc.conf(5) manpage...there's an explanation of the various ipv6_* variables there. There should be something on this topic in the FreeBSD Handbook as well. Bruce. signature.asc Description: OpenPGP digital signature
Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge
Roman, good day!
> Lets assume that we have two interfaces that are joined to bridge.
> I'll call them as A and B. Both has a distinct MACs.
>
> Now we have two cases for behaviour of filtering. The first case that
> we will behave like real hub between the physical interfaces and its
> virtual logical representation. The packet will arise on logical interface
> for which it is intended for (according to dst MAC). That is how it
> is implemented now. So now we can filter packets treating dst interface
> as incoming, but not the interfaces it comes through physically.
Yes, I've finally got the idea, thanks!
> The second variant to do visa versa, e q filter packets according interfaces
> they physically come in, and do not take in to account the dst MAC.
>
> Both variant have bad sides and good sides. Both are not wrong from the
> filtering point of view. So I do not want to discuss which one is correct.
I can add only one thing: I am already did the patch to implement
filtering on the physical incoming interface as well as on the logical
one. It is working quite well for the week on a rather busy filtering
bridge that is serving around 60 hosts. The additional behaviour is
controlled by a new sysctl, so it can be easily switched on and off.
> Now about the problem. Lets assume that we also have a C interfaces,
> but with VLANs or anything that will bring the same situation. I'll call
> VLANs C1,C2...CN.
>
> Now we can't implement the first case without a problems, cause all Cx
> will have the same MAC, MAC of the C interface. In current implementation
> we will take the first interface on the list, which would be the last added
> to the bridge. This problem could be fixed. Be patient, I'll describe all
> cases, but not at once. Read till the end of the letter.
>
> If I understand right the Eygene's patch solves problem by introducing the
> second behaviour. It is not quite good cause it will change the old known
> behaviour. Here is the patch itself:
>
> --- if_bridge.c.orig Fri Mar 2 18:23:56 2007
> +++ if_bridge.c Sat Mar 3 05:04:38 2007
> @@ -2122,7 +2122,11 @@
> LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) {
> if (bif2->bif_ifp->if_type == IFT_GIF)
> continue;
> -/* It is destined for us. */
> +/* It is destined for us. We should not rely on the
> + * found interface's MAC as the interface identifier,
> + * because vlanX interfaces are sharing their MAC
> + * with the parent. Moreover, we do know the interface
> + * the packet is coming from. So we're using it. */
> if (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost,
> ETHER_ADDR_LEN) == 0
> #ifdef DEV_CARP
> @@ -2133,7 +2137,7 @@
> if (bif->bif_flags & IFBIF_LEARNING)
> (void) bridge_rtupdate(sc,
> eh->ether_shost, bif, 0, IFBAF_DYNAMIC);
> -m->m_pkthdr.rcvif = bif2->bif_ifp;
> +m->m_pkthdr.rcvif = ifp;
> BRIDGE_UNLOCK(sc);
> return (m);
> }
>
>
> I suggest to fix this problem in the other way, by checking if the physical
> interface is the dst interface by MAC. Eq if we got packet from Ci,
> it will be market as received from Ci, not from Cj. Yes it will add
> double checking for this interface it is not the dst with some
> probability, but will optimize the case the dst is the current
> one cause we will not check the list. This will keep the old behaviour
> eq case 1 and will do the same trick for cases like VLANs.
> Here my variant of the patch:
>
> +/* Give a chance for ifp at first priority. This will help in case we
> + * the packet comes through the interface with VLAN's and the same
> + * MACs on several interfaces in a bridge. Also will save some
> circles
> + * in case dst interface is the physical input interface (eq ifp).
> + */
> +if (ifp->if_type == IFT_GIF
> +&& (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost,
> +ETHER_ADDR_LEN) == 0
> +#ifdef DEV_CARP
> +|| (bif2->bif_ifp->if_carp +&&
> carp_forus(bif2->bif_ifp->if_carp, eh->ether_dhost))
> +#endif
> +)) {
> +if (bif->bif_flags & IFBIF_LEARNING)
> +(void) bridge_rtupdate(sc,
> +eh->ether_shost, bif, 0, IFBAF_DYNAMIC);
> +m->m_pkthdr.rcvif = ifp;
> +BRIDGE_UNLOCK(sc);
> +return (m);
> +}
> LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) {
> if (bif2->bif_ifp->if_type == IFT_GIF)
> continue;
> /* It is destined for us. */
> if (memcmp(IF_LLADDR(bif2->bif_ifp), eh
