From owner-freebsd-net Sun Aug 26 19:19:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by hub.freebsd.org (Postfix) with ESMTP id AB84D37B401 for ; Sun, 26 Aug 2001 19:19:28 -0700 (PDT) (envelope-from keiichi@iij.ad.jp) Received: by neogw.osaka.iij.ad.jp; id LAA17594; Mon, 27 Aug 2001 11:19:27 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma017562; Mon, 27 Aug 01 11:19:10 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.3/8.11.3) with ESMTP id f7R2ItQ00449; Mon, 27 Aug 2001 11:18:55 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Mon, 27 Aug 2001 11:18:55 +0900 Message-ID: <86itfajldc.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA To: net@freebsd.org Cc: users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B76330E.86A0B689@elischer.org> References: <3B76330E.86A0B689@elischer.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Mon_Aug_27_11:18:55_2001-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Multipart_Mon_Aug_27_11:18:55_2001-1 Content-Type: text/plain; charset=US-ASCII Hi, KAME had removed ipprotosw.h from the KAME source repositry (for FreeBSD4). Though this do not clean up the varargs functions, we still think this is a better (or not worst at least) comprimise in a current situation. Also, I had made a patch for FreeBSD-CURRENT for the same purpose. Please see and review the attached patch. If it looks OK, I will commit it to the CURRENT tree. Thanks, --- Keiichi SHIMA IIJ Research Laboratory / KAME Project ZGlmZiAtdXIgc3lzLm9yaWcvbmV0L2lmX2dpZi5jIHN5cy9uZXQvaWZfZ2lmLmMKLS0tIHN5 --Multipart_Mon_Aug_27_11:18:55_2001-1 Content-Type: text/plain; charset=US-ASCII diff -ur sys.orig/net/if_gif.c sys/net/if_gif.c --- sys.orig/net/if_gif.c Tue Jul 3 06:02:05 2001 +++ sys/net/if_gif.c Mon Aug 27 10:08:28 2001 @@ -62,7 +62,6 @@ #include #include #include -#include #endif /* INET */ #ifdef INET6 @@ -101,7 +100,7 @@ #ifdef INET extern struct domain inetdomain; -struct ipprotosw in_gif_protosw = +struct protosw in_gif_protosw = { SOCK_RAW, &inetdomain, 0/*IPPROTO_IPV[46]*/, PR_ATOMIC|PR_ADDR, in_gif_input, rip_output, 0, rip_ctloutput, 0, diff -ur sys.orig/net/if_stf.c sys/net/if_stf.c --- sys.orig/net/if_stf.c Tue Jul 3 06:02:05 2001 +++ sys/net/if_stf.c Mon Aug 27 10:09:15 2001 @@ -98,7 +98,6 @@ #include #include #include -#include #include #include @@ -134,7 +133,7 @@ static int ip_stf_ttl = 40; extern struct domain inetdomain; -struct ipprotosw in_stf_protosw = +struct protosw in_stf_protosw = { SOCK_RAW, &inetdomain, IPPROTO_IPV6, PR_ATOMIC|PR_ADDR, in_stf_input, rip_output, 0, rip_ctloutput, 0, @@ -550,7 +549,7 @@ va_start(ap, m); off = va_arg(ap, int); - proto = va_arg(ap, int); + proto = mtod(m, struct ip *)->ip_p; va_end(ap); if (proto != IPPROTO_IPV6) { diff -ur sys.orig/netinet/igmp.c sys/netinet/igmp.c --- sys.orig/netinet/igmp.c Sun Jun 24 02:17:58 2001 +++ sys/netinet/igmp.c Mon Aug 27 10:09:40 2001 @@ -148,9 +148,9 @@ } void -igmp_input(m, off, proto) +igmp_input(m, off) register struct mbuf *m; - int off, proto; + int off; { register int iphlen = off; register struct igmp *igmp; diff -ur sys.orig/netinet/igmp_var.h sys/netinet/igmp_var.h --- sys.orig/netinet/igmp_var.h Wed Dec 29 13:40:59 1999 +++ sys/netinet/igmp_var.h Mon Aug 27 10:09:48 2001 @@ -86,7 +86,7 @@ #define IGMP_AGE_THRESHOLD 540 void igmp_init __P((void)); -void igmp_input __P((struct mbuf *, int, int)); +void igmp_input __P((struct mbuf *, int)); void igmp_joingroup __P((struct in_multi *)); void igmp_leavegroup __P((struct in_multi *)); void igmp_fasttimo __P((void)); diff -ur sys.orig/netinet/in_gif.c sys/netinet/in_gif.c --- sys.orig/netinet/in_gif.c Tue Jul 3 06:02:07 2001 +++ sys/netinet/in_gif.c Mon Aug 27 10:12:14 2001 @@ -202,17 +202,18 @@ } void -in_gif_input(m, off, proto) +in_gif_input(m, off) struct mbuf *m; int off; - int proto; { struct ifnet *gifp = NULL; struct ip *ip; int af; u_int8_t otos; + int proto; ip = mtod(m, struct ip *); + proto = ip->ip_p; gifp = (struct ifnet *)encap_getarg(m); diff -ur sys.orig/netinet/in_gif.h sys/netinet/in_gif.h --- sys.orig/netinet/in_gif.h Tue Jul 3 06:02:07 2001 +++ sys/netinet/in_gif.h Mon Aug 27 10:10:53 2001 @@ -37,7 +37,7 @@ extern int ip_gif_ttl; -void in_gif_input __P((struct mbuf *, int off, int proto)); +void in_gif_input __P((struct mbuf *, int off)); int in_gif_output __P((struct ifnet *, int, struct mbuf *, struct rtentry *)); int gif_encapcheck4 __P((const struct mbuf *, int, int, void *)); diff -ur sys.orig/netinet/in_proto.c sys/netinet/in_proto.c --- sys.orig/netinet/in_proto.c Tue Jul 3 06:02:07 2001 +++ sys/netinet/in_proto.c Mon Aug 27 10:13:01 2001 @@ -63,8 +63,6 @@ #include #include -#include - /* * TCP/IP protocol family: IP, ICMP, UDP, TCP. */ @@ -90,7 +88,7 @@ extern struct domain inetdomain; static struct pr_usrreqs nousrreqs; -struct ipprotosw inetsw[] = { +struct protosw inetsw[] = { { 0, &inetdomain, 0, 0, 0, 0, 0, 0, 0, @@ -207,8 +205,8 @@ struct domain inetdomain = { AF_INET, "internet", 0, 0, 0, - (struct protosw *)inetsw, - (struct protosw *)&inetsw[sizeof(inetsw)/sizeof(inetsw[0])], 0, + inetsw, + &inetsw[sizeof(inetsw)/sizeof(inetsw[0])], 0, in_inithead, 32, sizeof(struct sockaddr_in) }; diff -ur sys.orig/netinet/ip_divert.c sys/netinet/ip_divert.c --- sys.orig/netinet/ip_divert.c Fri Jul 27 04:19:48 2001 +++ sys/netinet/ip_divert.c Mon Aug 27 10:13:17 2001 @@ -128,7 +128,7 @@ * with that protocol number to enter the system from the outside. */ void -div_input(struct mbuf *m, int off, int proto) +div_input(struct mbuf *m, int off) { ipstat.ips_noproto++; m_freem(m); diff -ur sys.orig/netinet/ip_encap.c sys/netinet/ip_encap.c --- sys.orig/netinet/ip_encap.c Thu Jul 26 05:15:49 2001 +++ sys/netinet/ip_encap.c Mon Aug 27 10:15:24 2001 @@ -77,7 +77,6 @@ #include #include #include -#include #ifdef INET6 #include @@ -138,17 +137,17 @@ int off, proto; struct ip *ip; struct sockaddr_in s, d; - const struct ipprotosw *psw; + const struct protosw *psw; struct encaptab *ep, *match; va_list ap; int prio, matchprio; va_start(ap, m); off = va_arg(ap, int); - proto = va_arg(ap, int); va_end(ap); ip = mtod(m, struct ip *); + proto = ip->ip_p; bzero(&s, sizeof(s)); s.sin_family = AF_INET; @@ -205,17 +204,23 @@ if (match) { /* found a match, "match" has the best one */ - psw = (const struct ipprotosw *)match->psw; + psw = match->psw; if (psw && psw->pr_input) { encap_fillarg(m, match); - (*psw->pr_input)(m, off, proto); + (*psw->pr_input)(m, off); } else m_freem(m); return; } + /* for backward compatibility - messy... */ + if (proto == IPPROTO_IPV4) { + ipip_input(m, off); + return; + } + /* last resort: inject to raw socket */ - rip_input(m, off, proto); + rip_input(m, off); } #endif diff -ur sys.orig/netinet/ip_icmp.c sys/netinet/ip_icmp.c --- sys.orig/netinet/ip_icmp.c Sun Jun 24 02:17:58 2001 +++ sys/netinet/ip_icmp.c Mon Aug 27 10:15:46 2001 @@ -230,9 +230,9 @@ * Process a received ICMP message. */ void -icmp_input(m, off, proto) +icmp_input(m, off) register struct mbuf *m; - int off, proto; + int off; { int hlen = off; register struct icmp *icp; @@ -576,7 +576,7 @@ } raw: - rip_input(m, off, proto); + rip_input(m, off); return; freeit: diff -ur sys.orig/netinet/ip_icmp.h sys/netinet/ip_icmp.h --- sys.orig/netinet/ip_icmp.h Wed Dec 29 13:41:01 1999 +++ sys/netinet/ip_icmp.h Mon Aug 27 10:15:58 2001 @@ -186,7 +186,7 @@ #ifdef _KERNEL void icmp_error __P((struct mbuf *, int, int, n_long, struct ifnet *)); -void icmp_input __P((struct mbuf *, int, int)); +void icmp_input __P((struct mbuf *, int)); #endif #endif diff -ur sys.orig/netinet/ip_input.c sys/netinet/ip_input.c --- sys.orig/netinet/ip_input.c Sun Jun 24 02:17:58 2001 +++ sys/netinet/ip_input.c Mon Aug 27 10:17:01 2001 @@ -75,8 +75,6 @@ #include #include -#include - #include #include @@ -153,7 +151,7 @@ #endif extern struct domain inetdomain; -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; u_char ip_protox[IPPROTO_MAX]; static int ipqmaxlen = IFQ_MAXLEN; struct in_ifaddrhead in_ifaddrhead; /* first inet address */ @@ -236,17 +234,17 @@ void ip_init() { - register struct ipprotosw *pr; + register struct protosw *pr; register int i; TAILQ_INIT(&in_ifaddrhead); - pr = (struct ipprotosw *)pffindproto(PF_INET, IPPROTO_RAW, SOCK_RAW); + pr = pffindproto(PF_INET, IPPROTO_RAW, SOCK_RAW); if (pr == 0) panic("ip_init"); for (i = 0; i < IPPROTO_MAX; i++) ip_protox[i] = pr - inetsw; - for (pr = (struct ipprotosw *)inetdomain.dom_protosw; - pr < (struct ipprotosw *)inetdomain.dom_protoswNPROTOSW; pr++) + for (pr = inetdomain.dom_protosw; + pr < inetdomain.dom_protoswNPROTOSW; pr++) if (pr->pr_domain->dom_family == PF_INET && pr->pr_protocol && pr->pr_protocol != IPPROTO_RAW) ip_protox[pr->pr_protocol] = pr - inetsw; @@ -819,9 +817,9 @@ */ ipstat.ips_delivered++; { - int off = hlen, nh = ip->ip_p; + int off = hlen; - (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off, nh); + (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off); #ifdef IPFIREWALL_FORWARD ip_fw_fwd_addr = NULL; /* tcp needed it */ #endif diff -ur sys.orig/netinet/ip_mroute.c sys/netinet/ip_mroute.c --- sys.orig/netinet/ip_mroute.c Thu Jul 26 05:15:49 2001 +++ sys/netinet/ip_mroute.c Mon Aug 27 10:18:41 2001 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include @@ -108,10 +107,9 @@ int (*mrt_ioctl)(int, caddr_t) = _mrt_ioctl; void -rsvp_input(m, off, proto) /* XXX must fixup manually */ +rsvp_input(m, off) /* XXX must fixup manually */ struct mbuf *m; int off; - int proto; { /* Can still get packets with rsvp_on = 0 if there is a local member * of the group to which the RSVP packet is addressed. But in this @@ -125,15 +123,15 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); + rip_input(m, off); return; } /* Drop the packet */ m_freem(m); } -void ipip_input(struct mbuf *m, int off, int proto) { /* XXX must fixup manually */ - rip_input(m, off, proto); +void ipip_input(struct mbuf *m, int off) { /* XXX must fixup manually */ + rip_input(m, off); } int (*legal_vif_num)(int) = 0; @@ -708,7 +706,7 @@ * claimed). */ static void -mroute_encap_input(struct mbuf *m, int off, int proto) +mroute_encap_input(struct mbuf *m, int off) { struct ip *ip = mtod(m, struct ip *); int hlen = ip->ip_hl << 2; @@ -732,7 +730,7 @@ } extern struct domain inetdomain; -static struct ipprotosw mroute_encap_protosw = +static struct protosw mroute_encap_protosw = { SOCK_RAW, &inetdomain, IPPROTO_IPV4, PR_ATOMIC|PR_ADDR, mroute_encap_input, 0, 0, rip_ctloutput, 0, @@ -2108,10 +2106,9 @@ } void -rsvp_input(m, off, proto) +rsvp_input(m, off) struct mbuf *m; int off; - int proto; { int vifi; register struct ip *ip = mtod(m, struct ip *); @@ -2156,7 +2153,7 @@ if (ip_rsvpd != NULL) { if (rsvpdebug) printf("rsvp_input: Sending packet up old-style socket\n"); - rip_input(m, off, proto); /* xxx */ + rip_input(m, off); /* xxx */ } else { if (rsvpdebug && vifi == numvifs) printf("rsvp_input: Can't find vif for packet.\n"); diff -ur sys.orig/netinet/ip_var.h sys/netinet/ip_var.h --- sys.orig/netinet/ip_var.h Tue Jun 12 03:41:57 2001 +++ sys/netinet/ip_var.h Mon Aug 27 10:19:12 2001 @@ -177,10 +177,10 @@ int rip_ctloutput __P((struct socket *, struct sockopt *)); void rip_ctlinput __P((int, struct sockaddr *, void *)); void rip_init __P((void)); -void rip_input __P((struct mbuf *, int, int)); +void rip_input __P((struct mbuf *, int)); int rip_output __P((struct mbuf *, struct socket *, u_long)); -void ipip_input __P((struct mbuf *, int, int)); -void rsvp_input __P((struct mbuf *, int, int)); +void ipip_input __P((struct mbuf *, int)); +void rsvp_input __P((struct mbuf *, int)); int ip_rsvp_init __P((struct socket *)); int ip_rsvp_done __P((void)); int ip_rsvp_vif_init __P((struct socket *, struct sockopt *)); @@ -189,7 +189,7 @@ #ifdef IPDIVERT void div_init __P((void)); -void div_input __P((struct mbuf *, int, int)); +void div_input __P((struct mbuf *, int)); void divert_packet __P((struct mbuf *, int, int)); extern struct pr_usrreqs div_usrreqs; extern u_int16_t ip_divert_cookie; diff -ur sys.orig/netinet/raw_ip.c sys/netinet/raw_ip.c --- sys.orig/netinet/raw_ip.c Fri Jul 27 04:19:48 2001 +++ sys/netinet/raw_ip.c Mon Aug 27 10:19:40 2001 @@ -112,14 +112,15 @@ * mbuf chain. */ void -rip_input(m, off, proto) +rip_input(m, off) struct mbuf *m; - int off, proto; + int off; { register struct ip *ip = mtod(m, struct ip *); register struct inpcb *inp; struct inpcb *last = 0; struct mbuf *opts = 0; + int proto = ip->ip_p; ripsrc.sin_addr = ip->ip_src; LIST_FOREACH(inp, &ripcb, inp_list) { diff -ur sys.orig/netinet/tcp_input.c sys/netinet/tcp_input.c --- sys.orig/netinet/tcp_input.c Fri Aug 24 07:34:29 2001 +++ sys/netinet/tcp_input.c Mon Aug 27 10:20:03 2001 @@ -322,15 +322,15 @@ return IPPROTO_DONE; } - tcp_input(m, *offp, proto); + tcp_input(m, *offp); return IPPROTO_DONE; } #endif void -tcp_input(m, off0, proto) +tcp_input(m, off0) register struct mbuf *m; - int off0, proto; + int off0; { register struct tcphdr *th; register struct ip *ip = NULL; diff -ur sys.orig/netinet/tcp_var.h sys/netinet/tcp_var.h --- sys.orig/netinet/tcp_var.h Wed Aug 22 09:58:16 2001 +++ sys/netinet/tcp_var.h Mon Aug 27 10:20:14 2001 @@ -384,7 +384,7 @@ struct rmxp_tao * tcp_gettaocache __P((struct inpcb *)); void tcp_init __P((void)); -void tcp_input __P((struct mbuf *, int, int)); +void tcp_input __P((struct mbuf *, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); void tcp_drop_syn_sent __P((struct inpcb *, int)); diff -ur sys.orig/netinet/udp_usrreq.c sys/netinet/udp_usrreq.c --- sys.orig/netinet/udp_usrreq.c Fri Jul 27 04:19:48 2001 +++ sys/netinet/udp_usrreq.c Mon Aug 27 10:20:31 2001 @@ -149,9 +149,9 @@ } void -udp_input(m, off, proto) +udp_input(m, off) register struct mbuf *m; - int off, proto; + int off; { int iphlen = off; register struct ip *ip; diff -ur sys.orig/netinet/udp_var.h sys/netinet/udp_var.h --- sys.orig/netinet/udp_var.h Sun Feb 18 16:10:03 2001 +++ sys/netinet/udp_var.h Mon Aug 27 10:20:41 2001 @@ -105,7 +105,7 @@ void udp_ctlinput __P((int, struct sockaddr *, void *)); void udp_init __P((void)); -void udp_input __P((struct mbuf *, int, int)); +void udp_input __P((struct mbuf *, int)); void udp_notify __P((struct inpcb *inp, int errno)); int udp_shutdown __P((struct socket *so)); diff -ur sys.orig/netinet6/ah_input.c sys/netinet6/ah_input.c --- sys.orig/netinet6/ah_input.c Mon Jun 11 21:39:04 2001 +++ sys/netinet6/ah_input.c Mon Aug 27 10:21:48 2001 @@ -94,8 +94,7 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void #if __STDC__ @@ -122,7 +121,7 @@ va_start(ap, m); off = va_arg(ap, int); - proto = va_arg(ap, int); + proto = mtod(m, struct ip *)->ip_p; va_end(ap); #ifndef PULLDOWN_TEST @@ -550,7 +549,7 @@ ipsecstat.in_polvio++; goto fail; } - (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); + (*inetsw[ip_protox[nxt]].pr_input)(m, off); } else m_freem(m); m = NULL; diff -ur sys.orig/netinet6/esp_input.c sys/netinet6/esp_input.c --- sys.orig/netinet6/esp_input.c Mon Jun 11 21:39:05 2001 +++ sys/netinet6/esp_input.c Mon Aug 27 10:22:32 2001 @@ -97,8 +97,7 @@ ? sizeof(struct newesp) : sizeof(struct esp)) #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void #if __STDC__ @@ -125,7 +124,7 @@ va_start(ap, m); off = va_arg(ap, int); - proto = va_arg(ap, int); + proto = mtod(m, struct ip *)->ip_p; va_end(ap); /* sanity check for alignment. */ @@ -445,7 +444,7 @@ ipsecstat.in_polvio++; goto bad; } - (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); + (*inetsw[ip_protox[nxt]].pr_input)(m, off); } else m_freem(m); m = NULL; diff -ur sys.orig/netinet6/ipcomp_input.c sys/netinet6/ipcomp_input.c --- sys.orig/netinet6/ipcomp_input.c Mon Jun 11 21:39:06 2001 +++ sys/netinet6/ipcomp_input.c Mon Aug 27 10:23:47 2001 @@ -83,8 +83,7 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void #if __STDC__ @@ -110,7 +109,7 @@ va_start(ap, m); off = va_arg(ap, int); - proto = va_arg(ap, int); + proto = mtod(m, struct ip *)->ip_p; va_end(ap); if (m->m_pkthdr.len < off + sizeof(struct ipcomp)) { @@ -231,7 +230,7 @@ ipsecstat.in_polvio++; goto fail; } - (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); + (*inetsw[ip_protox[nxt]].pr_input)(m, off); } else m_freem(m); m = NULL; --Multipart_Mon_Aug_27_11:18:55_2001-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 20: 4:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 6B89137B40C for ; Sun, 26 Aug 2001 20:04:51 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 73147 invoked by uid 3193); 27 Aug 2001 03:04:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 03:04:50 -0000 Date: Sun, 26 Aug 2001 23:04:50 -0400 (EDT) From: Mike Silbersack X-Sender: To: singh Cc: Dave Zarzycki , Alfred Perlstein , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: <998543289.3b848fba02294@webmail.pdx.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 22 Aug 2001, singh wrote: > I even observed that FreeBSD4.3 adopts to NewReno algorith which is a > suggestion in RFC-2582 (which talks about NewReno, SACK and FACK), for clients > who can not have SACK/FACK, new reno will alleviate the problem of duplicate > acks in Fast Recovery stage and partial ack is a better solution as comapre to > reno algorithm. Ok, I looked over the patch more, as well as the RFCs. Basic SACK support seems straightforward according to the RFCs, but FACK is a bit more complex. From what I can tell, FACK isn't a tcp feature as much as a retransmission scheme. This scheme, in turn, has been updated and is now called "rate halving". Is the FACK implementation in this patch the old version, or the rate-halving version? Also, does FACK spill over into non-SACKed connections? I couldn't tell from a quick readthrough. I've also noticed that while SACK is sysctl disableable, FACK is not. A sysctl for FACK should be added as well so that we can enable/disable it at will (as can be done with newreno.) Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 20:21:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id B24C537B40C for ; Sun, 26 Aug 2001 20:21:35 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 74277 invoked by uid 3193); 27 Aug 2001 03:21:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 03:21:34 -0000 Date: Sun, 26 Aug 2001 23:21:34 -0400 (EDT) From: Mike Silbersack X-Sender: To: singh Cc: Dave Zarzycki , Alfred Perlstein , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 26 Aug 2001, Mike Silbersack wrote: > I've also noticed that while SACK is sysctl disableable, FACK is not. A > sysctl for FACK should be added as well so that we can enable/disable it > at will (as can be done with newreno.) > > Thanks, > > Mike "Silby" Silbersack To answer my previous question and pose another: FACK is SACK specific, Rate Halving works along with both SACK and non-SACK connections. So, what I wonder is this: Should we be importing SACK and FACK at the same time, or should we import just basic SACK support for now and worry about retransmission algorithms at a later date? I pose this question because SACK seems "safe" in my opinion; it should only be able to make performance better, and will be fairly easy to verify in that aspect. Retransmission algorithms require more study, and could cause new performance problems if not implemented perfectly. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 20:32: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 25ADD37B405 for ; Sun, 26 Aug 2001 20:31:55 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 69ACA66DE9; Sun, 26 Aug 2001 20:31:54 -0700 (PDT) Date: Sun, 26 Aug 2001 20:31:54 -0700 From: Kris Kennaway To: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" Cc: freebsd-net@FreeBSD.org Subject: Re: Reg. mbuf structure Message-ID: <20010826203153.A34063@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from EXT-Ramamoorthy.Ramasubramanian@nokia.com on Sun, Aug 26, 2001 at 05:59:22PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 26, 2001 at 05:59:22PM -0500, Ramasubramanian Ramamoorthy (EXT-= NRC/Boston) wrote: > Hi, > I am trying to extract same data from the skbuff structure and mbuf > structure for a checksum calculation. Can you tell me how we can can > confirm that we are extracting the same data from both these structures? >=20 > Thanks, > Ramamoorthy. R. >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message This question would be better asked on the freebsd-net mailing list where I've forwarded it. Kris --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7ib8pWry0BWjoQKURAoEaAJ9jaZeJetP+PqT8GkMYgCECx82vgwCfS1XI MvnNiIq2KamaqTkmoi01qXM= =D6sP -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 21:22:19 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 0648737B405; Sun, 26 Aug 2001 21:22:18 -0700 (PDT) To: silby@silby.com Subject: Re: RFC: SACK/FACK patch port to Current Cc: freebsd-net@FreeBSD.ORG In-Reply-To: Message-Id: <20010827042218.0648737B405@hub.freebsd.org> Date: Sun, 26 Aug 2001 21:22:18 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Rate-halving is implemented in the PSC version of SACK. Perhaps we should take a look at that? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 21:59: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 225BB37B409 for ; Sun, 26 Aug 2001 21:59:01 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA71453; Sun, 26 Aug 2001 22:05:36 -0700 (PDT) Message-ID: <3B89D023.8E3762D8@elischer.org> Date: Sun, 26 Aug 2001 21:44:19 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Keiichi SHIMA Cc: net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup References: <3B76330E.86A0B689@elischer.org> <86itfajldc.wl@keiichi01.osaka.iij.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Keiichi SHIMA wrote: > > Hi, > > KAME had removed ipprotosw.h from the KAME source repositry (for > FreeBSD4). Though this do not clean up the varargs functions, we > still think this is a better (or not worst at least) comprimise in a > current situation. > > Also, I had made a patch for FreeBSD-CURRENT for the same purpose. > Please see and review the attached patch. If it looks OK, I will > commit it to the CURRENT tree. > These patches seem ok, but I need to ask if this is the way to go.. The removal of the extra argument in the input routines is one way of doing the work (and the use of mtod(m, struct ip)->ip_p instead). The other would be to propose that the inclusion of a protocol identifier is a generically useful thing in a world where tunnellling is becoming more and more common, and to upgrade the standard protosw to include this extra argument in the standard input definition. Before we go this way, are you certain that it is architecturally cleaner to remove the extra arg on these, than to add it to all the other cases..? I'm not worried about whether it exists or not, just that is the same everywhere. as for: in_stf_input(m, va_alist) Why does it need to be varargs? The code specifies (using varargs) that the next argument is an int called "offset" and the correct argument for the standard protocol switch entry is an int called "offset" so why not just declare it as int offset;? why complicate the code with a va_alist? Which OS's have a va_alist? which have "int offset; ?" The only effect I see is to produce a warning message. (which hides real warning messages) I have still not heard any reason for the varargs here.. except "it's needed for portability".. portability with WHO? BSD4.4 certainly didn't have varargs there.... -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 22:19: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id E4BAF37B407 for ; Sun, 26 Aug 2001 22:18:57 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA71507; Sun, 26 Aug 2001 22:25:19 -0700 (PDT) Message-ID: <3B89D4C1.44AF91C9@elischer.org> Date: Sun, 26 Aug 2001 22:04:01 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Ramasubramanian Ramamoorthy (EXT-NRC/Boston)" Cc: freebsd-net@FreeBSD.org Subject: Re: Reg. mbuf structure References: <20010826203153.A34063@xor.obsecurity.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Sun, Aug 26, 2001 at 05:59:22PM -0500, Ramasubramanian Ramamoorthy (EXT-NRC/Boston) wrote: > > Hi, > > I am trying to extract same data from the skbuff structure and mbuf > > structure for a checksum calculation. Can you tell me how we can can > > confirm that we are extracting the same data from both these structures? > > > > Thanks, > > Ramamoorthy. R. > > > Well, you need to tell us what information you wish to extract.... -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 26 23:39: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 62E6437B405 for ; Sun, 26 Aug 2001 23:39:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA71828; Sun, 26 Aug 2001 23:58:12 -0700 (PDT) Message-ID: <3B89EA84.62FA4422@elischer.org> Date: Sun, 26 Aug 2001 23:36:52 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jun-ichiro itojun Hagino Cc: Keiichi SHIMA , net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup References: <20010827061439.E4ED97C1@starfruit.itojun.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jun-ichiro itojun Hagino wrote: > > >I have still not heard any reason for the varargs here.. > >except "it's needed for portability".. > >portability with WHO? > > portability with other *BSD projects (NetBSD, OpenBSD, BSD/OS, MacOSX > maybe). are you suggesting that BSD/OS and MacOS/X have varargs? Varargs are inherrently incompatible with switch tables unless there is a format key (e.g. as in printf()) (I think NetBSD must have been crazy when they did it) > > >BSD4.4 certainly didn't have varargs there.... > > 4.4BSD did not have prototype in protosw.h, there's no varargs either. > freebsd added prototype on its own, and thus change/broke some of the > existing xx{in,out}put prototypes. netbsd/openbsd added varargs, to > keep existing practices in 4.4BSD. they were too lazy to fix the problems. I agree that we should fix protosw if it is deficient, but not with varargs.! > see it for yourself. > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/protosw.h > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/protosw.h > http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/protosw.h so what's wrong with adding a #ifdef USE_VARARGS xxx_input(struct mbuf *m, va_alist) #else xxx_input(struct mbuf *m, int offset) #endif at least we'd get rid of the d*mned warning messages! Are you not aware that most of the warning messages for a normal kernel compile come from the KAME code? I am on compile number 157 for the KSE code. (in 3 weeks) I must look at those messages EVERY compile to check that they are not hiding a real problem there when I change things. It is damaging to your reputation, and it certainly hurts my professional reputation to have people say "yes but FreeBSD kernel has lived for over a year with the same warning messages in a simple kernel compile". I HAVE had people say something like this to me. (The second worst module is acpi from intel) > itojun -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 0:28:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from femail41.sdc1.sfba.home.com (femail41.sdc1.sfba.home.com [24.254.60.35]) by hub.freebsd.org (Postfix) with ESMTP id 4868F37B406 for ; Mon, 27 Aug 2001 00:28:08 -0700 (PDT) (envelope-from justin@mac.com) Received: from grinch ([65.11.111.111]) by femail41.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010827072807.UVLM3082.femail41.sdc1.sfba.home.com@grinch>; Mon, 27 Aug 2001 00:28:07 -0700 Date: Mon, 27 Aug 2001 00:28:06 -0700 From: Justin C.Walker Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: IPV6/KAME/protosw integration cleanup Cc: users@ipv6.org, core@kame.net To: net@freebsd.org X-Mailer: Apple Mail (2.388) In-Reply-To: <3B89EA84.62FA4422@elischer.org> Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Message-Id: <20010827072807.UVLM3082.femail41.sdc1.sfba.home.com@grinch> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org FWIW, sadly, Mac OS X does flirt with varargs. These seem to have crept in via the Mach back door. I don't believe that they are actually used anywhere, but the varargs headers are there. Our version of the KAME stack must have pre-dated the intro of this, because the 'bsd' side of the code is varargs-free (so far, at any rate). Regards, Justin On Sunday, August 26, 2001, at 11:36 PM, Julian Elischer wrote: > Jun-ichiro itojun Hagino wrote: >> >>> I have still not heard any reason for the varargs here.. >>> except "it's needed for portability".. >>> portability with WHO? >> >> portability with other *BSD projects (NetBSD, OpenBSD, >> BSD/OS, MacOSX >> maybe). > > are you suggesting that BSD/OS and MacOS/X have varargs? > Varargs are inherrently incompatible with switch tables > unless there is a format key (e.g. as in printf()) > (I think NetBSD must have been crazy when they did it) > >> >>> BSD4.4 certainly didn't have varargs there.... >> >> 4.4BSD did not have prototype in protosw.h, there's no >> varargs either. >> freebsd added prototype on its own, and thus change/broke >> some of the >> existing xx{in,out}put prototypes. netbsd/openbsd added >> varargs, to >> keep existing practices in 4.4BSD. > > they were too lazy to fix the problems. > > I agree that we should fix protosw if it is deficient, but not > with varargs.! > >> see it for yourself. > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/protosw.h >> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/protosw.h >> http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/protosw.h > > > > so what's wrong with adding a > > #ifdef USE_VARARGS > xxx_input(struct mbuf *m, va_alist) > #else > xxx_input(struct mbuf *m, int offset) > #endif > > at least we'd get rid of the d*mned warning messages! > Are you not aware that most of the warning messages for a normal > kernel compile come from the KAME code? I am on compile number 157 > for the KSE code. (in 3 weeks) > > I must look at those messages EVERY compile to check that they are > not hiding a > real > problem there when I change things. > > It is damaging to your reputation, and it certainly hurts my > professional > reputation to have people say "yes but FreeBSD kernel has lived for > over a year with the same warning messages in a simple kernel compile". > I HAVE had people say something like this to me. > > (The second worst module is acpi from intel) > > >> itojun > > -- > +------------------------------------+ ______ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at > work in > | / \ julian@elischer.org +------>x USA \ a very > strange > | ( OZ ) \___ ___ | country ! > +- X_.---._/ presently in San Francisco \_/ \\ > v > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology | When LuteFisk is outlawed Nexsi Systems Corp. | Only outlaws will have 1959 Concourse Drive | LuteFisk San Jose, CA 95131 | *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 5: 2:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from star.rila.bg (star.rila.bg [212.39.75.32]) by hub.freebsd.org (Postfix) with ESMTP id EA84B37B405 for ; Mon, 27 Aug 2001 05:02:13 -0700 (PDT) (envelope-from vlady@star.rila.bg) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.11.4/8.11.4) with ESMTP id f7RC2xc26296 for ; Mon, 27 Aug 2001 15:03:01 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200108271203.f7RC2xc26296@star.rila.bg> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.3 To: freebsd-net@FreeBSD.ORG From: "Vladimir Terziev" Subject: Cisco AIR-PCI 352 card strange behaviour Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2001 15:02:59 +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a dual-boot machine with Cisco AIR-PCI 352 card on it. The machine boots FreeBSD 4.3-STABLE and Windows'98. The AIR-PCI 352 card works either with FreeBSD and Win98, but it has different behaviour under both. When it works under Win98, ping to my gateway machine is ~ 6ms. When it works under FreeBSD, ping is ~ 200ms. That is very strange for me and I want to know what is the reason for this behaviour and how I can drop the ping under FreeBSD to be similar to ping under Win98? Any suggestions? Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 5: 7:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by hub.freebsd.org (Postfix) with ESMTP id F0E7137B406 for ; Mon, 27 Aug 2001 05:07:19 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E4ED97C1; Mon, 27 Aug 2001 15:14:38 +0900 (JST) To: Julian Elischer Cc: Keiichi SHIMA , net@freebsd.org, users@ipv6.org, core@kame.net In-reply-to: julian's message of Sun, 26 Aug 2001 21:44:19 MST. <3B89D023.8E3762D8@elischer.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPV6/KAME/protosw integration cleanup From: Jun-ichiro itojun Hagino Date: Mon, 27 Aug 2001 15:14:38 +0900 Message-Id: <20010827061439.E4ED97C1@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I have still not heard any reason for the varargs here.. >except "it's needed for portability".. >portability with WHO? portability with other *BSD projects (NetBSD, OpenBSD, BSD/OS, MacOSX maybe). >BSD4.4 certainly didn't have varargs there.... 4.4BSD did not have prototype in protosw.h, there's no varargs either. freebsd added prototype on its own, and thus change/broke some of the existing xx{in,out}put prototypes. netbsd/openbsd added varargs, to keep existing practices in 4.4BSD. see it for yourself. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/protosw.h http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/protosw.h http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/protosw.h itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 5:35:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 65F6637B407 for ; Mon, 27 Aug 2001 05:35:30 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ED0084B20; Mon, 27 Aug 2001 21:35:28 +0900 (JST) To: Julian Elischer Cc: Keiichi SHIMA , net@freebsd.org, users@ipv6.org, core@kame.net In-reply-to: julian's message of Sun, 26 Aug 2001 23:36:52 MST. <3B89EA84.62FA4422@elischer.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPV6/KAME/protosw integration cleanup From: itojun@iijlab.net Date: Mon, 27 Aug 2001 21:35:28 +0900 Message-ID: <28752.998915728@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >at least we'd get rid of the d*mned warning messages! >Are you not aware that most of the warning messages for a normal >kernel compile come from the KAME code? I am on compile number 157 >for the KSE code. (in 3 weeks) though i have no freebsd-current box, i disagree. there are a lot of other warnings i see from kernel compilation. why don't you attack other folks as well. itojun PS: i have unsubscribed from the list. i can't take this stress any more. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 6: 9:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 7B21F37B403 for ; Mon, 27 Aug 2001 06:09:24 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 9D14A5D9F; Mon, 27 Aug 2001 15:09:23 +0200 (CEST) Date: Mon, 27 Aug 2001 15:09:23 +0200 From: Jesper Skriver To: Scott Renfro Cc: Barney Wolff , freebsd-net@FreeBSD.ORG, Jonathan Lemon , Bill Fenner , Cory Scott , Mike Silbersack Subject: Re: Proposed change to icmp_may_rst induced ENETRESET Message-ID: <20010827150923.L55723@skriver.dk> References: <20010822020504.C24160@bonsai.home.renfro.org> <20010823165326.A24963@tp.databus.com> <20010823182331.A38019@bonsai.home.renfro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010823182331.A38019@bonsai.home.renfro.org>; from scott@renfro.org on Thu, Aug 23, 2001 at 06:23:31PM -0700 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 23, 2001 at 06:23:31PM -0700, Scott Renfro wrote: > On Thu, Aug 23, 2001 at 04:53:26PM -0400, Barney Wolff wrote: > > > > As another heavy nmap user, I'd vote just the other way. It's useful > > to differentiate between a reset coming back from the destination host > > and an unreachable from a firewall/router-acl. Ordinary apps probably > > don't care all that much about why a connection could not be > > established, and just report the error to the user. > > I suspect that most (good) applications use strerror(3) to map errors > into messages for the user. Today, users get "Network dropped > connection on reset"; with the patch they'd get "Connection refused". > I think the latter is preferred under POLA, especially when the former > is not a documented response to connect(2). > > You have a valid point that icmp_may_rst changes nmap's behavior, even > with the proposed patch. If you want nmap's historic behavior (admin > prohib ==> filtered), then turning off icmp_may_rst works. With > icmp_may_rst turned on and the patch commited, you get the other > behavior (admin prohib ==> closed). Without the patch, nmap spews > errors and would need a FreeBSD-specific change. I pretty much doesn't care, Jonathan, Bill, Mike what do you think ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 6:32:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from keiichi01.osaka.iij.ad.jp (c193223.ap.plala.or.jp [210.150.193.223]) by hub.freebsd.org (Postfix) with ESMTP id 757CE37B401 for ; Mon, 27 Aug 2001 06:32:49 -0700 (PDT) (envelope-from keiichi@iij.ad.jp) Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.3/8.11.3) with ESMTP id f7RDVEk02527; Mon, 27 Aug 2001 22:31:31 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Mon, 27 Aug 2001 22:31:14 +0900 Message-ID: <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA To: Julian Elischer Cc: itojun@iijlab.net, net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <28752.998915728@itojun.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We are planning to fill your (and many freebsd hackers') requirements. These plans include introducing some #ifdef clause to match freebsd's prototypes if there is no other way to live with freebsd in peace, though it increases our maintanance cost. (on the contrary, not introducing #ifdef clause increases the maintance cost of your KSE work. the dilemma.) We will decide how should we do in a week. --- Keiichi SHIMA IIJ Research Laboratory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 6:47:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by hub.freebsd.org (Postfix) with ESMTP id 99E6737B403 for ; Mon, 27 Aug 2001 06:47:39 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 942A47BA; Mon, 27 Aug 2001 22:47:34 +0900 (JST) To: Keiichi SHIMA Cc: Julian Elischer , net@freebsd.org, users@ipv6.org, core@kame.net In-reply-to: keiichi's message of Mon, 27 Aug 2001 22:31:14 +0900. <86heutd3z1.wl@keiichi01.osaka.iij.ad.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPV6/KAME/protosw integration cleanup From: Jun-ichiro itojun Hagino Date: Mon, 27 Aug 2001 22:47:34 +0900 Message-Id: <20010827134734.942A47BA@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >We are planning to fill your (and many freebsd hackers') requirements. just a nitpicking. - i don't think julian is in the position to set the requirement for freebsd. is he? - i have never heard from other people about (against) the use of varargs, therefore, it is misleading to say "many freebsd hackers". itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 7:28: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from keiichi01.osaka.iij.ad.jp (c193223.ap.plala.or.jp [210.150.193.223]) by hub.freebsd.org (Postfix) with ESMTP id F34BF37B407 for ; Mon, 27 Aug 2001 07:27:58 -0700 (PDT) (envelope-from keiichi@iij.ad.jp) Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.3/8.11.3) with ESMTP id f7RERbk02588; Mon, 27 Aug 2001 23:27:38 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Mon, 27 Aug 2001 23:27:37 +0900 Message-ID: <86g0add1d2.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA To: Jun-ichiro itojun Hagino Cc: Julian Elischer , net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <20010827134734.942A47BA@starfruit.itojun.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. References: <20010827134734.942A47BA@starfruit.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Jun-ichiro itojun Hagino wrote: > > >We are planning to fill your (and many freebsd hackers') requirements. > > - i have never heard from other people about (against) the use of > varargs, therefore, it is misleading to say "many freebsd hackers". Right. Sorry if other freebsd guys felt unconfortable. I might be tired to continue this discussion that seems no goal... --- Keiichi SHIMA IIJ Research Laboratory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 8:18:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id CAA8437B405 for ; Mon, 27 Aug 2001 08:18:10 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f7RFI4R21443; Mon, 27 Aug 2001 08:18:05 -0700 (PDT) Message-Id: <200108271518.f7RFI4R21443@ptavv.es.net> To: "Vladimir Terziev" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Cisco AIR-PCI 352 card strange behaviour In-reply-to: Your message of "Mon, 27 Aug 2001 15:02:59 +0300." <200108271203.f7RC2xc26296@star.rila.bg> Date: Mon, 27 Aug 2001 08:18:04 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: "Vladimir Terziev" > Date: Mon, 27 Aug 2001 15:02:59 +0300 > Sender: owner-freebsd-net@FreeBSD.ORG > > > Hi, > > I have a dual-boot machine with Cisco AIR-PCI 352 card on it. The machine > boots FreeBSD 4.3-STABLE and Windows'98. > > The AIR-PCI 352 card works either with FreeBSD and Win98, but it has > different behaviour under both. > When it works under Win98, ping to my gateway machine is ~ 6ms. When it > works under FreeBSD, ping is ~ 200ms. That is very strange for me and I want > to know what is the reason for this behaviour and how I can drop the ping > under FreeBSD to be similar to ping under Win98? Probably better to post this sort of thing to mobile or hardware, but I'll take a shot at it. Is it possible that you have power management enabled? For a Orinoco or Prism ][ based card, this will cause a significant delay in the start of transmission as the transmitter is powered on. 200 ms. is a bit long. For the wi driver, the default is 100 ms. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 8:44:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 662BB37B425 for ; Mon, 27 Aug 2001 08:44:36 -0700 (PDT) (envelope-from jkh@freebsd.org) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id f7RFiGw22130; Mon, 27 Aug 2001 08:44:16 -0700 (PDT) (envelope-from jkh@freebsd.org) To: itojun@iijlab.net Cc: julian@elischer.org, keiichi@iij.ad.jp, net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <28752.998915728@itojun.org> References: <3B89EA84.62FA4422@elischer.org> <28752.998915728@itojun.org> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010827084416R.jkh@freebsd.org> Date: Mon, 27 Aug 2001 08:44:16 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian, Can you *please* make some attempt to pick your battles more wisely and stop needlessly antagonizing the KAME folks? I'm sure you have some areas of technical skill, but diplomacy is certainly not something you excel at (in fact, you completely suck at it, let's be honest) so perhaps you should either elect to stay OUT of these discussions or confine the amount of time you spend "in public" to only those occasions where something truly meritorious is being debated. Going into a froth over warning messages does not constitute such an occasion and you should get someone else more capable in the art of communication to proxy these discussions for you if you're really keen to get involved in both the large scale and small scale issues. Thanks, - Jordan From: itojun@iijlab.net Subject: Re: IPV6/KAME/protosw integration cleanup Date: Mon, 27 Aug 2001 21:35:28 +0900 > >at least we'd get rid of the d*mned warning messages! > >Are you not aware that most of the warning messages for a normal > >kernel compile come from the KAME code? I am on compile number 157 > >for the KSE code. (in 3 weeks) > > though i have no freebsd-current box, i disagree. there are a lot of > other warnings i see from kernel compilation. why don't you attack > other folks as well. > > itojun > PS: i have unsubscribed from the list. i can't take this stress any more. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:32:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id E3C8537B403 for ; Mon, 27 Aug 2001 13:32:18 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 65ADF66DE9; Mon, 27 Aug 2001 13:32:18 -0700 (PDT) Date: Mon, 27 Aug 2001 13:32:18 -0700 From: Kris Kennaway To: "S.V. Ganesh" Cc: freebsd-net@FreeBSD.ORG Subject: Fwd: TCP PCB size Message-ID: <20010827133218.B43851@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ganesh@serve2net.com on Mon, Aug 27, 2001 at 11:51:30AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've forwarded this message to the freebsd-net mailing list where it's more on-topic for discussion. Kris On Mon, Aug 27, 2001 at 11:51:30AM -0700, S.V. Ganesh wrote: > What is the size of the IPCB(struct inpcb) and TPCB(struct tcpcb) structu= re? > (ignoring platform specific alignment issues) >=20 > Stevens v2 has 84(inpcb) and 140(tcpcb) bytes. >=20 > Thanks, > -svg >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7iq5RWry0BWjoQKURAjCMAJ4t1RWPCtX47hGOFWmQitJj+FbdMgCgmNKY QJj11LSWryXxj1mCnWM/iGM= =pQrF -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:33:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 6640037B403 for ; Mon, 27 Aug 2001 13:33:45 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 2E0E981D01; Mon, 27 Aug 2001 15:33:45 -0500 (CDT) Date: Mon, 27 Aug 2001 15:33:45 -0500 From: Bill Fumerola To: Kris Kennaway Cc: "S.V. Ganesh" , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: TCP PCB size Message-ID: <20010827153345.Q2759@elvis.mu.org> References: <20010827133218.B43851@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827133218.B43851@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Aug 27, 2001 at 01:32:18PM -0700 X-Operating-System: FreeBSD 4.3-FEARSOME-20010712 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 27, 2001 at 01:32:18PM -0700, Kris Kennaway wrote: > I've forwarded this message to the freebsd-net mailing list where it's > more on-topic for discussion. > > Kris > > On Mon, Aug 27, 2001 at 11:51:30AM -0700, S.V. Ganesh wrote: > > What is the size of the IPCB(struct inpcb) and TPCB(struct tcpcb) structure? > > (ignoring platform specific alignment issues) > > > > Stevens v2 has 84(inpcb) and 140(tcpcb) bytes. its more on topic for a C beginners mailing list. whats so hard about including the header file and using sizeof()? -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:34:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 33D4637B407 for ; Mon, 27 Aug 2001 13:34:19 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2752881D01; Mon, 27 Aug 2001 15:34:19 -0500 (CDT) Date: Mon, 27 Aug 2001 15:34:19 -0500 From: Alfred Perlstein To: Kris Kennaway Cc: "S.V. Ganesh" , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: TCP PCB size Message-ID: <20010827153419.I81307@elvis.mu.org> References: <20010827133218.B43851@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827133218.B43851@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Aug 27, 2001 at 01:32:18PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Kris Kennaway [010827 15:32] wrote: > I've forwarded this message to the freebsd-net mailing list where it's > more on-topic for discussion. > > Kris > > On Mon, Aug 27, 2001 at 11:51:30AM -0700, S.V. Ganesh wrote: > > What is the size of the IPCB(struct inpcb) and TPCB(struct tcpcb) structure? > > (ignoring platform specific alignment issues) > > > > Stevens v2 has 84(inpcb) and 140(tcpcb) bytes. > > > > Thanks, > > -svg Wouldn't it be trivial for you to just put a SYSINIT/SYSCTL in the netinet code to find out? -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:35: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id AA2E337B403 for ; Mon, 27 Aug 2001 13:35:03 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 9C9EA81D01; Mon, 27 Aug 2001 15:35:03 -0500 (CDT) Date: Mon, 27 Aug 2001 15:35:03 -0500 From: Alfred Perlstein To: Bill Fumerola Cc: Kris Kennaway , "S.V. Ganesh" , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: TCP PCB size Message-ID: <20010827153503.J81307@elvis.mu.org> References: <20010827133218.B43851@xor.obsecurity.org> <20010827153345.Q2759@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827153345.Q2759@elvis.mu.org>; from billf@mu.org on Mon, Aug 27, 2001 at 03:33:45PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bill Fumerola [010827 15:33] wrote: > On Mon, Aug 27, 2001 at 01:32:18PM -0700, Kris Kennaway wrote: > > I've forwarded this message to the freebsd-net mailing list where it's > > more on-topic for discussion. > > > > Kris > > > > On Mon, Aug 27, 2001 at 11:51:30AM -0700, S.V. Ganesh wrote: > > > What is the size of the IPCB(struct inpcb) and TPCB(struct tcpcb) structure? > > > (ignoring platform specific alignment issues) > > > > > > Stevens v2 has 84(inpcb) and 140(tcpcb) bytes. > > its more on topic for a C beginners mailing list. whats so hard about > including the header file and using sizeof()? It's actually a bit more difficult than that because you need to include a bunch of kernel headers (as well as defining _KERNEL) to get at it from userland. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:54:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 0083637B407 for ; Mon, 27 Aug 2001 13:54:36 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 98298 invoked by uid 3193); 27 Aug 2001 20:54:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 20:54:31 -0000 Date: Mon, 27 Aug 2001 16:54:31 -0400 (EDT) From: Mike Silbersack X-Sender: To: Jesper Skriver Cc: Scott Renfro , Barney Wolff , , Jonathan Lemon , Bill Fenner , Cory Scott Subject: Re: Proposed change to icmp_may_rst induced ENETRESET In-Reply-To: <20010827150923.L55723@skriver.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 27 Aug 2001, Jesper Skriver wrote: > On Thu, Aug 23, 2001 at 06:23:31PM -0700, Scott Renfro wrote: > > You have a valid point that icmp_may_rst changes nmap's behavior, even > > with the proposed patch. If you want nmap's historic behavior (admin > > prohib ==> filtered), then turning off icmp_may_rst works. With > > icmp_may_rst turned on and the patch commited, you get the other > > behavior (admin prohib ==> closed). Without the patch, nmap spews > > errors and would need a FreeBSD-specific change. > > I pretty much doesn't care, Jonathan, Bill, Mike what do you think ? > > /Jesper Seems best to have icmp admin-prohibited return what a RST would, just to be compatible with the widest range of apps, IMHO. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 13:57:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 4750C37B407 for ; Mon, 27 Aug 2001 13:57:32 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 98596 invoked by uid 3193); 27 Aug 2001 20:57:31 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 20:57:31 -0000 Date: Mon, 27 Aug 2001 16:57:31 -0400 (EDT) From: Mike Silbersack X-Sender: To: Alfred Perlstein Cc: Bill Fumerola , Kris Kennaway , "S.V. Ganesh" , Subject: Re: Fwd: TCP PCB size In-Reply-To: <20010827153503.J81307@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 27 Aug 2001, Alfred Perlstein wrote: > It's actually a bit more difficult than that because you need to > include a bunch of kernel headers (as well as defining _KERNEL) > to get at it from userland. The easy way to do this is to copy the top of one of the files from netstat, which already has all the includes included and in the proper order. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 14: 7:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id E79E337B401 for ; Mon, 27 Aug 2001 14:07:44 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 442 invoked by uid 3193); 27 Aug 2001 21:07:43 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 21:07:43 -0000 Date: Mon, 27 Aug 2001 17:07:43 -0400 (EDT) From: Mike Silbersack X-Sender: To: Jeffrey Hsu Cc: Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: <20010827042218.0648737B405@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 26 Aug 2001, Jeffrey Hsu wrote: > Rate-halving is implemented in the PSC version of SACK. Perhaps > we should take a look at that? Makes sense, if we want Rate-halving. All the papers evaluating it have sounded good, and it probably is good to incorporate. My only concern is whether it will be controversial to merge, which is why I think I'd like basic SACK + newreno first, then Rate-halving + FACK later. Of course, that does emply that taking the SACK bits from the PSC implementation might be best then. I'll look more into this. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 14:10:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by hub.freebsd.org (Postfix) with ESMTP id 6B12D37B408 for ; Mon, 27 Aug 2001 14:10:43 -0700 (PDT) (envelope-from ganesh@serve2net.com) Received: from suganesh (adsl-63-201-33-105.dsl.snfc21.pacbell.net [63.201.33.105]) by cleitus.hosting.pacbell.net id RAA17562; Mon, 27 Aug 2001 17:10:19 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "S.V. Ganesh" To: "Bill Fumerola" , "Kris Kennaway" Cc: Subject: RE: Fwd: TCP PCB size Date: Mon, 27 Aug 2001 14:17:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20010827153345.Q2759@elvis.mu.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As of now, do not have access to an environment to do the task. BTW, always better to say "I do not know" or choose not answer. As a child, all you have are questions. One grows up, goes to Stanford paying a lot of money, and stops asking questions for the fear of being perceived "stupid". Thanks, -svg -----Original Message----- From: Bill Fumerola [mailto:billf@mu.org] Sent: Monday, August 27, 2001 1:34 PM To: Kris Kennaway Cc: S.V. Ganesh; freebsd-net@FreeBSD.ORG Subject: Re: Fwd: TCP PCB size On Mon, Aug 27, 2001 at 01:32:18PM -0700, Kris Kennaway wrote: > I've forwarded this message to the freebsd-net mailing list where it's > more on-topic for discussion. > > Kris > > On Mon, Aug 27, 2001 at 11:51:30AM -0700, S.V. Ganesh wrote: > > What is the size of the IPCB(struct inpcb) and TPCB(struct tcpcb) structure? > > (ignoring platform specific alignment issues) > > > > Stevens v2 has 84(inpcb) and 140(tcpcb) bytes. its more on topic for a C beginners mailing list. whats so hard about including the header file and using sizeof()? -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 14:47: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 67A6837B407 for ; Mon, 27 Aug 2001 14:46:55 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1E0D881D01; Mon, 27 Aug 2001 16:46:45 -0500 (CDT) Date: Mon, 27 Aug 2001 16:46:45 -0500 From: Alfred Perlstein To: Mike Silbersack Cc: Bill Fumerola , Kris Kennaway , "S.V. Ganesh" , freebsd-net@FreeBSD.ORG Subject: Re: Fwd: TCP PCB size Message-ID: <20010827164645.K81307@elvis.mu.org> References: <20010827153503.J81307@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Mon, Aug 27, 2001 at 04:57:31PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [010827 15:57] wrote: > > On Mon, 27 Aug 2001, Alfred Perlstein wrote: > > > It's actually a bit more difficult than that because you need to > > include a bunch of kernel headers (as well as defining _KERNEL) > > to get at it from userland. > > The easy way to do this is to copy the top of one of the files from > netstat, which already has all the includes included and in the proper > order. :) Odd, you think it would only need to know of the xsocket/xinpcb stuff which is exported to userland. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 15:10:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 9964C37B403 for ; Mon, 27 Aug 2001 15:10:21 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 3D8995D33; Tue, 28 Aug 2001 00:10:21 +0200 (CEST) Date: Tue, 28 Aug 2001 00:10:21 +0200 From: Jesper Skriver To: Mike Silbersack Cc: Scott Renfro , Barney Wolff , freebsd-net@FreeBSD.ORG, Jonathan Lemon , Bill Fenner , Cory Scott Subject: Re: Proposed change to icmp_may_rst induced ENETRESET Message-ID: <20010828001021.I65064@skriver.dk> References: <20010827150923.L55723@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Mon, Aug 27, 2001 at 04:54:31PM -0400 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 27, 2001 at 04:54:31PM -0400, Mike Silbersack wrote: > > On Mon, 27 Aug 2001, Jesper Skriver wrote: > > > On Thu, Aug 23, 2001 at 06:23:31PM -0700, Scott Renfro wrote: > > > You have a valid point that icmp_may_rst changes nmap's behavior, even > > > with the proposed patch. If you want nmap's historic behavior (admin > > > prohib ==> filtered), then turning off icmp_may_rst works. With > > > icmp_may_rst turned on and the patch commited, you get the other > > > behavior (admin prohib ==> closed). Without the patch, nmap spews > > > errors and would need a FreeBSD-specific change. > > > > I pretty much doesn't care, Jonathan, Bill, Mike what do you think ? > > > > /Jesper > > Seems best to have icmp admin-prohibited return what a RST would, just to > be compatible with the widest range of apps, IMHO. Ack, committed to -current /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 15:13:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 2609937B403 for ; Mon, 27 Aug 2001 15:13:43 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 14471 invoked by uid 3193); 27 Aug 2001 22:13:41 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Aug 2001 22:13:41 -0000 Date: Mon, 27 Aug 2001 18:13:41 -0400 (EDT) From: Mike Silbersack X-Sender: To: Alfred Perlstein Cc: Bill Fumerola , Kris Kennaway , "S.V. Ganesh" , Subject: Re: Fwd: TCP PCB size In-Reply-To: <20010827164645.K81307@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 27 Aug 2001, Alfred Perlstein wrote: > * Mike Silbersack [010827 15:57] wrote: > > > > The easy way to do this is to copy the top of one of the files from > > netstat, which already has all the includes included and in the proper > > order. :) > > Odd, you think it would only need to know of the xsocket/xinpcb > stuff which is exported to userland. > > -- > -Alfred Perlstein [alfred@freebsd.org] True, that's all it should need to know. However, it does include basically all netinet related headers, and we have no #ifdef _KERNEL around the structure definitions in said header files. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 18: 4:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id 780FC37B421; Mon, 27 Aug 2001 18:04:42 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from gere.odin.pdx.edu (gere.odin.pdx.edu [131.252.120.42]) by thor.oit.pdx.edu (8.11.6/8.11.6) with ESMTP id f7S14f208777; Mon, 27 Aug 2001 18:04:41 -0700 (PDT) Received: from localhost (singh@localhost) by gere.odin.pdx.edu (8.11.6/8.11.6) with ESMTP id f7S14fm28421; Mon, 27 Aug 2001 18:04:41 -0700 (PDT) X-Authentication-Warning: gere.odin.pdx.edu: singh owned process doing -bs Date: Mon, 27 Aug 2001 18:04:40 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Mike Silbersack Cc: Dave Zarzycki , Alfred Perlstein , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I agree with your comment that FCAK is only a retransmission algorithm and many papers recommends that FACK+SACK improves the performance for long-delay network (for more information look at 1996 SIGCOMM paper). I would say that it would be nice to have SACK+FACK+NewReno and all have a sysctl so that user can use it at will. This facility will give the leverage to people who want to test the performance of TCP in the presence of NewReno, Sack and Fack. In my patch FACK will be used in combination with SACK! Regards, Harkirat Singh On Sun, 26 Aug 2001, Mike Silbersack wrote: > > On Wed, 22 Aug 2001, singh wrote: > > > I even observed that FreeBSD4.3 adopts to NewReno algorith which is a > > suggestion in RFC-2582 (which talks about NewReno, SACK and FACK), for clients > > who can not have SACK/FACK, new reno will alleviate the problem of duplicate > > acks in Fast Recovery stage and partial ack is a better solution as comapre to > > reno algorithm. > > Ok, I looked over the patch more, as well as the RFCs. Basic SACK support > seems straightforward according to the RFCs, but FACK is a bit more > complex. From what I can tell, FACK isn't a tcp feature as much as a > retransmission scheme. This scheme, in turn, has been updated and is now > called "rate halving". > > Is the FACK implementation in this patch the old version, or the > rate-halving version? Also, does FACK spill over into non-SACKed > connections? I couldn't tell from a quick readthrough. > > I've also noticed that while SACK is sysctl disableable, FACK is not. A > sysctl for FACK should be added as well so that we can enable/disable it > at will (as can be done with newreno.) > > Thanks, > > Mike "Silby" Silbersack > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 19:49:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id A27A037B406; Mon, 27 Aug 2001 19:49:31 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.4/8.11.4) with ESMTP id f7S2nOZ62047; Mon, 27 Aug 2001 22:49:24 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200108280249.f7S2nOZ62047@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Harkirat Singh Cc: Mike Silbersack , Dave Zarzycki , Alfred Perlstein , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: RFC: SACK/FACK patch port to Current References: In-reply-to: Your message of "Mon, 27 Aug 2001 18:04:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2001 22:49:24 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I agree with your comment that FCAK is only a retransmission algorithm and > many papers recommends that FACK+SACK improves the performance for > long-delay network (for more information look at 1996 SIGCOMM paper). Most of the hair in a TCP implementation is "only" the retransmission algorithm. Having been a co-author of a TCP/IP stack 20 years ago, and been through the evolution of TCP with Van Jacobson's work, I cringe everytime I see yet another hack in the FreeBSD TCP. It's hard to get right, even when you know what effect you're trying to achieve. Consider that much of the work that resulted in slow-start and other other related work that Van did was accompanied by a considerable of before and after testing to measure the effect. I sure hope someone has done that testing and analysis of this code and the effect on the FreeBSD TCP implementation. I don't think that a drive-by commit of some other related work without a commitment to understand the code in a very deep way is wise. If you consider the dynamic range that the TCP retransmit timers need to operate over, it's a truly frighting thing, and folks ought not to be anxious screw with the implementation lightly. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 20:32:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from maxim.gbch.net (gw.gbch.net [203.24.22.66]) by hub.freebsd.org (Postfix) with SMTP id 1D23637B403 for ; Mon, 27 Aug 2001 20:32:06 -0700 (PDT) (envelope-from gjb@gbch.net) Received: (qmail 68894 invoked by uid 1001); 28 Aug 2001 13:31:56 +1000 Message-ID: X-Posted-By: GJB-Post 2.21 16-Jun-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Date: Tue, 28 Aug 2001 13:31:56 +1000 From: Greg Black To: itojun@iijlab.net Cc: Julian Elischer , Keiichi SHIMA , net@freebsd.org, users@ipv6.org, core@kame.net Subject: Re: IPV6/KAME/protosw integration cleanup References: <28752.998915728@itojun.org> In-reply-to: <28752.998915728@itojun.org> of Mon, 27 Aug 2001 21:35:28 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org itojun@iijlab.net wrote: | >at least we'd get rid of the d*mned warning messages! | >Are you not aware that most of the warning messages for a normal | >kernel compile come from the KAME code? I am on compile number 157 | >for the KSE code. (in 3 weeks) | | though i have no freebsd-current box, i disagree. there are a lot of | other warnings i see from kernel compilation. why don't you attack | other folks as well. | | itojun | PS: i have unsubscribed from the list. i can't take this stress any more. The blowtorch should not be aimed at you. If Julian is bothered by the warning messages, there are simple steps he can take to eliminate them from the stuff he looks at -- common tools like grep, sed, awk, diff and the like make exercises like this quite trivial and he should employ them and stop the attacks on the KAME workers. Certainly, it would be good to get rid of the warnings in the long run, but all this drama is out of place now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 22: 5:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 4DDFA37B401 for ; Mon, 27 Aug 2001 22:05:38 -0700 (PDT) (envelope-from mike@sentex.net) Received: (from root@localhost) by cage.simianscience.com (8.11.6/8.11.5) id f7S55bF19922 for freebsd-net@freebsd.org; Tue, 28 Aug 2001 01:05:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from chimp.sentex.net (fcage [192.168.0.2]) by cage.simianscience.com (8.11.6/8.11.5av) with ESMTP id f7S55X919914 for ; Tue, 28 Aug 2001 01:05:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Aug 2001 01:05:32 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Subject: Runt frames = broken VLAN ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Can anyone tell me why the VLAN code might be causing my switches (ciscos) to see a lot of runt frames when the interface is in 802.1q trunking mode ? The same nic in the same port in regular ethernet mode does not cause this. e.g. FastEthernet0/20 is up, line protocol is up Hardware is Fast Ethernet, address is 0030.9410.9696 (bia 0030.9410.9696) Description: test trunking ports MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:01, output hang never Last clearing of "show interface" counters 02:10:40 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 3 packets/sec 11534 packets input, 2204339 bytes, 0 no buffer Received 0 broadcasts, 23 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 watchdog, 0 multicast 0 input packets with dribble condition detected 23960 packets output, 18559944 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out ping -c 3 -s 10 host-on-the-other-side will increment the runt count by 3 each time. The cisco looks like interface FastEthernet0/20 speed 100 duplex full switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,105-125,1002-1005 switchport mode trunk ! The nic looks like fxp1: flags=8843 mtu 1500 inet 10.255.255.253 netmask 0xfffffffc broadcast 10.255.255.255 inet6 fe80::201:80ff:fe05:9356%fxp1 prefixlen 64 scopeid 0x3 ether 00:01:80:05:93:56 media: Ethernet 100baseTX status: active The config statement looks like ifconfig vlan0 1.2.3.1 netmask 255.255.255.252 vlan 105 vlandev fxp1 mtu 1500 up If the other side is 1.2.3.2 ping -c 3 -s 10 1.2.3.2 from anywhere on the net, will cause the runt frames to increase by 3. i.e. with each small ping packet, I get a runt frame. According to Cisco's documentation, runt frames are a sign of collisions (this is full duplex end to end) in a non switched network, or a sign of broken software ie. the driver. Does anyone know what might be going on ? ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 22:37: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 972B137B406 for ; Mon, 27 Aug 2001 22:36:58 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 77533 invoked by uid 3193); 28 Aug 2001 05:36:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Aug 2001 05:36:57 -0000 Date: Tue, 28 Aug 2001 01:36:57 -0400 (EDT) From: Mike Silbersack X-Sender: To: Harkirat Singh Cc: Dave Zarzycki , Alfred Perlstein , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 27 Aug 2001, Harkirat Singh wrote: > I agree with your comment that FCAK is only a retransmission algorithm and > many papers recommends that FACK+SACK improves the performance for > long-delay network (for more information look at 1996 SIGCOMM paper). I've been reading through the papers I've found, digesting the content slowly. Implementing FACK and/or rate halving after SACK is all in place and working seems like a good idea, if the papers are correct. > I would say that it would be nice to have SACK+FACK+NewReno and all have a > sysctl so that user can use it at will. This facility will give the > leverage to people who want to test the performance of TCP in the presence > of NewReno, Sack and Fack. Agreed. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 27 22:39:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 9C41937B407 for ; Mon, 27 Aug 2001 22:39:09 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 77681 invoked by uid 3193); 28 Aug 2001 05:39:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Aug 2001 05:39:09 -0000 Date: Tue, 28 Aug 2001 01:39:09 -0400 (EDT) From: Mike Silbersack X-Sender: To: "Louis A. Mamakos" Cc: Harkirat Singh , Dave Zarzycki , Alfred Perlstein , Subject: Re: RFC: SACK/FACK patch port to Current In-Reply-To: <200108280249.f7S2nOZ62047@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 27 Aug 2001, Louis A. Mamakos wrote: > I don't think that a drive-by commit of some other related work without > a commitment to understand the code in a very deep way is wise. > > If you consider the dynamic range that the TCP retransmit timers need to > operate over, it's a truly frighting thing, and folks ought not to be > anxious screw with the implementation lightly. > > louie By the time something gets committed, it will certainly be well tested, and sysctl controlable. If the testing doesn't seem sufficient at that time, you're more than welcome to throw in scenarios it should be tested under. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 4:57: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from asdf.dk (electropop.netgroup.dk [195.41.198.44]) by hub.freebsd.org (Postfix) with ESMTP id 1952837B407 for ; Tue, 28 Aug 2001 04:56:56 -0700 (PDT) (envelope-from hroi@netgroup.dk) Received: from netgroup.dk (localhost [127.0.0.1]) by asdf.dk (Postfix) with ESMTP id 846C7D5; Tue, 28 Aug 2001 13:56:49 +0200 (CEST) Message-ID: <3B8B8701.D24E204@netgroup.dk> Date: Tue, 28 Aug 2001 13:56:49 +0200 From: Hroi Sigurdsson Organization: Netgroup A/S X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Tancsa Cc: freebsd-net@freebsd.org Subject: Re: Runt frames = broken VLAN ? References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa wrote: > According to Cisco's documentation, runt frames are a sign of collisions > (this is full duplex end to end) in a non switched network, or a sign of > broken software ie. the driver. Does anyone know what might be going on ? I don't know what it is but I'm seeing the same here on a Catalyst 3548 and FreeBSD 4.3-STABLE (July 4th), fxp cards. Packets do get through though. FastEthernet0/34 is up, line protocol is up Hardware is Fast Ethernet, address is 0005.32a2.7e62 (bia 0005.32a2.7e62) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 15000 bits/sec, 17 packets/sec 2311 packets input, 220685 bytes Received 1465 broadcasts, 869 runts, 0 giants, 0 throttles 869 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 2 multicast 0 input packets with dribble condition detected 38453483 packets output, 2531782393 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out bat# ifconfig fxp1 fxp1: flags=8843 mtu 1500 inet6 fe80::200:e2ff:fe3a:ee3f%fxp1 prefixlen 64 scopeid 0x2 ether 00:00:e2:3a:ee:3f media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX bat# ifconfig vlan0 vlan0: flags=8843 mtu 1500 inet6 fe80::200:e2ff:fe3a:ee40%vlan0 prefixlen 64 scopeid 0x3 inet 192.168.100.177 netmask 0xffffff00 broadcast 192.168.100.255 ether 00:00:e2:3a:ee:3f vlan: 501 parent interface: fxp1 bat# grep -E '^fxp|^inphy' /var/run/dmesg.boot fxp0: port 0x3800-0x383f mem 0xb300000-0xb3fffff,0xb200000-0xb200fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:00:e2:3a:ee:40 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0x3000-0x303f mem 0x9200000-0x92fffff,0x9100000-0x9100fff irq 7 at device 12.0 on pci0 fxp1: Ethernet address 00:00:e2:3a:ee:3f inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -- Hroi Sigurdsson hroi@netgroup.dk Netgroup A/S http://www.netgroup.dk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 5:47:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C3B037B403 for ; Tue, 28 Aug 2001 05:47:21 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f7SClKvR025635 for ; Tue, 28 Aug 2001 13:47:20 +0100 Date: Tue, 28 Aug 2001 13:47:20 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Subject: Gratuitous ARP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Easy question time, but I can't find it documented. How can I reliably (and non-destructively) trigger the sending of a single gratuitous ARP reply for some local IP/MAC address? Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 6:29:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 9CF6837B407 for ; Tue, 28 Aug 2001 06:29:18 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id f7SDTAZ90715; Tue, 28 Aug 2001 09:29:10 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20010828092209.03c05ec0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Aug 2001 09:23:09 -0400 To: Hroi Sigurdsson From: Mike Tancsa Subject: Re: Runt frames = broken VLAN ? Cc: freebsd-net@freebsd.org In-Reply-To: <3B8B8701.D24E204@netgroup.dk> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 01:56 PM 8/28/01 +0200, Hroi Sigurdsson wrote: >Mike Tancsa wrote: > > > According to Cisco's documentation, runt frames are a sign of collisions > > (this is full duplex end to end) in a non switched network, or a sign of > > broken software ie. the driver. Does anyone know what might be going on ? > >I don't know what it is but I'm seeing the same here on a Catalyst 3548 >and FreeBSD 4.3-STABLE (July 4th), fxp cards. Packets do get through though. Yes, they get through here as well. There seems to be some stalls and retransmits however which is what concerns me. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 7:27:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by hub.freebsd.org (Postfix) with ESMTP id 1FBF437B401 for ; Tue, 28 Aug 2001 07:27:34 -0700 (PDT) (envelope-from leventi@fgan.de) Received: from rufsun5.ffm.fgan.de (mailhost.ffm.fgan.de [128.7.2.5]) by mailguard.fgan.de (8.9.3/8.9.3) with ESMTP id QAA28088; Tue, 28 Aug 2001 16:27:25 +0200 Received: from melle.fkie.fgan.de (melle.ffm.fgan.de [128.7.5.11]) by rufsun5.ffm.fgan.de (8.8.6/8.8.8) with ESMTP id QAA28293; Tue, 28 Aug 2001 16:27:25 +0200 (MET DST) Received: (from lev@localhost) by melle.fkie.fgan.de (8.10.2+Sun/8.10.2) id f7SEROD01073; Tue, 28 Aug 2001 16:27:24 +0200 (MEST) Date: Tue, 28 Aug 2001 16:27:24 +0200 (MEST) Message-Id: <200108281427.f7SEROD01073@melle.fkie.fgan.de> From: Anastasia Leventi-Peetz To: itojun@iijlab.net Cc: jinmei@isl.rdc.toshiba.co.jp, leventi@fgan.de, net@FreeBSD.ORG In-reply-to: <20010828140530.2E8597BA@starfruit.itojun.org> (message from Jun-ichiro itojun Hagino on Tue, 28 Aug 2001 23:05:30 +0900) Subject: Re: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org yes itojun, you are right with your remark, on the other side I don't see by all available RFC's about tunneling IPv6 over IPv4, how can somebody perform it, without such a Link Local Address! (In this sense it is very relevant what JINMEI, Tatuya wrote) I have read about such a tunnel success between FreeBSD and Linux, but on the FreeBSD there was not the KAME stack. Unfortunatelly I get no Info on the subject... Anastasia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 7:33:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id C7B4C37B406 for ; Tue, 28 Aug 2001 07:33:10 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EB44D4B21; Tue, 28 Aug 2001 23:32:56 +0900 (JST) To: Anastasia Leventi-Peetz Cc: jinmei@isl.rdc.toshiba.co.jp, net@FreeBSD.ORG In-reply-to: leventi's message of Tue, 28 Aug 2001 16:27:24 +0200. <200108281427.f7SEROD01073@melle.fkie.fgan.de> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: From: itojun@iijlab.net Date: Tue, 28 Aug 2001 23:32:56 +0900 Message-ID: <13704.999009176@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >yes itojun, you are right with your remark, on the other side I don't >see by all available RFC's about tunneling IPv6 over IPv4, how >can somebody perform it, without such a Link Local Address! >(In this sense it is very relevant what JINMEI, Tatuya wrote) for configured tunnels, there's no relationship whatsoever between the link-local address on tunnelling interface, and the IPv4 address used to terminate the tunnel. jinmei's comment is totally unrelated to the topic, I would say. >I have read about such a tunnel success between FreeBSD and Linux, but >on the FreeBSD there was not the KAME stack. >Unfortunatelly I get no Info on the subject... now, what do you want to accomplish. this is still not clear to me. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 7:44:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by hub.freebsd.org (Postfix) with ESMTP id 5B72837B408 for ; Tue, 28 Aug 2001 07:44:24 -0700 (PDT) (envelope-from leventi@fgan.de) Received: from rufsun5.ffm.fgan.de (mailhost.ffm.fgan.de [128.7.2.5]) by mailguard.fgan.de (8.9.3/8.9.3) with ESMTP id QAA28621; Tue, 28 Aug 2001 16:44:20 +0200 Received: from melle.fkie.fgan.de (melle.ffm.fgan.de [128.7.5.11]) by rufsun5.ffm.fgan.de (8.8.6/8.8.8) with ESMTP id QAA28674; Tue, 28 Aug 2001 16:44:19 +0200 (MET DST) Received: (from lev@localhost) by melle.fkie.fgan.de (8.10.2+Sun/8.10.2) id f7SEiIT01108; Tue, 28 Aug 2001 16:44:18 +0200 (MEST) Date: Tue, 28 Aug 2001 16:44:18 +0200 (MEST) Message-Id: <200108281444.f7SEiIT01108@melle.fkie.fgan.de> From: Anastasia Leventi-Peetz To: itojun@iijlab.net Cc: leventi@fgan.de, jinmei@isl.rdc.toshiba.co.jp, net@FreeBSD.ORG In-reply-to: <13704.999009176@itojun.org> Subject: Re: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org nice to ask itojun, thank you. I wish to establish a configured SIT tunnel between a Linux box and a FreeBSD box. (host to host only) By the tunnel configuration on Linux side i give ifconfig sit0 tunnel ::IPv4-Address on the FreeBSD side. Automatically appears in the Linux routing table the fe80::IPv4(in hex) of the FreeBSD box as nexthop. But this address is not accesible because it doesnt exist on the other side therefore (i believe at least) I don't get a connection over the tunnel. I have seen routing tables of FreeBSD systems (in Internet) where fe80::IPv4(in hex)%gif0 was present. I am missing that. thanks a lot Anastasia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 8: 9:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 5227037B406 for ; Tue, 28 Aug 2001 08:09:34 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7SF8xK47918; Tue, 28 Aug 2001 18:08:59 +0300 (EEST) (envelope-from ru) Date: Tue, 28 Aug 2001 18:08:59 +0300 From: Ruslan Ermilov To: Joshua Goodall Cc: freebsd-net@FreeBSD.ORG Subject: Re: Gratuitous ARP Message-ID: <20010828180859.B39758@sunbay.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joshua@roughtrade.net on Tue, Aug 28, 2001 at 01:47:20PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Aug 28, 2001 at 01:47:20PM +0100, Joshua Goodall wrote: > > Easy question time, but I can't find it documented. How can I reliably > (and non-destructively) trigger the sending of a single gratuitous ARP > reply for some local IP/MAC address? > Under "local", do you mean the IP assigned to one of the local host's interfaces? If so, that could be done with ifconfig(8), though a bit tricky. For example, let assume that 192.168.0.1 is the address assigned to the if0 interface with the standard Class C netmask of 255.255.255.0. Then, if you run `ifconfig if0 192.168.0.1', that will cause the gratuitous ARP to be sent out, but that will delete and re-add the 192.168.0.1 address to the if0 interface blowing up any routes that used this address, probably the `default' route. The magic here is to use the `netmask' and `alias' keywords. That is, `ifconfig if0 192.168.0.1 netmask 255.255.255.0 alias' will achieve the desired effect. You can omit the address part (192.168.0.1) and the `alias' keyword, if the 192.168.0.1 is the only address bound to the if0 interface, like this: `ifconfig if0 netmask 255.255.255.0'. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 8:19: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from mercury.ccmr.cornell.edu (mercury.ccmr.cornell.edu [128.84.231.97]) by hub.freebsd.org (Postfix) with ESMTP id 14F4D37B401; Tue, 28 Aug 2001 08:18:59 -0700 (PDT) (envelope-from mitch@ccmr.cornell.edu) Received: from ruby.ccmr.cornell.edu (IDENT:0@ruby.ccmr.cornell.edu [128.84.231.115]) by mercury.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA26219; Tue, 28 Aug 2001 11:19:03 -0400 Received: from localhost (mitch@localhost) by ruby.ccmr.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA01465; Tue, 28 Aug 2001 11:18:58 -0400 X-Authentication-Warning: ruby.ccmr.cornell.edu: mitch owned process doing -bs Date: Tue, 28 Aug 2001 11:18:58 -0400 (EDT) From: Mitch Collinsworth To: Ruslan Ermilov Cc: Joshua Goodall , freebsd-net@FreeBSD.ORG Subject: Re: Gratuitous ARP In-Reply-To: <20010828180859.B39758@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It's not clear what Jushua is asking for, but my guess is proxy arp. See arp(8), in particular the -s flag. -Mitch On Tue, 28 Aug 2001, Ruslan Ermilov wrote: > On Tue, Aug 28, 2001 at 01:47:20PM +0100, Joshua Goodall wrote: > > > > Easy question time, but I can't find it documented. How can I reliably > > (and non-destructively) trigger the sending of a single gratuitous ARP > > reply for some local IP/MAC address? > > > Under "local", do you mean the IP assigned to one of the local host's > interfaces? If so, that could be done with ifconfig(8), though a bit > tricky. > > For example, let assume that 192.168.0.1 is the address assigned to the > if0 interface with the standard Class C netmask of 255.255.255.0. Then, > if you run `ifconfig if0 192.168.0.1', that will cause the gratuitous > ARP to be sent out, but that will delete and re-add the 192.168.0.1 > address to the if0 interface blowing up any routes that used this > address, probably the `default' route. > > The magic here is to use the `netmask' and `alias' keywords. That is, > `ifconfig if0 192.168.0.1 netmask 255.255.255.0 alias' will achieve the > desired effect. You can omit the address part (192.168.0.1) and the > `alias' keyword, if the 192.168.0.1 is the only address bound to the > if0 interface, like this: `ifconfig if0 netmask 255.255.255.0'. > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 9:54:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E31FD37B405 for ; Tue, 28 Aug 2001 09:54:20 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7SGsIF38299; Tue, 28 Aug 2001 12:54:18 -0400 (EDT) (envelope-from wollman) Date: Tue, 28 Aug 2001 12:54:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Runt frames = broken VLAN ? In-Reply-To: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Can anyone tell me why the VLAN code might be causing my switches (ciscos) > to see a lot of runt frames when the interface is in 802.1q trunking mode ? It's possible that the Cisco is (bogusly, IMHO) trying to enforce the Ethernet minimum frame length on the *de*capsulated frames. If you send a frame that's less than 60 octets long, it gets encapsulated (adding another four octets) and then padded by the interface up to 64 octets. After the encapsulation is removed by the receiver, the frame appears to only be 60 octets long. I'd call it a Cisco bug. The minimum frame length in Ethernet arises from the electrical parameters of the original CSMA/CD Ethernet design; what matters is the number of clocks the transmitter is active, not the length of the payload. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 10: 1:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.skyrunner.net (mail.new-era.com [208.133.44.6]) by hub.freebsd.org (Postfix) with ESMTP id 9248737B438 for ; Tue, 28 Aug 2001 10:01:12 -0700 (PDT) (envelope-from peter@skyrunner.net) Received: from skyrunne6e8soa (booray.new-era.com [208.150.25.130]) by mail.skyrunner.net (8.11.2/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f7SH1Be08515 for ; Tue, 28 Aug 2001 13:01:11 -0400 From: "Peter Brezny" To: Subject: mpd-netgraph on minimal install not working. Date: Tue, 28 Aug 2001 12:54:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've not been able to get mpd-netgraph to work as a PPTP VPN server on a minimal freebsd 4.3-Release install. A minimal install with mpd 3.2 installed from the packages appears to work fine when configured. no errors in log files etc, however, nmap of the machine doesn't even show port 1723 as being available. The system has no firewall in place and is using the generic kernel configuration. I've instaled mpd-netgraph and configured it for use as a PPTP VPN server on the standard 'developer' install configuration of freebsd with complete success. What have I missed. TIA Peter Brezny Skyrunner.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 10:35:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 3F53937B406 for ; Tue, 28 Aug 2001 10:35:45 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f7SHZaq19524; Tue, 28 Aug 2001 10:35:36 -0700 Date: Tue, 28 Aug 2001 10:35:36 -0700 From: Brooks Davis To: Garrett Wollman Cc: Mike Tancsa , freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? Message-ID: <20010828103536.D10481@Odin.AC.HMC.Edu> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ieNMXl1Fr3cevapt" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Aug 28, 2001 at 12:54:18PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --ieNMXl1Fr3cevapt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2001 at 12:54:18PM -0400, Garrett Wollman wrote: > < said: >=20 > > Can anyone tell me why the VLAN code might be causing my switches (cisc= os)=20 > > to see a lot of runt frames when the interface is in 802.1q trunking mo= de ?=20 >=20 > It's possible that the Cisco is (bogusly, IMHO) trying to enforce the > Ethernet minimum frame length on the *de*capsulated frames. If you > send a frame that's less than 60 octets long, it gets encapsulated > (adding another four octets) and then padded by the interface up to 64 > octets. After the encapsulation is removed by the receiver, the frame > appears to only be 60 octets long. >=20 > I'd call it a Cisco bug. The minimum frame length in Ethernet arises > from the electrical parameters of the original CSMA/CD Ethernet > design; what matters is the number of clocks the transmitter is > active, not the length of the payload. But doesn't the switch have to assume that the VLAN will be attached to some non-trunked ports, in which case the packets must be an appropriate length. From a switch vendor's perspective the case of a VLAN with no non-trunked ports is going to be a bizzare edge case. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ieNMXl1Fr3cevapt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7i9ZnXY6L6fI4GtQRAtosAJ9ESjVjJL8JijDjcDP6n1aCxcY7ogCgs11J EJQXU/gOTI8noHzpxFiUCmo= =7/y+ -----END PGP SIGNATURE----- --ieNMXl1Fr3cevapt-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 10:59:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 17A7E37B40A for ; Tue, 28 Aug 2001 10:59:46 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7SHxh439282; Tue, 28 Aug 2001 13:59:43 -0400 (EDT) (envelope-from wollman) Date: Tue, 28 Aug 2001 13:59:43 -0400 (EDT) From: Garrett Wollman Message-Id: <200108281759.f7SHxh439282@khavrinen.lcs.mit.edu> To: Brooks Davis Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? In-Reply-To: <20010828103536.D10481@Odin.AC.HMC.Edu> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> <20010828103536.D10481@Odin.AC.HMC.Edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > But doesn't the switch have to assume that the VLAN will be attached to > some non-trunked ports, in which case the packets must be an appropriate > length. The minimum length needs to be enforced at the output interface. (A switch would need to do so anyway for locally-generated packets.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 11:29: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailgate.program-products.co.uk (samson.program-products.co.uk [212.240.242.226]) by hub.freebsd.org (Postfix) with ESMTP id 827F937B406 for ; Tue, 28 Aug 2001 11:29:03 -0700 (PDT) (envelope-from terry@program-products.co.uk) Received: by mailgate.program-products.co.uk via smap (V2.1) id xma089628; Tue, 28 Aug 01 19:28:16 +0100 Distribution: local To: Cc: joshua@roughtrade.net (Joshua Goodall) Subject: Re: Gratuitous ARP References: From: Terry Glanfield Date: 28 Aug 2001 19:27:40 +0100 In-Reply-To: joshua@roughtrade.net's message of "28 Aug 2001 13:47:52 +0100" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.44/Emacs 19.34 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org joshua@roughtrade.net (Joshua Goodall) writes: > Easy question time, but I can't find it documented. How can I reliably > (and non-destructively) trigger the sending of a single gratuitous ARP > reply for some local IP/MAC address? arping (from ports) and ping the broadcast address. Terry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 12:53:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id DA29937B407 for ; Tue, 28 Aug 2001 12:53:08 -0700 (PDT) (envelope-from alex@pilosoft.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id PAA20294; Tue, 28 Aug 2001 15:53:32 -0400 (EDT) Date: Tue, 28 Aug 2001 15:53:31 -0400 (EDT) From: Alex Pilosov To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? In-Reply-To: <200108281759.f7SHxh439282@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 28 Aug 2001, Garrett Wollman wrote: > < said: > > > But doesn't the switch have to assume that the VLAN will be attached to > > some non-trunked ports, in which case the packets must be an appropriate > > length. > > The minimum length needs to be enforced at the output interface. > (A switch would need to do so anyway for locally-generated packets.) Disagree. Packet is either a runt or not a runt. It cannot be inconsistently bridged it to one (trunk) interface but not to (access) interface. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 13: 8:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 601D437B403 for ; Tue, 28 Aug 2001 13:08:10 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7SK88340636; Tue, 28 Aug 2001 16:08:08 -0400 (EDT) (envelope-from wollman) Date: Tue, 28 Aug 2001 16:08:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200108282008.f7SK88340636@khavrinen.lcs.mit.edu> To: Alex Pilosov Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? In-Reply-To: References: <200108281759.f7SHxh439282@khavrinen.lcs.mit.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Disagree. Packet is either a runt or not a runt. It cannot be > inconsistently bridged it to one (trunk) interface but not to (access) > interface. Runt-ness is not a property of the contents of the frame, it's a property of the wire the frame is sent on. A frame bridged from another network with no minimum frame length must be properly padded upon output if it is to be sent on an Ethernet. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 13:17:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id 1744837B40C for ; Tue, 28 Aug 2001 13:17:22 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id f7SKHJl65255; Tue, 28 Aug 2001 16:17:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20010828160054.01accec0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Aug 2001 16:11:16 -0400 To: Garrett Wollman From: Mike Tancsa Subject: Re: Runt frames = broken VLAN ? Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 12:54 PM 8/28/01 -0400, Garrett Wollman wrote: >< said: > > > Can anyone tell me why the VLAN code might be causing my switches (ciscos) > > to see a lot of runt frames when the interface is in 802.1q trunking > mode ? > >It's possible that the Cisco is (bogusly, IMHO) trying to enforce the >Ethernet minimum frame length on the *de*capsulated frames. If you >send a frame that's less than 60 octets long, it gets encapsulated >(adding another four octets) and then padded by the interface up to 64 >octets. After the encapsulation is removed by the receiver, the frame >appears to only be 60 octets long. > >I'd call it a Cisco bug. The minimum frame length in Ethernet arises >from the electrical parameters of the original CSMA/CD Ethernet >design; what matters is the number of clocks the transmitter is >active, not the length of the payload. If its a Cisco bug, would it not manifest it self consistently ? On other ports, I have a 3620 and another catalyst both in 802.1q trunking mode, but I dont see any runt frames there. Also, who is the VLAN maintainer these days ? I ran into a panic that I thought was netgraph related, but Archie Cobbs thinks it might be in the VLAN code. I filed a PR on the issue http://www.freebsd.org/cgi/query-pr.cgi?pr=30149 I saved the debug kernel as well as the core dump in case its needed, but the problem is easy enough to repeat. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 13:24:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DFC7737B406 for ; Tue, 28 Aug 2001 13:24:29 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7SKOR340840; Tue, 28 Aug 2001 16:24:27 -0400 (EDT) (envelope-from wollman) Date: Tue, 28 Aug 2001 16:24:27 -0400 (EDT) From: Garrett Wollman Message-Id: <200108282024.f7SKOR340840@khavrinen.lcs.mit.edu> To: Mike Tancsa Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? In-Reply-To: <5.1.0.14.0.20010828160054.01accec0@marble.sentex.ca> References: <5.1.0.14.0.20010828010515.0221d380@192.168.0.12> <200108281654.f7SGsIF38299@khavrinen.lcs.mit.edu> <5.1.0.14.0.20010828160054.01accec0@marble.sentex.ca> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Also, who is the VLAN maintainer these days ? I think that code has a ``sticky hat'', so whoever last touched it is ``it''. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 13:39: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id A7D1237B405 for ; Tue, 28 Aug 2001 13:38:57 -0700 (PDT) (envelope-from alex@pilosoft.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id QAA25405 for ; Tue, 28 Aug 2001 16:39:24 -0400 (EDT) Date: Tue, 28 Aug 2001 16:39:24 -0400 (EDT) From: Alex Pilosov Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? In-Reply-To: <200108282008.f7SK88340636@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 28 Aug 2001, Garrett Wollman wrote: > < said: > > > Disagree. Packet is either a runt or not a runt. It cannot be > > inconsistently bridged it to one (trunk) interface but not to (access) > > interface. > > Runt-ness is not a property of the contents of the frame, it's a > property of the wire the frame is sent on. A frame bridged from > another network with no minimum frame length must be properly padded > upon output if it is to be sent on an Ethernet. Looking up the authoritative source: http://www.ieee802.org/1/pages/802.1Q.html (click through on download, you need to accept terms), I'm wrong, so apologies. Section 7.2 (and C.4.4) says that switch or end station MAY pad the frame to be 68 bytes, but it is not required, and that this frame must be padded to 64 bytes when transmitted to non-trunk interface. C.4.4.3 clearly states that "The implication of this is that, for correct operation on 802.3/Ethernet, all devices have to be capable of correctly handling tagged frames of less than 68 octets in length (C.4.4.3)." But it still would be nice for it to interoperate with cisco by implementing that optional thing...;) -alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 16:26:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id C79DA37B407 for ; Tue, 28 Aug 2001 16:26:16 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f7SNQFvR000336 for ; Wed, 29 Aug 2001 00:26:15 +0100 Date: Wed, 29 Aug 2001 00:26:15 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Subject: Re: Gratuitous ARP (summary) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 28 Aug 2001, Mitch Collinsworth wrote: > It's not clear what Jushua is asking for, but my guess is proxy arp. > See arp(8), in particular the -s flag. Then I will clarify and say that what I want is precisely described in section 4.7 of TCP/IP Illustrated Vol. 1 (Stevens) and looks like this on a tcpdump: bloo:~# tcpdump -teli fxp0 arp net 10.1.1 & tcpdump: listening on fxp0 0:a0:c9:ca:73:5f Broadcast arp 42: arp who-has 10.1.1.1 tell 10.1.1.1 and is primarily used for collision detection and network-local arp-cache priming, but also has applications in IP address migration (a common high-availability technique). I should not have described it as an "arp reply" since it is, of course, an "arp who-has". However a synthesis of the suggestions from Terry & Ruslan yields what I wanted: a) in the case where the address is an alias, re-issuing the ifconfig ... alias results in a gratuitous ARP for the alias address without losing the subnet route & ARP cache entries. However I use a netmask of 255.255.255.255 for all aliases in the same subnet as the primary, in line with the ifconfig(8) manual. b) in the case where the address is the primary address of the interface, an ifconfig will cycle the route *and* delete the ARP cache entries for the subnet. However, using arping to the interface primary address (not broadcast) gives a correctly formatted, non-destructive gratuitous ARP. So I'm happy now. Curiously, an ifconfig for an alias will generate a gratuitous ARP for that alias even if the -arp option is supplied. I'm not sure this is correct behaviour. Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 28 23:33:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from hirogen.kabelfoon.nl (hirogen.kabelfoon.nl [62.45.45.69]) by hub.freebsd.org (Postfix) with ESMTP id 8C01B37B406 for ; Tue, 28 Aug 2001 23:33:37 -0700 (PDT) (envelope-from pblok@inter.NL.net) Received: from ntpc (kf-pij-tg01-426.dial.kabelfoon.nl [62.45.89.172]) by hirogen.kabelfoon.nl (Postfix) with SMTP id EFF8C7CD2; Wed, 29 Aug 2001 08:33:35 +0200 (CEST) Reply-To: From: "Peter Blok" To: "'Mike Tancsa'" , "'Garrett Wollman'" Cc: Subject: RE: Runt frames = broken VLAN ? Date: Wed, 29 Aug 2001 08:29:09 +0200 Message-ID: <001001c13053$e9ea74c0$8a02a8c0@ntpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.0.20010828160054.01accec0@marble.sentex.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike, et al. I had the panic too. The problem is the order of initialization. It only happened when you compile NETGRAPH support in the kernel instead of using it as a module. When initialize netgraph a little bit later it works fine. In netgraph.h there is a macro called NETGRAPH_INIT. I have changed the SI_ORDER_ANY to SI_ORDER_LAST or SI_SUB_PSEUDO to something else (I can't remember). I am using the module. I'll check on this today and get a proper answer. Peter -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Mike Tancsa Sent: Tuesday, August 28, 2001 22:11 To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Runt frames = broken VLAN ? At 12:54 PM 8/28/01 -0400, Garrett Wollman wrote: >< said: > > > Can anyone tell me why the VLAN code might be causing my switches (ciscos) > > to see a lot of runt frames when the interface is in 802.1q trunking > mode ? > >It's possible that the Cisco is (bogusly, IMHO) trying to enforce the >Ethernet minimum frame length on the *de*capsulated frames. If you >send a frame that's less than 60 octets long, it gets encapsulated >(adding another four octets) and then padded by the interface up to 64 >octets. After the encapsulation is removed by the receiver, the frame >appears to only be 60 octets long. > >I'd call it a Cisco bug. The minimum frame length in Ethernet arises >from the electrical parameters of the original CSMA/CD Ethernet >design; what matters is the number of clocks the transmitter is >active, not the length of the payload. If its a Cisco bug, would it not manifest it self consistently ? On other ports, I have a 3620 and another catalyst both in 802.1q trunking mode, but I dont see any runt frames there. Also, who is the VLAN maintainer these days ? I ran into a panic that I thought was netgraph related, but Archie Cobbs thinks it might be in the VLAN code. I filed a PR on the issue http://www.freebsd.org/cgi/query-pr.cgi?pr=30149 I saved the debug kernel as well as the core dump in case its needed, but the problem is easy enough to repeat. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 11:20:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from aeon.tvd.be (aeon.tvd.be [195.162.196.20]) by hub.freebsd.org (Postfix) with ESMTP id DBE5637B406 for ; Wed, 29 Aug 2001 11:20:50 -0700 (PDT) (envelope-from wouter@vub.ac.be) Received: from cocaine.cryolabs.net (cable-213-132-151-176.upc.chello.be [213.132.151.176]) by aeon.tvd.be (8.9.3/8.9.3/RELAY-1.1) with ESMTP id UAA17467 for ; Wed, 29 Aug 2001 20:20:48 +0200 (MET DST) Date: Wed, 29 Aug 2001 17:06:08 +0200 (CEST) From: Wouter Van Hemel To: Subject: ipv6 route configuration Message-ID: PGP: 0B B4 BC 28 53 62 FE 94 6A 57 EE B8 A6 E2 1B E4 (0xAA5412F0) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 'lo, Surprisingly unable to find good, extensive documentation on ipv6 or advanced ipv4 routing issues on the net, I turn to you with my problem, in the hope you can help me, or point me to some extensive information (not the 'hot to make a home network and share your connection'-stuff). I have an experimental /48 ipv6 network class, arriving on my router tunneled, and I'd like to route it to my internal network as follows: real_ip | <- ed0 -- ed1 -> internet |=--> router --> server1 | 192.168.196.1 192.168.196.2 --> server2 192.168.196.3 This is the simple, very basic ipv4 setup with natd. Now, I want to do the same, using the globally routable 3ffe:b80:1c8::/48 class (but without natd, ofcourse): router = 3ffe:b80:1c8::1 server1 = 3ffe:b80:1c8::2 server2 = 3ffe:b80:1c8::3 (etc) As you see, actually just like the 192.168.196.* network. The problem now is, that each setup I tried, only the router can be traced from the outside (3ffe:b80:1c8::1), and for instance server1 (3ffe:b80:1c8::2) either times out (traceroute = * * * etc), or starts repeating the packets between 3ffe:b80:1c8::1 and the upward tunnel address. I have a script, but it routes the 3ffe:b80:1c8:1:: network through, and hmmm... that's one character more to type :) Basically, what happens in the script (of those nice folks at freenet) is (after setting up the tunnel etc, that just works fine): ##### start ##### route add -inet6 3ffe:0b80:01c8:: -prefixlen 48 -interface lo0 (--> why lo0 ?? shouldn't this subnet be send to ed1, the internal net?) sysctl -w net.inet6.ip6.forwarding=1 sysctl -w net.inet6.ip6.accept_rtadv=0 ifconfig ed1 inet6 3ffe:b80:1c8:1::1 prefixlen 64 ##### end ##### and it makes a rtadvd.conf-file with: ##### start ##### default:\ :raflags#0:rltime#3600:\ :pinfoflags#64:vltime#360000:pltime#360000:mtu#1500: ether:\ :mtu#1280:tc=default: # interfaces. ed1:\ :addrs#1:\ :addr="3ffe:0b80:01c8:0001::":prefixlen#64:tc=ether: ##### end ##### So, my questions (finally :) ): 1) why does the /48 class get bound to lo0? 2) how do I send the full /48 class to the internal net, using ::1 for the router itself - like my ipv4 internal net? 3) does rtadvd have to run on all machines, or just the router? Anybody with a better understanding of routing, please enlighten me, or point me to good resources... thanks :) / wouter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 11:56:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id 2713637B401 for ; Wed, 29 Aug 2001 11:56:08 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 91779 invoked by uid 3193); 29 Aug 2001 18:56:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Aug 2001 18:56:06 -0000 Date: Wed, 29 Aug 2001 14:56:06 -0400 (EDT) From: Mike Silbersack X-Sender: To: Subject: BPF question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Silly question I could probably figure out myself, but thought it would be quicker to ask here... When listening on an ethernet interface, are the packets you see from yourself intercepted inside the network stack, or are you actually sniffing them off the wire? I'm helping someone track down corrupted packets he's seeing in tcpdump, and I'd like to know if I can locate where the corruption may be occuring more exactly. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 12: 7:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 328D937B409 for ; Wed, 29 Aug 2001 12:07:56 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 010A181D07; Wed, 29 Aug 2001 14:07:55 -0500 (CDT) Date: Wed, 29 Aug 2001 14:07:55 -0500 From: Alfred Perlstein To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: BPF question Message-ID: <20010829140755.T81307@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from silby@silby.com on Wed, Aug 29, 2001 at 02:56:06PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [010829 13:56] wrote: > Silly question I could probably figure out myself, but thought it would be > quicker to ask here... > > When listening on an ethernet interface, are the packets you see from > yourself intercepted inside the network stack, or are you actually > sniffing them off the wire? I'm helping someone track down corrupted > packets he's seeing in tcpdump, and I'd like to know if I can locate where > the corruption may be occuring more exactly. If you look, I'm pretty sure the tap occurs in ether_input/output, which means that obviously it is up to the driver to get the packet to that point unmolested. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 12:36: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 5DACE37B401 for ; Wed, 29 Aug 2001 12:36:06 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA85928; Wed, 29 Aug 2001 12:56:05 -0700 (PDT) Date: Wed, 29 Aug 2001 12:56:04 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: BPF question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To some extent it depends on the driver. check if_ethersubr.c and the driver for your interface to be sure. On Wed, 29 Aug 2001, Mike Silbersack wrote: > Silly question I could probably figure out myself, but thought it would be > quicker to ask here... > > When listening on an ethernet interface, are the packets you see from > yourself intercepted inside the network stack, or are you actually > sniffing them off the wire? I'm helping someone track down corrupted > packets he's seeing in tcpdump, and I'd like to know if I can locate where > the corruption may be occuring more exactly. > > Thanks, > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 13: 3:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by hub.freebsd.org (Postfix) with SMTP id D6BC637B406 for ; Wed, 29 Aug 2001 13:03:33 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 6128 invoked by uid 3193); 29 Aug 2001 20:03:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Aug 2001 20:03:25 -0000 Date: Wed, 29 Aug 2001 16:03:25 -0400 (EDT) From: Mike Silbersack X-Sender: To: Julian Elischer Cc: Subject: Re: BPF question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 29 Aug 2001, Julian Elischer wrote: > > To some extent it depends on the driver. > > check if_ethersubr.c and the driver for your interface to be sure. Ok, yeah, I found it. Looks like the driver gets its grubby little hands on the packet before injecting it into bpf. I'll have him try another NIC (+ driver). Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 13:11:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 6A9A437B408 for ; Wed, 29 Aug 2001 13:11:35 -0700 (PDT) (envelope-from oberman@ptavv.es.net) Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (8.10.1/8.10.1) with ESMTP id f7TKBZR23995 for ; Wed, 29 Aug 2001 13:11:35 -0700 (PDT) Message-Id: <200108292011.f7TKBZR23995@ptavv.es.net> To: net@freebsd.org Subject: Gig-E performance with FreeBSD Date: Wed, 29 Aug 2001 13:11:35 -0700 From: "Kevin Oberman" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Has anyone done any performance testing of Gig-E cards on FreeBSD? I need to run them with some high performance apps and I'm wondering what sort of performance people have been able to get, assuming large windows (up to 8 MB), with and without jumbo frames. Does anyone have any experience in this area? Thanks, R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 13:17:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from support.euronet.nl (support.euronet.nl [194.134.32.134]) by hub.freebsd.org (Postfix) with ESMTP id 9D91537B401 for ; Wed, 29 Aug 2001 13:17:37 -0700 (PDT) (envelope-from frans@quanza.net) Received: from localhost (franst@localhost) by support.euronet.nl (8.11.3/8.11.0) with ESMTP id f7TKHVw95559; Wed, 29 Aug 2001 22:17:31 +0200 (CEST) X-Authentication-Warning: support.euronet.nl: franst owned process doing -bs Date: Wed, 29 Aug 2001 22:17:31 +0200 (CEST) From: Frans ter Borg X-Sender: franst@support.euronet.nl To: Kevin Oberman Cc: net@FreeBSD.ORG Subject: Re: Gig-E performance with FreeBSD In-Reply-To: <200108292011.f7TKBZR23995@ptavv.es.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 29 Aug 2001, Kevin Oberman wrote: > Has anyone done any performance testing of Gig-E cards on FreeBSD? I > need to run them with some high performance apps and I'm wondering > what sort of performance people have been able to get, assuming large > windows (up to 8 MB), with and without jumbo frames. > > Does anyone have any experience in this area? don't want to sound like a me-too-er, but I'm very interested in this as well. Also I'm interested in the size of the routing table on the boxes that have been used. I'd like to find out how much a freebsd box with a full bgp-table (approx. 110.000 routes) can push in a live situation. Cheers, Frans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 14: 0:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E8E2537B406 for ; Wed, 29 Aug 2001 14:00:48 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7TL0gP73835; Wed, 29 Aug 2001 17:00:42 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 29 Aug 2001 17:00:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: BPF question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Depends on the SIMPLEX flag I believe, but for most ethernet interfaces, there's a software loopback. I actually take advantage of that to support the following BPF ioctl which I added: BIOCSSEESENT BIOCGSEESENT (u_int) Set or get the flag determining whether locally generated packets on the interface should be returned by BPF. Set to zero to see only incoming packets on the interface. Set to one to see packets originating locally and remotely on the interface. This flag is initialized to one by default. This is determined by checking that the mbuf pointer is non-NULL, indicating it originated in the interface code, rather than NULL, which signifies that it descended from a socket. Not 100% accurate with weird netgraph/etc cases, but sufficient for my needs, which permitted userland bridging using bpf. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 29 Aug 2001, Mike Silbersack wrote: > Silly question I could probably figure out myself, but thought it would be > quicker to ask here... > > When listening on an ethernet interface, are the packets you see from > yourself intercepted inside the network stack, or are you actually > sniffing them off the wire? I'm helping someone track down corrupted > packets he's seeing in tcpdump, and I'd like to know if I can locate where > the corruption may be occuring more exactly. > > Thanks, > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 29 15:51:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tgd.net (rand.tgd.net [64.81.67.117]) by hub.freebsd.org (Postfix) with SMTP id 90F5C37B407 for ; Wed, 29 Aug 2001 15:51:25 -0700 (PDT) (envelope-from sean@mailhost.tgd.net) Received: (qmail 3036 invoked by uid 1001); 29 Aug 2001 22:51:20 -0000 Date: Wed, 29 Aug 2001 15:51:20 -0700 From: Sean Chittenden To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org Subject: [yairamir@cnds.jhu.edu: [mls-users] Wackamole Release Announcement: N-Way Fail Over for IP addresses in a Cluster] Message-ID: <20010829155120.D2679@rand.tgd.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kjpMrWxdCilgNbo1" Content-Disposition: inline X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --kjpMrWxdCilgNbo1 Content-Type: multipart/mixed; boundary="E7i4zwmWs5DOuDSH" Content-Disposition: inline --E7i4zwmWs5DOuDSH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think enough of you guys would have an interest in this. The=20 guys at CNDS do some really nifty stuff: worth checking out. -sc --=20 Sean Chittenden --E7i4zwmWs5DOuDSH Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: chittenden.org-sean-apache-mls-users@chittenden.org Received: (qmail 2888 invoked from network); 29 Aug 2001 22:30:24 -0000 Received: from longsword.omniti.com (216.0.51.134) by perrin.tgd.net with SMTP; 29 Aug 2001 22:30:24 -0000 Received: from localhost ([127.0.0.1] helo=longsword.omniti.com ident=exim) by longsword.omniti.com with esmtp (Exim 3.22 #2) id 15cDqM-0003pE-00; Wed, 29 Aug 2001 18:29:54 -0400 Received: from [128.220.231.250] (helo=commedia.cnds.jhu.edu ident=exim) by longsword.omniti.com with esmtp (TLSv1:EDH-RSA-DES-CBC3-SHA:168) (Exim 3.22 #2) id 15cDqL-0003p7-00 for mls-users@lists.backhand.org; Wed, 29 Aug 2001 18:29:54 -0400 Received: from scout-6.cnds.jhu.edu ([128.220.221.226] helo=cnds.jhu.edu) by commedia.cnds.jhu.edu with asmtp (Exim 3.22 #8) id 15cDqL-0006O0-00 for mls-users@lists.backhand.org; Wed, 29 Aug 2001 18:29:53 -0400 Message-ID: <3B8D6EE9.13B18D63@cnds.jhu.edu> Date: Wed, 29 Aug 2001 18:38:33 -0400 From: Yair Amir Reply-To: yairamir@cnds.jhu.edu Organization: Johns Hopkins University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mls-users@lists.backhand.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [mls-users] Wackamole Release Announcement: N-Way Fail Over for IP addresses in a Cluster Sender: mls-users-admin@lists.backhand.org Errors-To: mls-users-admin@lists.backhand.org X-BeenThere: mls-users@lists.backhand.org X-Mailman-Version: 2.0beta2 Precedence: bulk List-Id: mod_log_spread -- users list Hi, We at the Center for Networking and Distributed Systems at Johns Hopkins University (http://www.cnds.jhu.edu) are happy to announce the release of Wackamole, a software tool that provides N-Way Fail Over for IP Addresses in a cluster. It is available here: http://www.backhand.org/wackamole/ and is released under the CNDS open source license http://www.backhand.org/wackamole/LICENSE.shtml which is essentially a version of BSD license with a somewhat stronger advertising requirement. Wackamole is a tool that helps with making a cluster highly available. It manages a bunch of virtual IPs that should be available to the outside world at all times. Wackamole ensures that exactly one machine within the cluster is listening on each virtual IP address that Wackamole manages. If it discovers that particular machines within the cluster are not alive, it will almost immediately ensure that other machines acquire the virtual IP addresses the down machines were managing. At no time will more than one connected machine be responsible for any virtual IP. Wackamole also works toward achieving a balanced distribution of the public IPs within the cluster it manages. How it works: Wackamole runs as root on each of the cluster's machines. It uses the membership notifications provided by the Spread Toolkit (http://www.spread.org, also available under a similar license) to generate a consistent state that is agreed upon among all of the connected Wackamole instances. Wackamole uses this knowledge to ensure that all of the public IP addresses served by the cluster will be covered by exactly one Wackamole instance. Wackamole is the newest component in the Backhand project (http://www.backhand.org), adding to its predecessors mod_backhand and mod_log_spread. For questions or comments - e-mail wackamole@backhand.org Best regards, :) Yair. http://www.cnds.jhu.edu _______________________________________________ mls-users mailing list mls-users@lists.backhand.org http://lists.backhand.org/mailman/listinfo/mls-users --E7i4zwmWs5DOuDSH-- --kjpMrWxdCilgNbo1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iEYEARECAAYFAjuNcecACgkQn09c7x7d+q1DhACdHdrMHFMKLky5UBAakxl7b+ta 2SsAn2d/9sFuoLoV2UHGzcXqAIBqs5TT =2dNF -----END PGP SIGNATURE----- --kjpMrWxdCilgNbo1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 4:14:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from excalibur.dotcom.fr (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 3F06A37B403 for ; Thu, 30 Aug 2001 04:14:19 -0700 (PDT) (envelope-from roman@IPricot.com) Received: from IPricot.com (pc181.fr.ipricot.com [192.168.31.181]) by excalibur.dotcom.fr (8.9.1/8.9.1) with ESMTP id LAA23120 for ; Thu, 30 Aug 2001 11:14:17 GMT X-To: Message-ID: <3B8E2008.7BB97D74@IPricot.com> Date: Thu, 30 Aug 2001 13:14:16 +0200 From: Roman Le Houelleur Organization: IPricot X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net Subject: kldunload not possible: why ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, Can someone tell me why it is not possible to kldunload some modules like if_sl or if_vlan ? Is it because these are old modules not yet fully compatible with the new kld facility or is there a technical restriction ? Actually I've tried to add the detach functionnality and it seems to work quite well... thanks, Roman. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 4:59: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6F86937B403; Thu, 30 Aug 2001 04:58:45 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7UBweU02805; Thu, 30 Aug 2001 14:58:40 +0300 (EEST) (envelope-from ru) Date: Thu, 30 Aug 2001 14:58:40 +0300 From: Ruslan Ermilov To: net@FreeBSD.org, security@FreeBSD.org Subject: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <20010830145840.A1554@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! The attached patch allows non-superuser to open, listen to, and send safe commands on the routing socket. Superuser privilege is required for all commands but RTM_GET. This has been in NetBSD and OpenBSD since 1997. This also allows us to drop setuid root privilege from the route(8) command. I would like to commit this patch on Monday if I hear no reasonable objections. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: sys/net/raw_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/net/raw_usrreq.c,v retrieving revision 1.19 diff -u -p -r1.19 raw_usrreq.c --- sys/net/raw_usrreq.c 2000/10/29 16:06:43 1.19 +++ sys/net/raw_usrreq.c 2001/08/30 11:53:09 @@ -153,12 +153,9 @@ static int raw_uattach(struct socket *so, int proto, struct proc *p) { struct rawcb *rp = sotorawcb(so); - int error; if (rp == 0) return EINVAL; - if (p && (error = suser(p)) != 0) - return error; return raw_attach(so, proto); } Index: sys/net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.55 diff -u -p -r1.55 rtsock.c --- sys/net/rtsock.c 2001/08/02 19:56:29 1.55 +++ sys/net/rtsock.c 2001/08/30 11:53:12 @@ -326,6 +326,14 @@ route_output(m, so) else senderr(ENOBUFS); } + + /* + * Verify that the caller has the appropriate privilege; RTM_GET + * is the only operation the non-superuser is allowed. + */ + if (rtm->rtm_type != RTM_GET && suser(curproc) != 0) + senderr(EACCES); + switch (rtm->rtm_type) { case RTM_ADD: Index: sbin/route/Makefile =================================================================== RCS file: /home/ncvs/src/sbin/route/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- sbin/route/Makefile 2001/03/26 14:33:22 1.13 +++ sbin/route/Makefile 2001/08/30 11:53:12 @@ -7,7 +7,6 @@ SRCS= route.c keywords.h CFLAGS+=-I. -Wall -DNS CFLAGS+=-DINET6 CLEANFILES+=keywords.h -BINMODE=4555 keywords.h: keywords sed -e '/^#/d' -e '/^$$/d' ${.CURDIR}/keywords > _keywords.tmp Index: sbin/route/route.c =================================================================== RCS file: /home/ncvs/src/sbin/route/route.c,v retrieving revision 1.55 diff -u -p -r1.55 route.c --- sbin/route/route.c 2001/08/20 14:53:05 1.55 +++ sbin/route/route.c 2001/08/30 11:53:23 @@ -100,13 +100,14 @@ union sockunion { } so_dst, so_gate, so_mask, so_genmask, so_ifa, so_ifp; typedef union sockunion *sup; -int pid, rtm_addrs, uid; +int pid, rtm_addrs; int s; int forcehost, forcenet, doflush, nflag, af, qflag, tflag, keyword(); int iflag, verbose, aflen = sizeof (struct sockaddr_in); int locking, lockrest, debugonly; struct rt_metrics rt_metrics; u_long rtm_inits; +uid_t uid; int atalk_aton __P((const char *, struct at_addr *)); char *atalk_ntoa __P((struct at_addr)); const char *routename(), *netname(); @@ -176,7 +177,6 @@ main(argc, argv) s = socket(PF_ROUTE, SOCK_RAW, 0); if (s < 0) err(EX_OSERR, "socket"); - setuid(uid); if (*argv) switch (keyword(*argv)) { case K_GET: --17pEHd4RhPHOinZp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 8:34: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 52C2B37B403; Thu, 30 Aug 2001 08:34:04 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7UFXYT64952; Thu, 30 Aug 2001 11:33:34 -0400 (EDT) (envelope-from wollman) Date: Thu, 30 Aug 2001 11:33:34 -0400 (EDT) From: Garrett Wollman Message-Id: <200108301533.f7UFXYT64952@khavrinen.lcs.mit.edu> To: Ruslan Ermilov Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Proposed change to route(4) sockets to make them available to non-superuser In-Reply-To: <20010830145840.A1554@sunbay.com> References: <20010830145840.A1554@sunbay.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > raw_uattach(struct socket *so, int proto, struct proc *p) > { > struct rawcb *rp = sotorawcb(so); > - int error; > if (rp == 0) > return EINVAL; > - if (p && (error = suser(p)) != 0) > - return error; > return raw_attach(so, proto); > } This allows *anyone* to open any raw socket. This change should not be made; use a specialized route_uattach instead. > + if (rtm->rtm_type != RTM_GET && suser(curproc) != 0) Ick. I worked hard several years ago to get rid of all references to `curproc' in the network stack; I'm none too pleased to see them coming back. Since we already save the credentials of the process which opened the socket, we should do the access-control on the basis of those credentials, not on the basis of the process that happens to be running. (Consider, for example, a daemon which opens its sockets and then changes credentials for safety.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 8:59: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id CEDA437B403; Thu, 30 Aug 2001 08:58:57 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Q5PY2J2J; Thu, 30 Aug 2001 19:48:27 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f7UFw0623395; Thu, 30 Aug 2001 19:58:00 +0400 (MSD) (envelope-from yar) Date: Thu, 30 Aug 2001 19:58:00 +0400 From: Yar Tikhiy To: Archie Cobbs Cc: Mike Tancsa , stable@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: kernel panic when bringing up a VLAN interface (netgraph?) Message-ID: <20010830195759.A21176@comp.chem.msu.su> References: <20010829214910.A204@comp.chem.msu.su> <200108292247.f7TMl6i40209@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108292247.f7TMl6i40209@arch20m.dellroad.org>; from archie@dellroad.org on Wed, Aug 29, 2001 at 03:47:06PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [adding -net to the Cc: list] On Wed, Aug 29, 2001 at 03:47:06PM -0700, Archie Cobbs wrote: > Yar Tikhiy writes: > > Why does gdb report the values of "ifp" and "mp" inconsistently? > > The kernel crashed at the first line of ng_ether_output(), so > > the arguments couldn't be modified... I'm confused. > > Optimization.. it's probably reusing the same variable/register for > both 'ifp' and 'node'. So 'node' is NULL, which indicates that > ether_ifattach() was probably never called on this interface. Yes it was. As I've just traced, it's ng_ether_mod_event() that is responsible for the panic. When ng_ether is being loaded as a module, or just initialized as a part of a kernel, it attaches all existing ethernet interfaces to netgraph using ng_ether_attach(). However, the vlan interface has a different type, IFT_L2VLAN, so it won't get attached to netgraph properly. On the other hand, vlan can't attach to netgraph by itself because its init function is usually called earlier that that of ng_ether. Peter Block on -net reported that he had avoided the panic by fiddling with initialization order. However, that was a hack, not a solution. I'd suggest the following fix. Not sure if it should be pushed into the upcoming 4.4-RELEASE... Index: ng_ether.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v retrieving revision 1.18 diff -u -r1.18 ng_ether.c --- ng_ether.c 2001/01/30 20:51:52 1.18 +++ ng_ether.c 2001/08/30 15:33:24 @@ -798,7 +798,8 @@ /* Create nodes for any already-existing Ethernet interfaces */ TAILQ_FOREACH(ifp, &ifnet, if_link) { - if (ifp->if_type == IFT_ETHER) + if (ifp->if_type == IFT_ETHER || + ifp->if_type == IFT_L2VLAN) ng_ether_attach(ifp); } break; -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 9:13:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from reservoir.absolight.com (reservoir.absolight.com [212.43.217.72]) by hub.freebsd.org (Postfix) with ESMTP id 96D7437B403 for ; Thu, 30 Aug 2001 09:13:17 -0700 (PDT) (envelope-from arn_mat@club-internet.fr) Received: from bilbo.in.mat.cc (bilbo.in.mat.cc [212.43.217.121]) by reservoir.absolight.com (Postfix) with ESMTP id CEA9BD39CB for ; Thu, 30 Aug 2001 18:12:12 +0200 (CEST) Received: from club-internet.fr (sauron.in.mat.cc [212.43.217.122]) by bilbo.in.mat.cc (Postfix) with ESMTP id F37B633524 for ; Thu, 30 Aug 2001 18:12:07 +0200 (CEST) Message-ID: <3B8E65D7.EE5DE38B@club-internet.fr> Date: Thu, 30 Aug 2001 18:12:07 +0200 From: Mathieu Arnold Organization: http://www.absolight.com/ X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: ipfilter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I'm having some problems with ipfilter : # ipfstat -s IP states added: 4572145 TCP 573649 UDP 463188 ICMP 1165608186 hits 34257625 misses 0 maximum 1546129 no memory 8208 bkts in use 22215 active 959216 expired 3081422 closed # uptime 6:10PM up 1 day, 7:24, 2 users, load averages: 0.08, 0.12, 0.27 # uname -r 4.3-RELEASE-p14 as you can see, the no memory should stay at 0, but here, it's far from good. do you have some ideas... btw, here are some things i've modified... in /usr/src/sys/netinet/ip_state.c : #define FIVE_DAYS (2*2*3600) /* 5 days: half closed session */ in /usr/src/sys/netinet/ip_state.h : #define IPSTATE_SIZE 1613321 #define IPSTATE_MAX 1048576 /* Maximum number of states held */ any clue ? -- Mathieu Arnold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 10: 6:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 5147637B403 for ; Thu, 30 Aug 2001 10:06:09 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f7UH5L721375; Thu, 30 Aug 2001 10:05:21 -0700 Date: Thu, 30 Aug 2001 10:05:21 -0700 From: Brooks Davis To: Roman Le Houelleur Cc: freebsd-net Subject: Re: kldunload not possible: why ? Message-ID: <20010830100521.A16896@Odin.AC.HMC.Edu> References: <3B8E2008.7BB97D74@IPricot.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B8E2008.7BB97D74@IPricot.com>; from roman@IPricot.com on Thu, Aug 30, 2001 at 01:14:16PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 30, 2001 at 01:14:16PM +0200, Roman Le Houelleur wrote: > Can someone tell me why it is not possible to kldunload > some modules like if_sl or if_vlan ? > Is it because these are old modules not yet fully compatible > with the new kld facility or is there a technical restriction ? Yup, many modules were converted without unload functions. I've got patches I need to commit for vlan. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7jnJQXY6L6fI4GtQRAndsAJ4zP+aphPnzT9PB23LEtTqjwYUWagCgmXcP S6DV7W1XOEEQS+/VLn/b+6A= =BpcU -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 10:43: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id BCEEC37B403; Thu, 30 Aug 2001 10:42:52 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f7UHfWs48175; Thu, 30 Aug 2001 20:41:32 +0300 (EEST) (envelope-from ru) Date: Thu, 30 Aug 2001 20:41:32 +0300 From: Ruslan Ermilov To: Garrett Wollman Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser Message-ID: <20010830204132.A47482@sunbay.com> References: <20010830145840.A1554@sunbay.com> <200108301533.f7UFXYT64952@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108301533.f7UFXYT64952@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Aug 30, 2001 at 11:33:34AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Aug 30, 2001 at 11:33:34AM -0400, Garrett Wollman wrote: > < said: > > > raw_uattach(struct socket *so, int proto, struct proc *p) > > { > > struct rawcb *rp = sotorawcb(so); > > - int error; > > > if (rp == 0) > > return EINVAL; > > - if (p && (error = suser(p)) != 0) > > - return error; > > return raw_attach(so, proto); > > } > > This allows *anyone* to open any raw socket. This change should not > be made; use a specialized route_uattach instead. > Not any, as almost all domains don't use raw_usrreqs, but you are of course right. At least PF_KEY_V2 raw sockets were affected. > > + if (rtm->rtm_type != RTM_GET && suser(curproc) != 0) > > Ick. I worked hard several years ago to get rid of all references to > `curproc' in the network stack; I'm none too pleased to see them > coming back. Since we already save the credentials of the process > which opened the socket, we should do the access-control on the basis > of those credentials, not on the basis of the process that happens to > be running. (Consider, for example, a daemon which opens its sockets > and then changes credentials for safety.) > How about this one (kernel part only)? Index: rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.55 diff -u -p -r1.55 rtsock.c --- rtsock.c 2001/08/02 19:56:29 1.55 +++ rtsock.c 2001/08/30 17:37:56 @@ -123,7 +123,7 @@ rts_attach(struct socket *so, int proto, */ s = splnet(); so->so_pcb = (caddr_t)rp; - error = raw_usrreqs.pru_attach(so, proto, p); + error = raw_attach(so, proto); rp = sotorawcb(so); if (error) { splx(s); @@ -326,6 +326,14 @@ route_output(m, so) else senderr(ENOBUFS); } + + /* + * Verify that the caller has the appropriate privilege; RTM_GET + * is the only operation the non-superuser is allowed. + */ + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0) + senderr(EACCES); + switch (rtm->rtm_type) { case RTM_ADD: Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 11:21:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id AAA0B37B401; Thu, 30 Aug 2001 11:21:35 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7UIKGZ66585; Thu, 30 Aug 2001 14:20:16 -0400 (EDT) (envelope-from wollman) Date: Thu, 30 Aug 2001 14:20:16 -0400 (EDT) From: Garrett Wollman Message-Id: <200108301820.f7UIKGZ66585@khavrinen.lcs.mit.edu> To: Ruslan Ermilov Cc: net@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Proposed change to route(4) sockets to make them available to non-superuser In-Reply-To: <20010830204132.A47482@sunbay.com> References: <20010830145840.A1554@sunbay.com> <200108301533.f7UFXYT64952@khavrinen.lcs.mit.edu> <20010830204132.A47482@sunbay.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0) > + senderr(EACCES); I'm certain rwatson would object to this. suser_xxx() allows checking on the basis of credentials rather than a process, so that's what should be used. In any case, the correct error is EPERM, not EACCES. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 12:17:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 2271C37B407; Thu, 30 Aug 2001 12:17:04 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA75759; Thu, 30 Aug 2001 12:05:49 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f7UJ5m043601; Thu, 30 Aug 2001 12:05:48 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200108301905.f7UJ5m043601@arch20m.dellroad.org> Subject: Re: kernel panic when bringing up a VLAN interface (netgraph?) In-Reply-To: <20010830195759.A21176@comp.chem.msu.su> "from Yar Tikhiy at Aug 30, 2001 07:58:00 pm" To: Yar Tikhiy Date: Thu, 30 Aug 2001 12:05:48 -0700 (PDT) Cc: Archie Cobbs , Mike Tancsa , stable@FreeBSD.ORG, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yar Tikhiy writes: > I'd suggest the following fix. Not sure if it should be pushed > into the upcoming 4.4-RELEASE... > > Index: ng_ether.c > =================================================================== > RCS file: /home/ncvs/src/sys/netgraph/ng_ether.c,v > retrieving revision 1.18 > diff -u -r1.18 ng_ether.c > --- ng_ether.c 2001/01/30 20:51:52 1.18 > +++ ng_ether.c 2001/08/30 15:33:24 > @@ -798,7 +798,8 @@ > > /* Create nodes for any already-existing Ethernet interfaces */ > TAILQ_FOREACH(ifp, &ifnet, if_link) { > - if (ifp->if_type == IFT_ETHER) > + if (ifp->if_type == IFT_ETHER || > + ifp->if_type == IFT_L2VLAN) > ng_ether_attach(ifp); > } > break; Yes, this is the correct fix .. nice and simple :-) Definitely a MFC candidate. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 30 17:17:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 3D87637B401 for ; Thu, 30 Aug 2001 17:17:33 -0700 (PDT) (envelope-from hansc@datamatrix.com) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12]) by Awfulhak.org (8.11.5/8.11.5) with ESMTP id f7V0D2A74095 for ; Fri, 31 Aug 2001 01:13:02 +0100 (BST) (envelope-from hansc@datamatrix.com) Received: (from root@localhost) by hak.lan.Awfulhak.org (8.11.6/8.11.6) id f7V0CpN20651 for freebsd-net@freebsd.org; Fri, 31 Aug 2001 01:12:51 +0100 (BST) (envelope-from hansc@datamatrix.com) Date: Fri, 31 Aug 2001 01:12:51 +0100 (BST) From: hansc@datamatrix.com Message-Id: <200108310012.f7V0CpN20651@hak.lan.Awfulhak.org> To: freebsd-net@freebsd.org Subject: slow ftp transfers forward from hans christensen Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have recently redefined a problem which has been plaguing me for close to a year now. I have several FBSD boxes at a site fed by a Sprint T1 (Site A). Each of these boxes is capable of ftp'ing to each other on the same subnet at speeds approaching the limits of the disk subsystem. In short, transfers on the LAN between FBSD boxen appear to be fine. In addition, I have enlisted the help of the folks at sprint to ftp in and out of these boxes with speeds approaching the limits of the T1 line - no problem there. It should be noted that the sprint guys have done their transfers from within sprint's network and are therefore NOT crossing their own network access points. Here is where it gets weird. If I ftp into one of my boxes at Site A across the WAN (in this case from a colocation facility) and put a large file onto my server in Site A, I get speeds of about 10KB/s. This may fluctuate from 4KB/s to 16KB/s, but it far below what one would normally see across a T1 line. Interestingly enough, sending ftp traffic out of Site A seems to move five to ten time faster - not perfect, but workable. Below are example of the same file transferred first out of Site A to the colocation facility, and then the same file just transferred, back into Site A. You will note the difference in speeds... This colocation facility is NOT on the same network as sprint and therefore DOES have to cross one of Sprint's network access points. Furthermore, to rule out the possibility that the colo facility is to blame, I ftp'ed from a linux box on yet another ISP's network. This linux box had the same type of performance problems. Slow puts to Site A and reasonable gets from Site A. I have seen this before as well, between boxes at the colocation facility and again across different class c subnets. Sprint claims that the problem lies with the MTU settings of the boxes at the "linux side" and the "colo side." This smells wrong to me, but I confess that I don't really know that it is wrong. I have looked in the FBSD bug reports for any indication of a similar problem and do not see any so far, but I have seen several questions on the mailing list archives. Most of these are dismissed as improper configuration of ethernet cards. I have tried these suggestions but found no relief. I ftp close to a GB of info every night into Site A and I need it to go faster than it has been going, but I'm stumped. Anybody got any clues for the clueless? Hans Christensen hansc@datamatrix.com Remote system type is UNIX. Using binary mode to transfer files. ftp> put jdk-1_2_2_006-win.exe local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe 227 Entering Passive Mode (************). 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe 100% |*************************************************************************** ***************************| 298 KB 00:00 ETA 226 Transfer complete. 305152 bytes sent in 3.66 seconds (81.33 KB/s) ftp> get jdk-1_2_2_006-win.exe local: jdk-1_2_2_006-win.exe remote: jdk-1_2_2_006-win.exe 227 Entering Passive Mode (*************). 150 Opening BINARY mode data connection for jdk-1_2_2_006-win.exe (305152 bytes). 100% |*************************************************************************** ***************************| 298 KB 00:00 ETA 226 Transfer complete. 305152 bytes received in 25.77 seconds (11.56 KB/s) ftp> Here is a dmesg: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-STABLE #0: Fri Jun 1 06:59:28 PDT 2001 Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 201261056 (196544K bytes) avail memory = 192282624 (187776K bytes) Preloaded elf kernel "kernel" at 0xc035e000. VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc02fd882 (1000022) VESA: ATI MACH64 Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 chip1: port 0x5000-0x500f at device 7.3 on pci0 fxp0: port 0xe400-0xe43f mem 0xeb000000-0xeb0fffff,0xeb202000-0xeb202fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 00:90:27:9a:47:1e inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xe800-0xe83f mem 0xeb100000-0xeb1fffff,0xeb200000-0xeb200fff irq 5 at device 10.0 on pci0 fxp1: Ethernet address 00:90:27:9a:47:10 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: port 0xec00-0xecff mem 0xeb201000-0xeb201fff irq 11 at device 12.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: failed to get data. psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, logging disabled ad0: 9787MB [19885/16/63] at ata0-master UDMA33 ad2: 19546MB [39714/16/63] at ata1-master UDMA33 acd0: CD-RW at ata0-slave using PIO4 Waiting 5 seconds for SCSI devices to settle no devsw da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 105010MB (215061120 512 byte sectors: 255H 63S/T 13386C) (majdev=0 bootdev=0xa0200000) Mounting root from ufs:/dev/ad0s1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 4:25:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from rios.sitaranetworks.com (rios.sitaranetworks.com [199.103.141.78]) by hub.freebsd.org (Postfix) with ESMTP id BFF8E37B405 for ; Fri, 31 Aug 2001 04:25:12 -0700 (PDT) Received: by rios.sitaranetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 06:38:36 -0400 Message-ID: <31269226357BD211979E00A0C9866DABE412ED@rios.sitaranetworks.com> From: Charles Richmond To: "'oberman@es.net'" , "'net@FreeBSD.ORG'" Subject: RE: Gig-E performance with FreeBSD Date: Fri, 31 Aug 2001 06:38:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am the manager of the kernel group at Sitara Networks and we have tested both Netgear and Intel GigE cards. The Tigon based Netgear card is not as good as the Intel 543 based card. The Tigon chip maxes out at 200k packets/second. The Intel 543 does better by about 30%. Charles Richmond ----Original Message----- >From: "Kevin Oberman" >To: "net@FreeBSD.ORG" >Cc: >Bcc: >Subj: Gig-E performance with FreeBSD >Type: IPM.Note >Sent: Wednesday, August 29, 2001 4:12 PM > >Has anyone done any performance testing of Gig-E cards on FreeBSD? I >need to run them with some high performance apps and I'm wondering what >sort of performance people have been able to get, assuming large >windows (up to 8 MB), with and without jumbo frames. > >Does anyone have any experience in this area? > >Thanks, > >R. Kevin Oberman, Network Engineer >Energy Sciences Network (ESnet) >Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) >E-mail: oberman@es.net Phone: +1 510 486-8634 > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 6:26:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id 1159037B406 for ; Fri, 31 Aug 2001 06:26:40 -0700 (PDT) Received: from xena.gsicomp.on.ca ([64.228.155.124]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010831132638.XFLC10424.tomts5-srv.bellnexxia.net@xena.gsicomp.on.ca> for ; Fri, 31 Aug 2001 09:26:38 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f7VDJru00560 for ; Fri, 31 Aug 2001 09:19:53 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <003201c1321f$71de65e0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: Subject: Help with IPSec VPN Date: Fri, 31 Aug 2001 09:18:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I've been trying to get an IPSec tunneling VPN between two boxes working without much success. I've read the FAQs and HOWTOs on www.freebsd.org, www.freebsddiary.org, www.daemonnews.org and www.kame.net and they all have helped me get closer to where I want to be, but I'm still missing something. The exact problem that I'm running into is that once I've got everything configured (all details below), when I try and ping the other end of the tunnel, nothing happens. I get this from 'netstat -p ipsec', with every other ipsec counter showing a value of 0. 8 outbound packets with no SA available Both boxes are running RELENG_4_3 (security release), and have 'options IPSEC' and 'options IPSEC_ESP' in the kernel. Box A is 192.168.0.2/24, Box B is 192.168.0.3/24. Here's what I'm doing on box A: gabby# gifconfig gif0 192.168.0.2 192.168.0.3 gabby# ifconfig gif0 inet 10.0.2.1 10.0.3.1 netmask 255.255.255.0 gabby# setkey -F gabby# setkey -FP gabby# setkey -c << EOF add 10.0.2.1 10.0.3.1 esp 1000 -E 3des-cbc "goofgoofgoofgoofgoofgoof"; add 10.0.3.1 10.0.2.1 esp 1001 -E 3des-cbc "foolfoolfoolfoolfoolfool"; spdadd 10.0.2.0/24 10.0.3.0/24 any -P out ipsec esp/tunnel/192.168.0.2-192.168.0.3/require; spdadd 10.0.3.0/24 10.0.2.0/24 any -P in ipsec esp/tunnel/192.168.0.3-192.168.0.2/require; EOF gabby# route add -net 10.0.3.0/24 10.0.3.1 gabby# I'm doing the exact same thing on Box B, except that all the IP pairs are reversed, with the exception of the 'add' lines for setkey (as outlined in the KAME IpSec FAQ, VPN tunnel section.) and the route statement. Here's output from gifconfig, ifconfig, netstat, and setkey (slightly trimmed): gabby# gifconfig -a gif0 gif0: flags=8011 mtu 1280 inet6 fe80::200:c0ff:fef2:7c40%gif0 --> :: prefixlen 64 inet 10.0.2.1 --> 10.0.3.1 netmask 0xffffff00 physical address inet 192.168.0.2 --> 192.168.0.3 gabby# ifconfig gif0 gif0: flags=8011 mtu 1280 inet6 fe80::200:c0ff:fef2:7c40%gif0 --> :: prefixlen 64 scopeid 0x4 inet 10.0.2.1 --> 10.0.3.1 netmask 0xffffff00 gabby# netstat -rn -f inet Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 1 0 ed0 10.0.3/24 10.0.3.1 UGSc 0 0 gif0 10.0.3.1 10.0.2.1 UH 1 8 gif0 127.0.0.1 127.0.0.1 UH 1 92 lo0 192.168 link#1 UC 0 0 ed0 => gabby# setkey -D 10.0.3.1 10.0.2.1 esp mode=any spi=1001(0x000003e9) reqid=0(0x00000000) E: 3des-cbc 666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c 666f6f6c replay=0 flags=0x00000040 state=mature seq=1 pid=403 created: Aug 31 08:39:59 2001 current: Aug 31 09:11:49 2001 diff: 1910(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 refcnt=1 10.0.2.1 10.0.3.1 esp mode=any spi=1000(0x000003e8) reqid=0(0x00000000) E: 3des-cbc 676f6f66 676f6f66 676f6f66 676f6f66 676f6f66 676f6f66 replay=0 flags=0x00000040 state=mature seq=0 pid=403 created: Aug 31 08:39:59 2001 current: Aug 31 09:11:49 2001 diff: 1910(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 refcnt=1 gabby# setkey -DP 10.0.3.0/24[any] 10.0.2.0/24[any] any in ipsec esp/tunnel/192.168.0.3-192.168.0.2/require spid=4 seq=1 pid=404 refcnt=1 10.0.2.0/24[any] 10.0.3.0/24[any] any out ipsec esp/tunnel/192.168.0.2-192.168.0.3/require spid=3 seq=0 pid=404 refcnt=1 -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 8:58:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from owa-sj-1.digisle.com (owa-sj-1.digisle.com [167.216.153.124]) by hub.freebsd.org (Postfix) with ESMTP id B0CC737B401; Fri, 31 Aug 2001 08:56:34 -0700 (PDT) Received: from VWALL-SJ-1.digisle.com ([167.216.153.118]) by owa-sj-1.digisle.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 31 Aug 2001 08:57:36 -0700 Received: from 206.220.227.145 by VWALL-SJ-1.digisle.com (InterScan E-Mail VirusWall NT); Fri, 31 Aug 2001 16:56:43 +0100 Message-ID: <3B8FB3AD.4A3F20D1@digisle.net> Date: Fri, 31 Aug 2001 08:56:29 -0700 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis , freebsd-current@freebsd.org, freebsd-net@freebsd.org, Vladimir Silyaev , Nick Sayer Subject: PATCH: if_tap device cloning (final) References: <3B8EB490.6875087F@digisle.net> <20010830151026.B18097@Odin.AC.HMC.Edu> <3B8EBC8A.43DFFCD7@digisle.net> <20010830154127.A22437@Odin.AC.HMC.Edu> <3B8ECAA0.2A41AE04@digisle.net> <20010830165150.B27635@Odin.AC.HMC.Edu> <3B8EE1F8.3426B811@digisle.net> <20010830182256.A10150@Odin.AC.HMC.Edu> Content-Type: multipart/mixed; boundary="------------A09F7670A8BACD9104B3E55E" X-OriginalArrivalTime: 31 Aug 2001 15:57:36.0056 (UTC) FILETIME=[A70FA380:01C13235] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------A09F7670A8BACD9104B3E55E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hackers, Attached some patches that implements device cloning (with devfs(5) support) for tap(4). The implementation is based on resource manager (see tun(4) and gif(4)). Brooks Davis (brooks@one-eyed-alien.net) took a quick look at the patch and seems has no objection. Please review, test and if there is no objection Brooks Davis will commit it. If there are any problems, please let me know. thanks, max p.s. i'm not on freebsd-net list, so please reply directly p.p.s. Brooks Davis wrote: [...] > Looks good. If could post a copy to freebsd-net and give it another > 24hrs or so for other responses, I'll commit it if nothing else comes > up. --------------A09F7670A8BACD9104B3E55E Content-Type: text/plain; charset=us-ascii; name="if_tap.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_tap.diff" diff -ru /usr/src/share/man/man4/tap.4 ./src/share/man/man4/tap.4 --- /usr/src/share/man/man4/tap.4 Thu Aug 30 14:23:44 2001 +++ ./src/share/man/man4/tap.4 Thu Aug 30 15:14:40 2001 @@ -1,4 +1,4 @@ -.\" $FreeBSD: src/share/man/man4/tap.4,v 1.8 2001/08/07 15:48:39 ru Exp $ +.\" $FreeBSD: src/share/man/man4/tap.4,v 1.7 2001/05/01 09:15:13 schweikh Exp $ .\" Based on PR#2411 .\" .Dd July 9, 2000 @@ -36,11 +36,50 @@ interface. .Pp The network interfaces are named -.Sy tap Ns Ar 0 , -.Sy tap Ns Ar 1 , -etc, as many as were made by -.Xr MAKEDEV 8 . -Each one supports the usual Ethernet network-interface +.Dq Li tap0 , +.Dq Li tap1 , +etc., one for each control device that has been opened. +These Ethernet network interfaces persist until +.Pa if_tap.ko +module is unloaded (if +.Nm +is built into your kernel, the network interfaces can not be removed). +.Pp +On older systems without +.Xr devfs 5 +support, +.Xr MAKEDEV 8 +should be used to create the initial control devices and the task +of locating an unused device is left up to the opener (a +.Nm +device is usually obtained by attempting to open +.Pa /dev/tap0 , +and if that fails +.Pa /dev/tap1 +etc., until an +.Va errno +of +.Er EBUSY +is not received). +.Pp +On systems with +.Xr devfs 5 +support, +.Nm +permits opens on the special control device +.Pa /dev/tap . +When this device is opened, +.Nm +will return a handle for the lowest unused +.Nm +device (use +.Xr devname 3 +to determine which). +Control devices (once successfully opened) persist until +.Pa if_tap.ko +is unloaded in the same way that network interfaces persist (see above). +.Pp +Each interface supports the usual Ethernet network interface .Xr ioctl 2 Ns s , such as .Dv SIOCSIFADDR @@ -56,7 +95,7 @@ there); writing an Ethernet frame to the control device generates an input frame on the network interface, as if the -(non-existent) +.Pq non-existent hardware had just received it. .Pp The Ethernet tunnel device, normally @@ -91,15 +130,14 @@ .Fn write . Writes will not block; if the frame cannot be accepted for a transient reason -(e.g., no buffer space available), +.Pq e.g., no buffer space available , it is silently dropped; if the reason is not transient -(e.g., frame too large), +.Pq e.g., frame too large , an error is returned. The following .Xr ioctl 2 calls are supported -(defined in -.Aq Pa net/if_tap.h ) : +.Pq defined in Aq Pa net/if_tap.h Ns : .Bl -tag -width VMIO_SIOCSETMACADDR .It Dv TAPSDEBUG The argument should be a pointer to an @@ -115,7 +153,7 @@ Turn non-blocking I/O for reads off or on, according as the argument .Va int Ns 's value is or isn't zero -(Writes are always nonblocking). +.Pq Writes are always nonblocking . .It Dv FIOASYNC Turn asynchronous I/O for reads (i.e., generation of @@ -172,8 +210,7 @@ .Dq remote side. This command is used by VMware port and expected to be executed on a descriptor, associated with control device -(usually -.Pa /dev/vmnet Ns Sy N ) . +.Pq usually Pa /dev/vmnet Ns Sy N . .El .Pp The control device also supports @@ -199,7 +236,7 @@ and .Nm vmnet devices. VMnet minor numbers begin at -.Va 0x10000 +.Va 0x800000 + .Va N . Where diff -ru /usr/src/sys/net/if_tap.c ./src/sys/net/if_tap.c --- /usr/src/sys/net/if_tap.c Mon Mar 26 04:41:17 2001 +++ ./src/sys/net/if_tap.c Thu Aug 30 17:51:00 2001 @@ -54,6 +54,9 @@ #include #include #include +#include /* XXX: Shouldn't really be required! */ +#include +#include #include #include @@ -73,7 +76,9 @@ #define TAP "tap" #define VMNET "vmnet" -#define VMNET_DEV_MASK 0x00010000 +#define TAPMAXUNIT 0x7fff +#define VMNET_DEV_MASK 0x00800000 + /* 0x007f00ff */ /* module */ static int tapmodevent __P((module_t, int, void *)); @@ -111,9 +116,12 @@ /* flags */ 0, }; -static int taprefcnt = 0; /* module ref. counter */ -static int taplastunit = -1; /* max. open unit number */ -static int tapdebug = 0; /* debug flag */ +static int tapdebug = 0; /* debug flag */ +static SLIST_HEAD(, tap_softc) taphead; /* first device */ +static udev_t tapbasedev = NOUDEV; /* base device */ +static struct rman tapdevunits[2]; /* device units */ +#define tapunits tapdevunits +#define vmnetunits (tapdevunits + 1) MALLOC_DECLARE(M_TAP); MALLOC_DEFINE(M_TAP, CDEV_NAME, "Ethernet tunnel interface"); @@ -131,61 +139,100 @@ int type; void *data; { - static int attached = 0; - static eventhandler_tag eh_tag = NULL; + static eventhandler_tag eh_tag = NULL; + struct tap_softc *tp = NULL; + struct ifnet *ifp = NULL; + int error, s; switch (type) { case MOD_LOAD: - if (attached) - return (EEXIST); + /* initialize resources */ + tapunits->rm_type = RMAN_ARRAY; + tapunits->rm_descr = "open tap units"; + vmnetunits->rm_type = RMAN_ARRAY; + vmnetunits->rm_descr = "open vmnet units"; + + error = rman_init(tapunits); + if (error != 0) + goto bail; + + error = rman_init(vmnetunits); + if (error != 0) + goto bail1; + + error = rman_manage_region(tapunits, 0, TAPMAXUNIT); + if (error != 0) + goto bail2; + + error = rman_manage_region(vmnetunits, 0, TAPMAXUNIT); + if (error != 0) + goto bail2; + + /* intitialize device */ + + SLIST_INIT(&taphead); eh_tag = EVENTHANDLER_REGISTER(dev_clone, tapclone, 0, 1000); - cdevsw_add(&tap_cdevsw); - attached = 1; - break; + if (eh_tag == NULL) { + error = ENOMEM; + goto bail2; + } - case MOD_UNLOAD: { - int unit; + if (!devfs_present) { + error = cdevsw_add(&tap_cdevsw); + if (error != 0) { + EVENTHANDLER_DEREGISTER(dev_clone, eh_tag); + goto bail2; + } + } + + return (0); +bail2: + rman_fini(vmnetunits); +bail1: + rman_fini(tapunits); +bail: + return (error); - if (taprefcnt > 0) - return (EBUSY); + case MOD_UNLOAD: + SLIST_FOREACH(tp, &taphead, tap_next) + if (tp->tap_unit != NULL) + return (EBUSY); EVENTHANDLER_DEREGISTER(dev_clone, eh_tag); - cdevsw_remove(&tap_cdevsw); - unit = 0; - while (unit <= taplastunit) { - int s; - struct ifnet *ifp = NULL; + error = rman_fini(tapunits); + KASSERT((error == 0), ("Could not fini tap units")); + error = rman_fini(vmnetunits); + KASSERT((error == 0), ("Could not fini vmnet units")); + + while ((tp = SLIST_FIRST(&taphead)) != NULL) { + SLIST_REMOVE_HEAD(&taphead, tap_next); + + ifp = &tp->tap_if; + + TAPDEBUG("detaching %s%d\n", ifp->if_name,ifp->if_unit); + + KASSERT(!(tp->tap_flags & TAP_OPEN), + ("%s%d flags is out of sync", ifp->if_name, + ifp->if_unit)); + + /* XXX makedev check? nah.. not right now :) */ s = splimp(); - TAILQ_FOREACH(ifp, &ifnet, if_link) - if ((strcmp(ifp->if_name, TAP) == 0) || - (strcmp(ifp->if_name, VMNET) == 0)) - if (ifp->if_unit == unit) - break; + ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); splx(s); - if (ifp != NULL) { - struct tap_softc *tp = ifp->if_softc; - - TAPDEBUG("detaching %s%d. minor = %#x, " \ - "taplastunit = %d\n", - ifp->if_name, unit, minor(tp->tap_dev), - taplastunit); - - s = splimp(); - ether_ifdetach(ifp, 1); - splx(s); - destroy_dev(tp->tap_dev); - FREE(tp, M_TAP); - } - else - unit ++; + FREE(tp, M_TAP); } - attached = 0; - } break; + if (tapbasedev != NOUDEV) + destroy_dev(udev2dev(tapbasedev, 0)); + + if (!devfs_present) + cdevsw_remove(&tap_cdevsw); + + break; default: return (EOPNOTSUPP); @@ -207,26 +254,66 @@ int namelen; dev_t *dev; { - int unit, minor; - char *device_name = NULL; + int unit, minor = 0 /* XXX avoid warning */ , error; + char *device_name = name; + struct resource *r = NULL; if (*dev != NODEV) return; - device_name = TAP; - if (dev_stdclone(name, NULL, device_name, &unit) != 1) { - device_name = VMNET; + if (strcmp(device_name, TAP) == 0) { + /* get first free tap unit */ + r = rman_reserve_resource(tapunits, 0, TAPMAXUNIT, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + unit = rman_get_start(r); + minor = unit2minor(unit); + } + else if (strcmp(device_name, VMNET) == 0) { + /* get first free vmnet unit */ + r = rman_reserve_resource(vmnetunits, 0, TAPMAXUNIT, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + unit = rman_get_start(r); + minor = unit2minor(unit) | VMNET_DEV_MASK; + } + + if (r != NULL) { /* need cloning */ + TAPDEBUG("%s%d is available. minor = %#x\n", + device_name, unit, minor); + + error = rman_release_resource(r); + KASSERT((error == 0), ("Could not release tap/vmnet unit")); + + /* check if device for the unit has been created */ + *dev = makedev(CDEV_MAJOR, minor); + if ((*dev)->si_flags & SI_NAMED) { + TAPDEBUG("%s%d device exists. minor = %#x\n", + device_name, unit, minor); + return; /* device has been created */ + } + } else { /* try to match name/unit, first try tap then vmnet */ + device_name = TAP; + if (dev_stdclone(name, NULL, device_name, &unit) != 1) { + device_name = VMNET; - if (dev_stdclone(name, NULL, device_name, &unit) != 1) - return; + if (dev_stdclone(name, NULL, device_name, &unit) != 1) + return; - minor = unit2minor(unit | VMNET_DEV_MASK); + minor = unit2minor(unit) | VMNET_DEV_MASK; + } else + minor = unit2minor(unit); } - else - minor = unit2minor(unit); + + TAPDEBUG("make_dev(%s%d). minor = %#x\n", device_name, unit, minor); *dev = make_dev(&tap_cdevsw, minor, UID_ROOT, GID_WHEEL, 0600, "%s%d", device_name, unit); + + if (tapbasedev == NOUDEV) + tapbasedev = (*dev)->si_udev; + else { + (*dev)->si_flags |= SI_CHEAPCLONE; + dev_depends(udev2dev(tapbasedev, 0), *dev); + } } /* tapclone */ @@ -247,21 +334,22 @@ /* allocate driver storage and create device */ MALLOC(tp, struct tap_softc *, sizeof(*tp), M_TAP, M_WAITOK | M_ZERO); + SLIST_INSERT_HEAD(&taphead, tp, tap_next); + + unit = dev2unit(dev) & TAPMAXUNIT; /* select device: tap or vmnet */ if (minor(dev) & VMNET_DEV_MASK) { name = VMNET; - unit = dev2unit(dev) & 0xff; tp->tap_flags |= TAP_VMNET; - } - else { + } else name = TAP; - unit = dev2unit(dev); - } - tp->tap_dev = make_dev(&tap_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, + TAPDEBUG("tapcreate(%s%d). minor = %#x\n", name, unit, minor(dev)); + + if (!(dev->si_flags & SI_NAMED)) + dev = make_dev(&tap_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, "%s%d", name, unit); - tp->tap_dev->si_drv1 = dev->si_drv1 = tp; /* generate fake MAC address: 00 bd xx xx xx unit_no */ macaddr_hi = htons(0x00bd); @@ -272,11 +360,7 @@ /* fill the rest and attach interface */ ifp = &tp->tap_if; ifp->if_softc = tp; - ifp->if_unit = unit; - if (unit > taplastunit) - taplastunit = unit; - ifp->if_name = name; ifp->if_init = tapifinit; ifp->if_output = ether_output; @@ -286,14 +370,16 @@ ifp->if_flags = (IFF_BROADCAST|IFF_SIMPLEX|IFF_MULTICAST); ifp->if_snd.ifq_maxlen = ifqmaxlen; + dev->si_drv1 = tp; + s = splimp(); - ether_ifattach(ifp, 1); + ether_ifattach(ifp, ETHER_BPF_SUPPORTED); splx(s); tp->tap_flags |= TAP_INITED; - TAPDEBUG("interface %s%d created. minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("interface %s%d is created. minor = %#x\n", + ifp->if_name, ifp->if_unit, minor(dev)); } /* tapcreate */ @@ -310,29 +396,43 @@ struct proc *p; { struct tap_softc *tp = NULL; - int error; + int unit, error; + struct resource *r = NULL; if ((error = suser(p)) != 0) return (error); + unit = dev2unit(dev) & TAPMAXUNIT; + + if (minor(dev) & VMNET_DEV_MASK) + r = rman_reserve_resource(vmnetunits, unit, unit, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + else + r = rman_reserve_resource(tapunits, unit, unit, 1, + RF_ALLOCATED | RF_ACTIVE, NULL); + + if (r == NULL) + return (EBUSY); + + dev->si_flags &= ~SI_CHEAPCLONE; + tp = dev->si_drv1; if (tp == NULL) { tapcreate(dev); tp = dev->si_drv1; } - if (tp->tap_flags & TAP_OPEN) - return (EBUSY); + KASSERT(!(tp->tap_flags & TAP_OPEN), + ("%s%d flags is out of sync", tp->tap_if.if_name, unit)); bcopy(tp->arpcom.ac_enaddr, tp->ether_addr, sizeof(tp->ether_addr)); + tp->tap_unit = r; tp->tap_pid = p->p_pid; tp->tap_flags |= TAP_OPEN; - taprefcnt ++; - TAPDEBUG("%s%d is open. minor = %#x, refcnt = %d, taplastunit = %d\n", - tp->tap_if.if_name, tp->tap_if.if_unit, - minor(tp->tap_dev), taprefcnt, taplastunit); + TAPDEBUG("%s%d is open. minor = %#x\n", + tp->tap_if.if_name, unit, minor(dev)); return (0); } /* tapopen */ @@ -350,20 +450,15 @@ int bar; struct proc *p; { - int s; + int s, error; struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = &tp->tap_if; - struct mbuf *m = NULL; - /* junk all pending output */ + KASSERT((tp->tap_unit != NULL), + ("%s%d is not open", ifp->if_name, ifp->if_unit)); - s = splimp(); - do { - IF_DEQUEUE(&ifp->if_snd, m); - if (m != NULL) - m_freem(m); - } while (m != NULL); - splx(s); + /* junk all pending output */ + IF_DRAIN(&ifp->if_snd); /* * do not bring the interface down, and do not anything with @@ -401,18 +496,13 @@ tp->tap_flags &= ~TAP_OPEN; tp->tap_pid = 0; + error = rman_release_resource(tp->tap_unit); + KASSERT((error == 0), + ("%s%d could not release unit", ifp->if_name, ifp->if_unit)); + tp->tap_unit = NULL; - taprefcnt --; - if (taprefcnt < 0) { - taprefcnt = 0; - printf("%s%d minor = %#x, refcnt = %d is out of sync. " \ - "set refcnt to 0\n", ifp->if_name, ifp->if_unit, - minor(tp->tap_dev), taprefcnt); - } - - TAPDEBUG("%s%d is closed. minor = %#x, refcnt = %d, taplastunit = %d\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev), - taprefcnt, taplastunit); + TAPDEBUG("%s%d is closed. minor = %#x\n", + ifp->if_name, ifp->if_unit, minor(dev)); return (0); } /* tapclose */ @@ -430,8 +520,7 @@ struct tap_softc *tp = (struct tap_softc *)xtp; struct ifnet *ifp = &tp->tap_if; - TAPDEBUG("initializing %s%d, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("initializing %s%d\n", ifp->if_name, ifp->if_unit); ifp->if_flags |= IFF_RUNNING; ifp->if_flags &= ~IFF_OACTIVE; @@ -468,7 +557,7 @@ case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ case SIOCADDMULTI: case SIOCDELMULTI: - break; + break; case SIOCGIFSTATUS: s = splimp(); @@ -479,7 +568,7 @@ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); splx(s); - break; + break; default: return (EINVAL); @@ -501,8 +590,7 @@ struct tap_softc *tp = ifp->if_softc; int s; - TAPDEBUG("%s%d starting, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("%s%d starting\n", ifp->if_name, ifp->if_unit); /* * do not junk pending output if we are in VMnet mode. @@ -513,9 +601,8 @@ ((tp->tap_flags & TAP_READY) != TAP_READY)) { struct mbuf *m = NULL; - TAPDEBUG("%s%d not ready. minor = %#x, tap_flags = 0x%x\n", - ifp->if_name, ifp->if_unit, - minor(tp->tap_dev), tp->tap_flags); + TAPDEBUG("%s%d not ready, tap_flags = 0x%x\n", ifp->if_name, + ifp->if_unit, tp->tap_flags); s = splimp(); do { @@ -567,6 +654,7 @@ struct ifnet *ifp = &tp->tap_if; struct tapinfo *tapp = NULL; int s; + short f; switch (cmd) { case TAPSIFINFO: @@ -576,25 +664,25 @@ ifp->if_type = tapp->type; ifp->if_baudrate = tapp->baudrate; splx(s); - break; + break; case TAPGIFINFO: tapp = (struct tapinfo *)data; tapp->mtu = ifp->if_mtu; tapp->type = ifp->if_type; tapp->baudrate = ifp->if_baudrate; - break; + break; case TAPSDEBUG: tapdebug = *(int *)data; - break; + break; case TAPGDEBUG: *(int *)data = tapdebug; - break; + break; case FIONBIO: - break; + break; case FIOASYNC: s = splimp(); @@ -603,7 +691,7 @@ else tp->tap_flags &= ~TAP_ASYNC; splx(s); - break; + break; case FIONREAD: s = splimp(); @@ -612,11 +700,10 @@ for(*(int *)data = 0;mb != NULL;mb = mb->m_next) *(int *)data += mb->m_len; - } - else + } else *(int *)data = 0; splx(s); - break; + break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tap_sigio)); @@ -638,11 +725,10 @@ case SIOCGIFFLAGS: /* get ifnet flags */ bcopy(&ifp->if_flags, data, sizeof(ifp->if_flags)); - break; - - case VMIO_SIOCSIFFLAGS: { /* VMware/VMnet SIOCSIFFLAGS */ - short f = *(short *)data; + break; + case VMIO_SIOCSIFFLAGS: /* VMware/VMnet SIOCSIFFLAGS */ + f = *(short *)data; f &= 0x0fff; f &= ~IFF_CANTCHANGE; f |= IFF_UP; @@ -650,16 +736,16 @@ s = splimp(); ifp->if_flags = f | (ifp->if_flags & IFF_CANTCHANGE); splx(s); - } break; + break; case OSIOCGIFADDR: /* get MAC address of the remote side */ case SIOCGIFADDR: bcopy(tp->ether_addr, data, sizeof(tp->ether_addr)); - break; + break; case SIOCSIFADDR: /* set MAC address of the remote side */ bcopy(data, tp->ether_addr, sizeof(tp->ether_addr)); - break; + break; default: return (ENOTTY); @@ -685,13 +771,12 @@ struct mbuf *m = NULL, *m0 = NULL; int error = 0, len, s; - TAPDEBUG("%s%d reading, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("%s%d reading, minor = %#x\n", + ifp->if_name, ifp->if_unit, minor(dev)); if ((tp->tap_flags & TAP_READY) != TAP_READY) { TAPDEBUG("%s%d not ready. minor = %#x, tap_flags = 0x%x\n", - ifp->if_name, ifp->if_unit, - minor(tp->tap_dev), tp->tap_flags); + ifp->if_name, ifp->if_unit, minor(dev), tp->tap_flags); return (EHOSTDOWN); } @@ -731,8 +816,8 @@ } if (m0 != NULL) { - TAPDEBUG("%s%d dropping mbuf, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("%s%d dropping mbuf, minor = %#x\n", ifp->if_name, + ifp->if_unit, minor(dev)); m_freem(m0); } @@ -757,16 +842,15 @@ struct ether_header *eh = NULL; int error = 0, tlen, mlen; - TAPDEBUG("%s%d writting, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("%s%d writting, minor = %#x\n", + ifp->if_name, ifp->if_unit, minor(dev)); if (uio->uio_resid == 0) return (0); if ((uio->uio_resid < 0) || (uio->uio_resid > TAPMRU)) { TAPDEBUG("%s%d invalid packet len = %d, minor = %#x\n", - ifp->if_name, ifp->if_unit, - uio->uio_resid, minor(tp->tap_dev)); + ifp->if_name, ifp->if_unit, uio->uio_resid, minor(dev)); return (EIO); } @@ -836,21 +920,20 @@ struct ifnet *ifp = &tp->tap_if; int s, revents = 0; - TAPDEBUG("%s%d polling, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + TAPDEBUG("%s%d polling, minor = %#x\n", + ifp->if_name, ifp->if_unit, minor(dev)); s = splimp(); if (events & (POLLIN | POLLRDNORM)) { if (ifp->if_snd.ifq_len > 0) { TAPDEBUG("%s%d have data in queue. len = %d, " \ "minor = %#x\n", ifp->if_name, ifp->if_unit, - ifp->if_snd.ifq_len, minor(tp->tap_dev)); + ifp->if_snd.ifq_len, minor(dev)); revents |= (events & (POLLIN | POLLRDNORM)); - } - else { + } else { TAPDEBUG("%s%d waiting for data, minor = %#x\n", - ifp->if_name, ifp->if_unit, minor(tp->tap_dev)); + ifp->if_name, ifp->if_unit, minor(dev)); selrecord(p, &tp->tap_rsel); } diff -ru /usr/src/sys/net/if_tapvar.h ./src/sys/net/if_tapvar.h --- /usr/src/sys/net/if_tapvar.h Tue Jul 25 16:50:30 2000 +++ ./src/sys/net/if_tapvar.h Thu Aug 30 16:06:21 2001 @@ -44,7 +44,7 @@ struct tap_softc { struct arpcom arpcom; /* ethernet common data */ #define tap_if arpcom.ac_if - dev_t tap_dev; /* device */ + struct resource *tap_unit; /* unit */ u_short tap_flags; /* misc flags */ #define TAP_OPEN (1 << 0) @@ -59,6 +59,8 @@ pid_t tap_pid; /* PID of process to open */ struct sigio *tap_sigio; /* information for async I/O */ struct selinfo tap_rsel; /* read select */ + + SLIST_ENTRY(tap_softc) tap_next; /* next device in chain */ }; #endif /* !_NET_IF_TAPVAR_H_ */ --------------A09F7670A8BACD9104B3E55E-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 10:14:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from spitfire.velocet.net (spitfire.velocet.net [216.138.223.227]) by hub.freebsd.org (Postfix) with ESMTP id 1D63837B405 for ; Fri, 31 Aug 2001 10:14:10 -0700 (PDT) Received: from nomad.tor.lets.net (H74.C220.tor.velocet.net [216.138.220.74]) by spitfire.velocet.net (Postfix) with SMTP id 0717B44AAFD for ; Fri, 31 Aug 2001 13:14:09 -0400 (EDT) Received: (qmail 15506 invoked by uid 1001); 31 Aug 2001 17:09:02 -0000 Date: Fri, 31 Aug 2001 13:09:02 -0400 From: Steve Shorter To: freebsd-net@freebsd.org Subject: Tuning UDP for NFS Message-ID: <20010831130902.A15501@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy! I am interested in tuning UDP for NFS over a 100Mbs LAN. Specifically, to tune UDP, what are guidelines/restrictions for setting the sysclt variables net.inet.udp.maxdgram net.inet.udp.recvspace I assume that increasing both of these will improve performance. Is this correct? What factors should be considered, and what other barriers/effects (if any) will I come up against. Any experience/knowledge that you can share will be greatly appreciated. thanx - steve (Please CC me as I am not on the list) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 10:19:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id BFCBB37B401 for ; Fri, 31 Aug 2001 10:19:23 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f7VHJJn79650; Fri, 31 Aug 2001 13:19:19 -0400 (EDT) (envelope-from wollman) Date: Fri, 31 Aug 2001 13:19:19 -0400 (EDT) From: Garrett Wollman Message-Id: <200108311719.f7VHJJn79650@khavrinen.lcs.mit.edu> To: Steve Shorter Cc: freebsd-net@FreeBSD.ORG Subject: Tuning UDP for NFS In-Reply-To: <20010831130902.A15501@nomad.lets.net> References: <20010831130902.A15501@nomad.lets.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > net.inet.udp.maxdgram > net.inet.udp.recvspace > I assume that increasing both of these will improve performance. Neither of these have any impact on UDP performance. In fact, there really are no UDP performance parameters to be tweaked; the UDP protocol doesn't have much in the way of mechanism which would need it. You need to instead look at tuning NFS. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 10:51:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id B985437B403 for ; Fri, 31 Aug 2001 10:51:25 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id AA34481D01; Fri, 31 Aug 2001 12:51:20 -0500 (CDT) Date: Fri, 31 Aug 2001 12:51:20 -0500 From: Alfred Perlstein To: Steve Shorter Cc: freebsd-net@freebsd.org Subject: Re: Tuning UDP for NFS Message-ID: <20010831125120.O81307@elvis.mu.org> References: <20010831130902.A15501@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010831130902.A15501@nomad.lets.net>; from steve@nomad.lets.net on Fri, Aug 31, 2001 at 01:09:02PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Steve Shorter [010831 12:14] wrote: > Howdy! > > I am interested in tuning UDP for NFS over a 100Mbs LAN. > > Specifically, to tune UDP, what are guidelines/restrictions for > setting the sysclt variables > > net.inet.udp.maxdgram > > net.inet.udp.recvspace > > > I assume that increasing both of these will improve performance. > Is this correct? What factors should be considered, and what other > barriers/effects (if any) will I come up against. > > Any experience/knowledge that you can share will be greatly > appreciated. Using UDP is usually a bad idea, I would use tcp, I find that these flags make for a decent mount point that's quite fast: rw,tcp,intr,nfsv3,-w=32768,-r=32768 -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 13: 3:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 593B937B408 for ; Fri, 31 Aug 2001 13:03:49 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f7VK3kg03443; Fri, 31 Aug 2001 13:03:46 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.5/8.11.0) id f7VK3k004259; Fri, 31 Aug 2001 13:03:46 -0700 (PDT) (envelope-from jdp) Date: Fri, 31 Aug 2001 13:03:46 -0700 (PDT) Message-Id: <200108312003.f7VK3k004259@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bright@mu.org Subject: Re: Tuning UDP for NFS In-Reply-To: <20010831125120.O81307@elvis.mu.org> References: <20010831130902.A15501@nomad.lets.net> <20010831125120.O81307@elvis.mu.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20010831125120.O81307@elvis.mu.org>, Alfred Perlstein wrote: > > Using UDP is usually a bad idea, I would use tcp, I find that these > flags make for a decent mount point that's quite fast: > rw,tcp,intr,nfsv3,-w=32768,-r=32768 FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do you think we should change it? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 13:41:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 0C88B37B406 for ; Fri, 31 Aug 2001 13:41:20 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id F057C81D01; Fri, 31 Aug 2001 15:41:19 -0500 (CDT) Date: Fri, 31 Aug 2001 15:41:19 -0500 From: Alfred Perlstein To: John Polstra Cc: net@freebsd.org Subject: Re: Tuning UDP for NFS Message-ID: <20010831154119.S81307@elvis.mu.org> References: <20010831130902.A15501@nomad.lets.net> <20010831125120.O81307@elvis.mu.org> <200108312003.f7VK3k004259@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108312003.f7VK3k004259@vashon.polstra.com>; from jdp@polstra.com on Fri, Aug 31, 2001 at 01:03:46PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * John Polstra [010831 15:03] wrote: > In article <20010831125120.O81307@elvis.mu.org>, > Alfred Perlstein wrote: > > > > Using UDP is usually a bad idea, I would use tcp, I find that these > > flags make for a decent mount point that's quite fast: > > rw,tcp,intr,nfsv3,-w=32768,-r=32768 > > FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do > you think we should change it? I'm not familiar with amd, what implications would that have? What worries me is people using amd against a v2 server, also those tunables are good at tickling bugs in other NFS implementations (as well as ours, at least a year or two ago). So if amd is smart enough to downgrade then yes, otherwise perhaps just a comment to indicate that the person may want to use better mount options... ? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 18:39:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from spitfire.velocet.net (spitfire.velocet.net [216.138.223.227]) by hub.freebsd.org (Postfix) with ESMTP id 644E937B408 for ; Fri, 31 Aug 2001 18:39:13 -0700 (PDT) Received: from nomad.tor.lets.net (H74.C220.tor.velocet.net [216.138.220.74]) by spitfire.velocet.net (Postfix) with SMTP id 5390D44A91B for ; Fri, 31 Aug 2001 21:39:12 -0400 (EDT) Received: (qmail 36099 invoked by uid 1001); 1 Sep 2001 01:34:05 -0000 Date: Fri, 31 Aug 2001 21:34:05 -0400 From: Steve Shorter To: freebsd-net@freebsd.org Subject: 4.3 RELEASE "bug" status and patches? Message-ID: <20010831213405.A36093@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy! There is a reference to a networking code bug in 4.3 RELEASE on http://www.daemonnews.org/200108/benchmark.html in the footnote at the bottom. It also references a patch. I can find no other information about this issue. Can someone point me to the patch or other documentation about this. thanx - steve (Please Cc me as I am not on the list) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 31 22:57:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by hub.freebsd.org (Postfix) with ESMTP id 7F78D37B409 for ; Fri, 31 Aug 2001 22:57:44 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 2E8597BA; Tue, 28 Aug 2001 23:05:30 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Anastasia Leventi-Peetz , net@FreeBSD.ORG In-reply-to: jinmei's message of Tue, 28 Aug 2001 20:16:02 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: From: Jun-ichiro itojun Hagino Date: Tue, 28 Aug 2001 23:05:30 +0900 Message-Id: <20010828140530.2E8597BA@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >By the way, RFC2893 has the following text: (snip) >Thus, people would say that KAME (FreeBSD) is not compliant to RFC >2893. i guess you did not check the original question. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 6:42: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from e028121.vtacs.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by hub.freebsd.org (Postfix) with ESMTP id 16FF237B40A for ; Sat, 1 Sep 2001 06:42:05 -0700 (PDT) Received: by e028121.vtacs.vt.edu (Postfix, from userid 1000) id A71B98678; Sat, 1 Sep 2001 09:42:32 -0400 (EDT) Date: Sat, 1 Sep 2001 09:42:32 -0400 From: Clark Gaylord To: freebsd-net@freebsd.org Subject: Re: Tuning UDP for NFS Message-ID: <20010901094232.B41683@e028121.vtacs.vt.edu> References: <20010831130902.A15501@nomad.lets.net> <20010831125120.O81307@elvis.mu.org> <200108312003.f7VK3k004259@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200108312003.f7VK3k004259@vashon.polstra.com>; from jdp@polstra.com on Fri, Aug 31, 2001 at 01:03:46PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In various performance tests we have found proto=tcp to be uniformly a Good Thing. I'd vote for that to be default in general, but perhaps there is an AMD-specific reason for UDP; I can't imagine what that would be, though. --ckg On Fri, Aug 31, 2001 at 01:03:46PM -0700, John Polstra wrote: > In article <20010831125120.O81307@elvis.mu.org>, > Alfred Perlstein wrote: > > > > Using UDP is usually a bad idea, I would use tcp, I find that these > > flags make for a decent mount point that's quite fast: > > rw,tcp,intr,nfsv3,-w=32768,-r=32768 > > FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do > you think we should change it? > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 6:58:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134]) by hub.freebsd.org (Postfix) with ESMTP id 6603537B403; Sat, 1 Sep 2001 06:58:12 -0700 (PDT) Received: from world.std.com (world-f.std.com [199.172.62.5]) by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id JAA19774005; Sat, 1 Sep 2001 09:58:11 -0400 (EDT) Received: (from kwc@localhost) by world.std.com (8.9.3/8.9.3) id JAA09511; Sat, 1 Sep 2001 09:58:09 -0400 (EDT) Date: Sat, 1 Sep 2001 09:58:09 -0400 (EDT) From: Kenneth W Cochran Message-Id: <200109011358.JAA09511@world.std.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: NAT with >1 gateway interface Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: How do I "properly" set up NAT on a system that "transmits" and "receives" on different interfaces? Briefly - Machine A receives on fxp0 & transmits on ppp0. I'd like to use a 2nd Ethernet on Machine A (fxp1) for the "NAT"ed/masqueraded network. Scenario: Machine A: - Running RELENG_4 as of 2001/08/28, scheduled to update again 2001/09/01 (thus one reason I'm asking on -stable :). - Connected to a "hybrid" aka "1-way" cable-modem, - "Receives" via cablemodem/Ethernet (fxp0, config'ed as 10.0.0.11/24) - "Transmits/outgoing" is via analog dial-modem & ppp(d). - "Real" ip-address is established by (kernel) pppd (ppp0), and is "officially" dynamic, even though it always (at least right now) gets the same ip-address. - Runs cache-only nameserver. - Has been running in this manner for about 1.5 years. - (recently) Has 2nd NIC (fxp1), connected to hub for private network. Machine B: - Has private ip-address on "its" fxp0. - Connected via hub to 2nd NIC (fxp1) on Machine A. I've followed the instructions from the Handbook, Section 18.10, Network Address Translation. Machines A & B can talk to each other; I can ping & ssh from/to either one. Machine A communicates "outside" (with the Internet) as usual, but Machine B cannot. I'm thinking something needs to be tweaked in the ipfw and/or natd-config(s). Suggestions? Also, where would be the best place(s) to put these "customizations" (for example, so as to not be any more "disruptive" than necessary to the base-OS configs)? Of course, FAQ/-doc/readme pointers are quite welcome. :) Please cc replies to me. Many thanks, -kc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 9: 2: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id EE01A37B40B for ; Sat, 1 Sep 2001 09:01:57 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id f81G1tg11104; Sat, 1 Sep 2001 09:01:55 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.5/8.11.0) id f81G1tY09116; Sat, 1 Sep 2001 09:01:55 -0700 (PDT) (envelope-from jdp) Date: Sat, 1 Sep 2001 09:01:55 -0700 (PDT) Message-Id: <200109011601.f81G1tY09116@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: bright@mu.org Subject: Re: Tuning UDP for NFS In-Reply-To: <20010831154119.S81307@elvis.mu.org> References: <20010831130902.A15501@nomad.lets.net> <20010831125120.O81307@elvis.mu.org> <200108312003.f7VK3k004259@vashon.polstra.com> <20010831154119.S81307@elvis.mu.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20010831154119.S81307@elvis.mu.org>, Alfred Perlstein wrote: > * John Polstra [010831 15:03] wrote: > > FreeBSD's "src/etc/amd.map" file still has "vers=2,proto=udp". Do > > you think we should change it? > > I'm not familiar with amd, what implications would that have? > > What worries me is people using amd against a v2 server, also those > tunables are good at tickling bugs in other NFS implementations > (as well as ours, at least a year or two ago). So if amd is smart > enough to downgrade then yes, otherwise perhaps just a comment to > indicate that the person may want to use better mount options... ? I have the same concerns. Unfortunately I don't know enough about NFS interoperability issues to say whether it would cause problems or not. OTOH we have been moving toward giving our default configurations better performance at the expense of a small amount of failsafe-ness. I'm inclined to think this might be a good candidate for that trend. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 9:52: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from gahch.it.ca (gahch.it.ca [216.126.86.4]) by hub.freebsd.org (Postfix) with ESMTP id 1BF4C37B40C for ; Sat, 1 Sep 2001 09:52:00 -0700 (PDT) Received: (from paul@localhost) by gahch.it.ca (8.11.5/8.11.1) id f81Gncq47509; Sat, 1 Sep 2001 12:49:38 -0400 (EDT) (envelope-from paul) Date: Sat, 1 Sep 2001 12:49:38 -0400 From: Paul Chvostek To: Joshua Goodall Cc: net@freebsd.org Subject: Re: Gratuitous ARP (summary) Message-ID: <20010901124938.A41615@gahch.it.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from joshua@roughtrade.net on Wed, Aug 29, 2001 at 12:26:15AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Aug 29, 2001 at 12:26:15AM +0100, Joshua Goodall wrote: > 0:a0:c9:ca:73:5f Broadcast arp 42: arp who-has 10.1.1.1 tell 10.1.1.1 > > and is primarily used for collision detection and network-local arp-cache > priming, but also has applications in IP address migration (a common > high-availability technique). I should not have described it as an "arp > reply" since it is, of course, an "arp who-has". Yeah, that got me too -- I thought you were trying to manually implement proxy-arp by sending out is-at's. I saw this behaviour with a Cisco router that was managing a dialup pool and sending gratuitous is-at's every time a new IP address was assigned out of the pool to a new PPP session. It became a problem when the pool got into the 1000's of lines, because every machine on the network was maintaining a huge honkin' local arp table rather than just relying on routing. > a) in the case where the address is an alias, re-issuing the > ifconfig ... alias results in a gratuitous ARP for the alias address > without losing the subnet route & ARP cache entries. However I use a > netmask of 255.255.255.255 for all aliases in the same subnet as the > primary, in line with the ifconfig(8) manual. FWIW, on aliased IPs, I seem to be unable to generate the who-has arps unless I specify the netmask. Just doing "ifconfig if0 a.b.c.d alias" does not seem to be sufficient. But the actual value of the netmask should not affect ARP, since ARP doesn't know about CIDR. > So I'm happy now. Woo hoo! :) I'd still like to know how to generate a gratuitous is-at. I mean, besides forging it in dsniff's arpspoof. -- Paul Chvostek Operations / Development / Abuse / Whatever vox: +1 416 598-0000 IT Canada http://www.it.ca/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 15:14:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-54.dsl.lsan03.pacbell.net [63.207.60.54]) by hub.freebsd.org (Postfix) with ESMTP id 7FDC637B419 for ; Sat, 1 Sep 2001 15:14:02 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 190CB66C80; Sat, 1 Sep 2001 15:14:02 -0700 (PDT) Date: Sat, 1 Sep 2001 15:14:01 -0700 From: Kris Kennaway To: Steve Shorter Cc: freebsd-net@freebsd.org Subject: Re: 4.3 RELEASE "bug" status and patches? Message-ID: <20010901151401.D57116@xor.obsecurity.org> References: <20010831213405.A36093@nomad.lets.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010831213405.A36093@nomad.lets.net>; from steve@nomad.lets.net on Fri, Aug 31, 2001 at 09:34:05PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 31, 2001 at 09:34:05PM -0400, Steve Shorter wrote: > Howdy! >=20 > There is a reference to a networking code bug in 4.3 RELEASE on=20 >=20 > http://www.daemonnews.org/200108/benchmark.html >=20 > in the footnote at the bottom. >=20 >=20 > It also references a patch. I can find no other information about > this issue. Can someone point me to the patch or other documentation > about this.=20 Yes, it was fixed by switching to the RFC 1948 algorithm. Kris --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7kV2pWry0BWjoQKURAoi/AJ0YUpo5RQWPEUJilxX87R/vqkR18QCfRo5G oFtcTaFZbAqseCfFlSqBtt0= =oD+L -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 18:30:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 32E7337B408 for ; Sat, 1 Sep 2001 18:30:29 -0700 (PDT) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta19/8.12.0.Beta19/Debian 8.12.0.Beta19) with ESMTP id f821UR2r002148; Sun, 2 Sep 2001 02:30:27 +0100 Date: Sun, 2 Sep 2001 02:30:27 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Paul Chvostek Cc: Subject: Re: Gratuitous ARP (summary) In-Reply-To: <20010901124938.A41615@gahch.it.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 1 Sep 2001, Paul Chvostek wrote: > FWIW, on aliased IPs, I seem to be unable to generate the who-has arps > unless I specify the netmask. Just doing "ifconfig if0 a.b.c.d alias" > does not seem to be sufficient. But the actual value of the netmask > should not affect ARP, since ARP doesn't know about CIDR. I see the same behaviour (as predicted by Ruslan). A full ifconfig inet
netmask alias is required. > I'd still like to know how to generate a gratuitous is-at. I mean, > besides forging it in dsniff's arpspoof. I think the base system lacks the tools. You may be able to roll-your-own with appropriate ioctls, this being all ifconfig does in practise. However, none of them seem documented to perform any immediate ARP functions, this being a side-effect of their functionality at best. I think, ultimately, the only guaranteed way is to construct your own ARP packet and write it at the link layer. arping uses libnet for this. Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 19:46:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 6EFFD37B409; Sat, 1 Sep 2001 19:46:21 -0700 (PDT) Received: from vovik@localhost (vovik@localhost) by burka.carrier.kiev.ua id FRU49123; Sun, 2 Sep 2001 05:46:17 +0300 (EEST) (envelope-from vovik) Date: Sun, 2 Sep 2001 05:46:17 +0300 From: "Vladimir A. Jakovenko" To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: SO_REUSEPORT on unicast UDP sockets Message-ID: <20010902054617.A47742@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than one socket to the same port (even with same source ip address). But quick look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will work as expected (data stream duplicate) only on multicast/broadcast local addresses. Please pay attention to the following code fragment comments: if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) { struct inpcb *last; /* * Deliver a multicast or broadcast datagram to *all* sockets * for which the local and remote addresses and ports match * those of the incoming datagram. This allows more than * one process to receive multi/broadcasts on the same port. * (This really ought to be done for unicast datagrams as * well, but that would cause problems with existing * applications that open both address-specific sockets and * a wildcard socket listening to the same port -- they would * end up receiving duplicates of every unicast datagram. * Those applications open the multiple sockets to overcome an * inadequacy of the UDP socket interface, but for backwards * compatibility we avoid the problem here rather than * fixing the interface. Maybe 4.5BSD will remedy this?) */ Is there still any real need in such backward compatibility? Can such functionality be added (fixed) with possibility to switch it off using sysctl or kernel-build option? I find such possibility realy useful at least for NetFlow data processing and believe that it would be useful for many UDP-based protocols. -- Regards, Vladimir. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 1 23:12:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from gahch.it.ca (gahch.it.ca [216.126.86.4]) by hub.freebsd.org (Postfix) with ESMTP id 1041237B407 for ; Sat, 1 Sep 2001 23:12:44 -0700 (PDT) Received: (from paul@localhost) by gahch.it.ca (8.11.5/8.11.1) id f826AYL79167 for freebsd-net@freebsd.org; Sun, 2 Sep 2001 02:10:34 -0400 (EDT) (envelope-from paul) Date: Sun, 2 Sep 2001 02:10:34 -0400 From: Paul Chvostek To: freebsd-net@freebsd.org Subject: laptop arp weirdness Message-ID: <20010902021033.L60846@gahch.it.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hiya. Major weirdness here, confusing me greatly. I've just set up a Dell Latitude XPi CD with a fresh install of 4.3-RELEASE (since the boot floppies for 4.4-RELEASE cause a kernel panic on this box, but that's another story). I've got a pair of 3COM 3C589D cards which both exhibit identical behaviour, both of which have work fine in other other laptops and other operating systems on the same laptop, on the same Ethernet cable. I see the same behaviour with the GENERIC kernel as well as the stripped-down kernel with only 'device ep' for Ethernet. The 3C589D cards are recognized properly by pccardd using the default config file. The interface is assigned, I see the card's MAC address, and can assign an IP address. The ifconfig shows: ep0: flags=8843 mtu 1500 inet 10.4.1.9 netmask 0xffffff00 broadcast 10.4.1.255 ether 00:60:97:78:2a:e4 media: 10baseT/UTP supported media: 10base2/BNC 10baseT/UTP 10base5/AUI Oddly, the laptop's own IP and MAC address pair appears as "permanent" in its arp table (I haven't noticed that before), and it's picking up arp from the rest of the network. I tried removing that entry, but it didn't change the behaviour. I thought at first that the card just wasn't talking to the network, despite showing a link light on both ends. On a hunch, I left a ping to the laptop running for a while, and started seeing the real weirdness. # ping -r 10.4.1.9 PING 10.4.1.9 (10.4.1.9): 56 data bytes 64 bytes from 10.4.1.9: icmp_seq=75 ttl=255 time=78305.271 ms 64 bytes from 10.4.1.9: icmp_seq=153 ttl=255 time=99514.223 ms 64 bytes from 10.4.1.9: icmp_seq=154 ttl=255 time=98504.297 ms 64 bytes from 10.4.1.9: icmp_seq=155 ttl=255 time=97494.497 ms 64 bytes from 10.4.1.9: icmp_seq=156 ttl=255 time=96484.632 ms 64 bytes from 10.4.1.9: icmp_seq=157 ttl=255 time=95474.784 ms 64 bytes from 10.4.1.9: icmp_seq=158 ttl=255 time=94464.932 ms 64 bytes from 10.4.1.9: icmp_seq=159 ttl=255 time=93455.088 ms 64 bytes from 10.4.1.9: icmp_seq=160 ttl=255 time=92445.242 ms 64 bytes from 10.4.1.9: icmp_seq=161 ttl=255 time=91435.438 ms 64 bytes from 10.4.1.9: icmp_seq=162 ttl=255 time=90425.590 ms 64 bytes from 10.4.1.9: icmp_seq=163 ttl=255 time=89415.743 ms 64 bytes from 10.4.1.9: icmp_seq=164 ttl=255 time=88405.884 ms 64 bytes from 10.4.1.9: icmp_seq=165 ttl=255 time=87396.055 ms 64 bytes from 10.4.1.9: icmp_seq=166 ttl=255 time=86386.208 ms 64 bytes from 10.4.1.9: icmp_seq=167 ttl=255 time=85376.361 ms 64 bytes from 10.4.1.9: icmp_seq=168 ttl=255 time=84366.512 ms 64 bytes from 10.4.1.9: icmp_seq=169 ttl=255 time=83356.672 ms 64 bytes from 10.4.1.9: icmp_seq=170 ttl=255 time=82346.809 ms 64 bytes from 10.4.1.9: icmp_seq=171 ttl=255 time=81336.987 ms 64 bytes from 10.4.1.9: icmp_seq=172 ttl=255 time=80327.140 ms 64 bytes from 10.4.1.9: icmp_seq=173 ttl=255 time=79317.297 ms 64 bytes from 10.4.1.9: icmp_seq=174 ttl=255 time=78307.456 ms ^C --- 10.4.1.9 ping statistics --- 270 packets transmitted, 23 packets received, 91% packet loss round-trip min/avg/max/stddev = 78305.271/88449.701/99514.223/6628.680 ms Pings in the other direction (i.e. laptop to network) look the same, but are more difficult to cut and paste. :) The lines from 153 to 174 appeared ALL AT ONCE (note the decending times). If I leave it for a long time, the pattern repeats, with a slew of ping responses showing up at irregular intervals. I also ran tcpdumps elsewhere on the network, and found that ... - pings *to* the laptop merely generate gobs of "arp who-has" on the network, none of which is seen by the laptop, - pings from the laptop are being seen by other hosts but ARP isn't being answered in a timely fashion, so other machines on the network can't respond to the pings. A ping from the laptop (.9) as seen from another box (.4): # tcpdump -neixl0 icmp or arp tcpdump: listening on xl0 01:36:39.754243 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:39.754375 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:40.762199 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:40.762276 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:41.772074 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:41.772139 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:42.781983 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:42.782061 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:43.791886 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:43.791937 0:60:8:5a:58:fc ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.4.1.9 tell 10.4.1.4 01:36:44.801844 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:45.811725 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:46.821628 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:47.831538 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:36:48.841466 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request ... 01:37:43.376789 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:44.386633 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:45.396575 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:46.406470 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:47.417971 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418017 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:47.418030 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418090 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418288 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418356 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418423 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418491 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418559 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418627 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418695 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418763 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418830 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418899 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.418989 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.419034 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0806 60: arp reply 10.4.1.9 is-at 0:60:97:89:2a:e4 01:37:47.419134 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:47.419192 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:48.426296 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:48.426379 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply 01:37:49.436246 0:60:97:89:2a:e4 0:60:8:5a:58:fc 0800 98: 10.4.1.9 > 10.4.1.4: icmp: echo request 01:37:49.436331 0:60:8:5a:58:fc 0:60:97:89:2a:e4 0800 98: 10.4.1.4 > 10.4.1.9: icmp: echo reply Note the collection of arp replies at 01:37:47. So the icmp is moving, but the laptop is failing to spit out the arp replies that would let machines on the LAN send traffic to it. Note that despite the "echo reply" shown by tcpdump at the end of this session, the responses never actually showed up in ping's stdout. It seems to me that everything would work a little better if the laptop would respond to arp who-has packets, which it does not seem to do. The only time other machines get to see the laptop's MAC address is from outbound traffic from the laptop, except for bursts which happen every few minutes of traffic. I've got other tcpdump details that may or may not be relevant, but would certainly lengthen this email if included, so I won't include 'em. Anybody have any idea what's going on? I'm stumped. -- Paul Chvostek Operations / Development / Abuse / Whatever vox: +1 416 598-0000 IT Canada http://www.it.ca/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message