ng_ether patch: need testers
Could somebody test out the attached patch on a -current machine?
I don't have one handy.
This patch allows the ng_ether(4) "lower" and "orphans" hooks to
be used simultaneously (see also PR kern/63317).
Thanks,
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Index: share/man/man4/ng_ether.4
===
RCS file: /home/ncvs/src/share/man/man4/ng_ether.4,v
retrieving revision 1.20
diff -u -r1.20 ng_ether.4
--- share/man/man4/ng_ether.4 21 Apr 2004 19:47:33 - 1.20
+++ share/man/man4/ng_ether.4 10 May 2004 14:24:51 -
@@ -97,12 +97,12 @@
hook is equivalent to
.Va lower ,
except that only unrecognized packets (that would otherwise be discarded)
-are written to the hook, and normal incoming traffic is unaffected.
-At most one of
+are written to the hook, while other normal incoming traffic is unaffected.
+Unrecognized packets written to
+.Va upper
+will be forwarded back out to
.Va orphans
-and
-.Va lower
-may be connected at any time.
+if connected.
.Pp
In all cases, frames are raw Ethernet frames with the standard
14 byte Ethernet header (but no checksum).
Index: sys/netgraph/ng_ether.c
===
RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v
retrieving revision 1.33
diff -u -r1.33 ng_ether.c
--- sys/netgraph/ng_ether.c 18 Apr 2004 01:15:32 - 1.33
+++ sys/netgraph/ng_ether.c 10 May 2004 14:24:51 -
@@ -70,8 +70,8 @@
struct private {
struct ifnet *ifp; /* associated interface */
hook_p upper; /* upper hook connection */
- hook_p lower; /* lower OR orphan hook connection */
- u_char lowerOrphan; /* whether lower is lower or orphan */
+ hook_p lower; /* lower hook connection */
+ hook_p orphan; /* orphan hook connection */
u_char autoSrcAddr; /* always overwrite source address */
u_char promisc; /* promiscuous mode enabled */
u_long hwassist; /* hardware checksum capabilities */
@@ -94,7 +94,6 @@
static void ng_ether_detach(struct ifnet *ifp);
/* Other functions */
-static void ng_ether_input2(node_p node, struct mbuf **mp);
static int ng_ether_rcv_lower(node_p node, struct mbuf *m, meta_p meta);
static int ng_ether_rcv_upper(node_p node, struct mbuf *m, meta_p meta);
@@ -201,11 +200,12 @@
{
const node_p node = IFP2NG(ifp);
const priv_p priv = NG_NODE_PRIVATE(node);
+ int error;
/* If "lower" hook not connected, let packet continue */
- if (priv->lower == NULL || priv->lowerOrphan)
+ if (priv->lower == NULL)
return;
- ng_ether_input2(node, mp);
+ NG_SEND_DATA_ONLY(error, priv->lower, *mp); /* sets *mp = NULL */
}
/*
@@ -219,33 +219,14 @@
{
const node_p node = IFP2NG(ifp);
const priv_p priv = NG_NODE_PRIVATE(node);
+ int error;
- /* If "orphan" hook not connected, let packet continue */
- if (priv->lower == NULL || !priv->lowerOrphan) {
+ /* If "orphan" hook not connected, discard packet */
+ if (priv->orphan == NULL) {
m_freem(m);
return;
}
- ng_ether_input2(node, &m);
- if (m != NULL)
- m_freem(m);
-}
-
-/*
- * Handle a packet that has come in on an ethernet interface.
- * The Ethernet header has already been detached from the mbuf,
- * so we have to put it back.
- *
- * NOTE: this function will get called at splimp()
- */
-static void
-ng_ether_input2(node_p node, struct mbuf **mp)
-{
- const priv_p priv = NG_NODE_PRIVATE(node);
- int error;
-
- /* Send out lower/orphan hook */
- NG_SEND_DATA_ONLY(error, priv->lower, *mp);
- *mp = NULL;
+ NG_SEND_DATA_ONLY(error, priv->orphan, m);
}
/*
@@ -352,7 +333,6 @@
ng_ether_newhook(node_p node, hook_p hook, const char *name)
{
const priv_p priv = NG_NODE_PRIVATE(node);
- u_char orphan = priv->lowerOrphan;
hook_p *hookptr;
/* Divert hook is an alias for lower */
@@ -362,13 +342,11 @@
/* Which hook? */
if (strcmp(name, NG_ETHER_HOOK_UPPER) == 0)
hookptr = &priv->upper;
- else if (strcmp(name, NG_ETHER_HOOK_LOWER) == 0) {
- hookptr = &priv->lower;
- orphan = 0;
- } else if (strcmp(name, NG_ETHER_HOOK_ORPHAN) == 0) {
+ else if (strcmp(name, NG_ETHER_HOOK_LOWER) == 0)
hookptr = &priv->lower;
- orphan = 1;
- } else
+ else if (strcmp(name, NG_ETHER_HOOK_ORPHAN) == 0)
+ hookptr = &priv->orphan;
+ else
return (EINVAL);
/* Check if already connected (shouldn't be, but doesn't hurt) */
@@ -381,7 +359,6 @@
/* OK */
*hookptr = hook;
- priv->lowerOrphan = orphan;
return (0);
}
@@ -514,18 +491,18 @@
NGI_GET_M(item, m);
NGI_GET_META(item, meta);
NG_FREE_ITEM(item);
- if (hook == priv->lower)
+ if (hook == priv->lower || hook == priv->orphan)
return ng_ether_rcv_lower(node, m, meta);
if (hook == priv->upper)
return ng_ether_rcv_upper(node, m, meta);
panic("%s: weird hook", __func__);
-#ifdef RESTARTABLE_PANICS /* so we don;t get an error msg in LINT */
+#ifdef RESTARTABLE_PANICS /* so we don't get an error msg in L
ipfw: reset tcp
Hi! When a rule 'reset tcp' matches, a kernel generates new TCP packet. Will it have to go through ipfw list (from the beginning or not)? Eugene Grosbein ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 05:00:47PM +0800, Eugene Grosbein wrote: > Hi! > > When a rule 'reset tcp' matches, a kernel generates new TCP packet. > Will it have to go through ipfw list (from the beginning or not)? ipfw2 uses an mbuf flag to bypass the firewall - I am not sure if i only used it for the keepalives or also for TCP reset packets cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
Luigi Rizzo wrote: > > When a rule 'reset tcp' matches, a kernel generates new TCP packet. > > Will it have to go through ipfw list (from the beginning or not)? > > ipfw2 uses an mbuf flag to bypass the firewall - I am not sure if i > only used it for the keepalives or also for TCP reset packets Please check. I suspect it does not enter ipfw itself, it is not processed by my natd and bad things happen here. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 05:31:46PM +0800, Eugene Grosbein wrote: E> > > When a rule 'reset tcp' matches, a kernel generates new TCP packet. E> > > Will it have to go through ipfw list (from the beginning or not)? E> > E> > ipfw2 uses an mbuf flag to bypass the firewall - I am not sure if i E> > only used it for the keepalives or also for TCP reset packets E> E> Please check. I suspect it does not enter ipfw itself, E> it is not processed by my natd and bad things happen here. According to send_pkt() in ip_fw2.c it does not pass firewall, since M_SKIP_FIREWALL is set. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 05:31:46PM +0800, Eugene Grosbein wrote: > Luigi Rizzo wrote: > > > > When a rule 'reset tcp' matches, a kernel generates new TCP packet. > > > Will it have to go through ipfw list (from the beginning or not)? > > > > ipfw2 uses an mbuf flag to bypass the firewall - I am not sure if i > > only used it for the keepalives or also for TCP reset packets > > Please check. I suspect it does not enter ipfw itself, yes it does skip the firewall, see ip_fw2.c:send_pkt() near the end: ip_rtaddr(ip->ip_dst, &sro); --->m->m_flags |= M_SKIP_FIREWALL; ip_output(m, NULL, &sro, 0, NULL, NULL); removing the M_SKIP_FIREWALL would let ipfw process the packet too. HOWEVER: i think it is a bug in the general case to reprocess internally-generated packet, because you would rely on a correct ipfw configuration to avoid loops (which might not be the case). I have no idea how ipfw1 used to do (and i am not goin to check!) but i don't think the generated packet did reenter the firewall. cheers luigi > it is not processed by my natd and bad things happen here. > > Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
Luigi Rizzo wrote: > > Please check. I suspect it does not enter ipfw itself, > > yes it does skip the firewall, see ip_fw2.c:send_pkt() near the > end: > > ip_rtaddr(ip->ip_dst, &sro); > --->m->m_flags |= M_SKIP_FIREWALL; > ip_output(m, NULL, &sro, 0, NULL, NULL); > > removing the M_SKIP_FIREWALL would let ipfw process the > packet too. HOWEVER: i think it is a bug in the general case > to reprocess internally-generated packet, because you would rely > on a correct ipfw configuration to avoid loops (which might not > be the case). > > I have no idea how ipfw1 used to do (and i am not goin to check!) > but i don't think the generated packet did reenter the firewall. I use ipfw2. Please make it possible (using sysctl or any other mean) to disable M_SKIP_FIREWALL for such packets (I suppose 'unreach' rules are affected too). I DO need to process ALL outgoing packets. For exapmle, I must use 'ipfw fwd' (to implement policy routing) for the packets with source IP like this. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Looking for a Broadcom BCM5704 datasheet
Dear networkers, I'm looking for a Broadcom BCM5704[S] technical datasheet. If anyone has such a beast, or knows how one could obtain it, please let me know. Thanks in advance, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 05:55:05PM +0800, Eugene Grosbein wrote: E> Please make it possible (using sysctl or any other mean) to E> disable M_SKIP_FIREWALL for such packets (I suppose 'unreach' rules E> are affected too). I DO need to process ALL outgoing packets. E> For exapmle, I must use 'ipfw fwd' (to implement policy routing) E> for the packets with source IP like this. Better idea is to separate policy routing decisions from packet filter. However, implementing this is much more difficult, than just removing one string from send_pkt(). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 05:55:05PM +0800, Eugene Grosbein wrote: ... > > removing the M_SKIP_FIREWALL would let ipfw process the > > packet too. HOWEVER: i think it is a bug in the general case > > to reprocess internally-generated packet, because you would rely > > on a correct ipfw configuration to avoid loops (which might not > > be the case). > > > > I have no idea how ipfw1 used to do (and i am not goin to check!) > > but i don't think the generated packet did reenter the firewall. > > I use ipfw2. > > Please make it possible (using sysctl or any other mean) to > disable M_SKIP_FIREWALL for such packets (I suppose 'unreach' rules > are affected too). I DO need to process ALL outgoing packets. > For exapmle, I must use 'ipfw fwd' (to implement policy routing) > for the packets with source IP like this. ok the situation is the following: 1.- unreach rules send packets through send_reject() which in turn calls icmp_error() which in turn goes through the firewall; This is safe because ipfw2 will not generate an ICMP reject in response to an ICMP packets so loops are avoided; 2.- all other firewall-generated TCP packets (rst and keepalives) go through send_pkt() and then bypass the firewall. The only way we could safely go through the firewall again is to make sure that we never send a RST in response to a RST (need to add an additional check in O_REJECT). Give me a few days (i.e. ping me again on monday!) to come up with a safe patch to do this, which does not rely on the programmer to DTRT and avoid loops. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw: reset tcp
On Thu, May 13, 2004 at 06:48:56AM -0700, Luigi Rizzo wrote: > 2.- all other firewall-generated TCP packets (rst and keepalives) > go through send_pkt() and then bypass the firewall. > The only way we could safely go through the firewall again is > to make sure that we never send a RST in response to a RST (need > to add an additional check in O_REJECT). > > Give me a few days (i.e. ping me again on monday!) to come up with > a safe patch to do this, which does not rely on the programmer to > DTRT and avoid loops. Thanks a lot! Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
divert with ipnat instead of ipfw?
Hi all, My setup : -- FreeBSD hostname 4.10-PRERELEASE FreeBSD 4.10-PRERELEASE #2: Wed Apr 28 09:40:43 EST 2004 fxp0 : link to the outside world fxp1 : link to LAN fxp2 : link to DMZ ipf firewall ipnat for LAN and rdr for services. -- I'm running tcpmssd to fix MSS: /usr/local/bin/tcpmssd -p 1000 -i fxp2 and I have the ipfw line that redirects all the traffic from fxp2 into tcpmssd: ipfw add divert 1000 tcp from x.x.x.x/y to any out via fxp0 setup (where x.x.x.x/y is the subnet behind fxp2). This works fine, but I was wondering how to do this with ipnat's rdr configuration line (rather keep ipfw for bwlimiting). I haven't managed to figure out how to redirect ALL traffic from fxp2 to that port. I can do it on a port by part basis, but I need all traffic to go through it. I tried : rdr fxp2 0.0.0.0/0 port 0-65535 -> 127.0.0.1 port 1000 but tcpmssd with -v showed no made. ipfw not used for anything else right now. Any hints? Thanks!! Beto ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ttcp problem
I started a T/TCP connection and started sending packets. Client sent first packet with SYN,data1,PSH,FIN. But server is sending SYN-ACK and igonring the data which is sent because of SYN-flood attack DOS protection. Client had to send the data1 packet again. After this time, server is able to send FIN,data2,ACK at one time. How to have, protection from SYN-flood attack and minimal T/TCP transactions both at the same time. I am using FreeBSD4.9 release with minor modifications. Thanks in advance, Nagaraju. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
