From owner-freebsd-net Sun Aug 12 0:56:56 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 AB86F37B403 for ; Sun, 12 Aug 2001 00:55: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 AAA95437 for ; Sun, 12 Aug 2001 00:49:33 -0700 (PDT) Message-ID: <3B76330E.86A0B689@elischer.org> Date: Sun, 12 Aug 2001 00:41:02 -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: net@freebsd.org Subject: IPV6/KAME/protosw integration cleanup Content-Type: multipart/mixed; boundary="------------8E304995AC7CC80311DE7C03" 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. --------------8E304995AC7CC80311DE7C03 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit When KAME was added the mesh was less that perfect but there was so much to be done that some shortcuts needed to be taken. now that time has passed some of these can be cleaned up. 1/ Merging ipprotosw.h and protosw.h 2/ removal of all varargs stuff from the kernel (this revealing the mismatched prototypes they were hiding) removal of lotso warnings from the KAME stuff. here is a set of patches: Notes: the change of 'proto' on output from int to protonum_t was to catch any 'wrong' usage of that tempting integer argument and can be left out of what's commtted. the function in6_pcbnotify() takes const arguments on the 4th argument in severalplaces, however if you try make this argument a const, you discover that, while error messages are reduced elsewhere, the function actually can modify the contents of what that argument is pointing to, thus consts could be modified.. either the arguments need to be copied at those call points or the function fixed.. Either way there are still Far too many warming messages coming out of the IPV6 code. this is a first pass. As a rsult of it, netinet/ipprotosw.h can be removed. I'd really like it if the KAME guys would use these as a base to FIX some of the interface hacks they needed to do to get KAME in.. Julian -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v --------------8E304995AC7CC80311DE7C03 Content-Type: text/plain; charset=iso-8859-2; name="protosw.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="protosw.diff" ? i386/conf/LINT Index: contrib/ipfilter/netinet/mlfk_ipl.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/mlfk_ipl.c,v retrieving revision 1.9 diff -u -r1.9 mlfk_ipl.c --- contrib/ipfilter/netinet/mlfk_ipl.c 2001/03/26 12:41:18 1.9 +++ contrib/ipfilter/netinet/mlfk_ipl.c 2001/08/12 07:31:48 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include Index: kern/uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.86 diff -u -r1.86 uipc_mbuf.c --- kern/uipc_mbuf.c 2001/06/22 06:34:59 1.86 +++ kern/uipc_mbuf.c 2001/08/12 07:31:57 @@ -303,7 +303,7 @@ * continuing for "len" bytes, into the indicated buffer. */ void -m_copydata(struct mbuf *m, int off, int len, caddr_t cp) +m_copydata(const struct mbuf *m, int off, int len, caddr_t cp) { unsigned count; Index: net/if_faith.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.6 diff -u -r1.6 if_faith.c --- net/if_faith.c 2001/07/05 14:42:54 1.6 +++ net/if_faith.c 2001/08/12 07:31:59 @@ -58,6 +58,7 @@ #include #include #include +#include #include #include Index: net/if_gif.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.c,v retrieving revision 1.12 diff -u -r1.12 if_gif.c --- net/if_gif.c 2001/07/02 21:02:05 1.12 +++ net/if_gif.c 2001/08/12 07:31:59 @@ -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, @@ -110,7 +109,7 @@ }; #endif #ifdef INET6 -extern struct domain6 inet6domain; +extern struct domain inet6domain; struct ip6protosw in6_gif_protosw = { SOCK_RAW, &inet6domain, 0/*IPPROTO_IPV[46]*/, PR_ATOMIC|PR_ADDR, in6_gif_input, rip6_output, 0, rip6_ctloutput, @@ -321,7 +320,7 @@ } /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); switch (ip.ip_v) { #ifdef INET @@ -571,6 +570,9 @@ &(((struct if_laddrreq *)data)->addr); dst = (struct sockaddr *) &(((struct if_laddrreq *)data)->dstaddr); + break; + default: + panic("gif_ioctl"); } /* sa_family must be equal */ Index: net/if_stf.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.9 diff -u -r1.9 if_stf.c --- net/if_stf.c 2001/07/02 21:02:05 1.9 +++ net/if_stf.c 2001/08/12 07:31:59 @@ -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, @@ -247,7 +246,7 @@ return 0; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); if (ip.ip_v != 4) return 0; @@ -531,14 +530,11 @@ } void -#if __STDC__ -in_stf_input(struct mbuf *m, ...) -#else -in_stf_input(m, va_alist) +in_stf_input(m, off, proto) struct mbuf *m; -#endif + int off; + protonum_t proto; { - int off, proto; struct stf_softc *sc; struct ip *ip; struct ip6_hdr *ip6; @@ -546,12 +542,6 @@ int len, isr; struct ifqueue *ifq = NULL; struct ifnet *ifp; - va_list ap; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); if (proto != IPPROTO_IPV6) { m_freem(m); Index: net/if_stf.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_stf.h,v retrieving revision 1.1 diff -u -r1.1 if_stf.h --- net/if_stf.h 2000/07/04 16:35:04 1.1 +++ net/if_stf.h 2001/08/12 07:31:59 @@ -33,6 +33,6 @@ #ifndef _NET_IF_STF_H_ #define _NET_IF_STF_H_ -void in_stf_input __P((struct mbuf *, ...)); +pr_input_t in_stf_input; #endif /* _NET_IF_STF_H_ */ Index: net/net_osdep.h =================================================================== RCS file: /home/ncvs/src/sys/net/net_osdep.h,v retrieving revision 1.5 diff -u -r1.5 net_osdep.h --- net/net_osdep.h 2001/06/11 12:38:58 1.5 +++ net/net_osdep.h 2001/08/12 07:31:59 @@ -195,6 +195,7 @@ * - protosw for IPv4 (sys/netinet) * FreeBSD4: struct ipprotosw in netinet/ipprotosw.h * others: struct protosw in sys/protosw.h + * (including FreeBSD5) * * - protosw in general. * NetBSD 1.5 has extra member for ipfilter (netbsd-current dropped Index: net/raw_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/net/raw_usrreq.c,v retrieving revision 1.19 diff -u -r1.19 raw_usrreq.c --- net/raw_usrreq.c 2000/10/29 16:06:43 1.19 +++ net/raw_usrreq.c 2001/08/12 07:31:59 @@ -249,15 +249,14 @@ error = EISCONN; goto release; } - rp->rcb_faddr = nam; } else if (rp->rcb_faddr == 0) { error = ENOTCONN; goto release; + } else { + nam = rp->rcb_faddr; } - error = (*so->so_proto->pr_output)(m, so); + error = (*so->so_proto->pr_output)(m, so, nam); m = NULL; - if (nam) - rp->rcb_faddr = 0; release: if (m != NULL) m_freem(m); Index: net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.55 diff -u -r1.55 rtsock.c --- net/rtsock.c 2001/08/02 19:56:29 1.55 +++ net/rtsock.c 2001/08/12 07:32:01 @@ -73,7 +73,7 @@ static int rt_xaddrs __P((caddr_t, caddr_t, struct rt_addrinfo *)); static int sysctl_dumpentry __P((struct radix_node *rn, void *vw)); static int sysctl_iflist __P((int af, struct walkarg *w)); -static int route_output __P((struct mbuf *, struct socket *)); +static pr_output_t route_output; static void rt_setmetrics __P((u_long, struct rt_metrics *, struct rt_metrics *)); /* Sleazy use of local variables throughout file, warning!!!! */ @@ -264,18 +264,34 @@ } static struct pr_usrreqs route_usrreqs = { - rts_abort, pru_accept_notsupp, rts_attach, rts_bind, rts_connect, - pru_connect2_notsupp, pru_control_notsupp, rts_detach, rts_disconnect, - pru_listen_notsupp, rts_peeraddr, pru_rcvd_notsupp, pru_rcvoob_notsupp, - rts_send, pru_sense_null, rts_shutdown, rts_sockaddr, - sosend, soreceive, sopoll + rts_abort, + pru_accept_notsupp, + rts_attach, + rts_bind, + rts_connect, + pru_connect2_notsupp, + pru_control_notsupp, + rts_detach, + rts_disconnect, + pru_listen_notsupp, + rts_peeraddr, + pru_rcvd_notsupp, + pru_rcvoob_notsupp, + rts_send, + pru_sense_null, + rts_shutdown, + rts_sockaddr, + sosend, + soreceive, + sopoll }; /*ARGSUSED*/ static int -route_output(m, so) +route_output(m, so, addr) register struct mbuf *m; struct socket *so; + struct sockaddr *addr; { register struct rt_msghdr *rtm = 0; register struct rtentry *rt = 0; Index: netinet/igmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/igmp.c,v retrieving revision 1.31 diff -u -r1.31 igmp.c --- netinet/igmp.c 2001/06/23 17:17:58 1.31 +++ netinet/igmp.c 2001/08/12 07:32:03 @@ -150,7 +150,8 @@ void igmp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + protonum_t proto; { register int iphlen = off; register struct igmp *igmp; Index: netinet/igmp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/igmp_var.h,v retrieving revision 1.17 diff -u -r1.17 igmp_var.h --- netinet/igmp_var.h 1999/12/29 04:40:59 1.17 +++ netinet/igmp_var.h 2001/08/12 07:32:03 @@ -85,12 +85,13 @@ */ #define IGMP_AGE_THRESHOLD 540 -void igmp_init __P((void)); -void igmp_input __P((struct mbuf *, int, int)); +pr_init_t igmp_init; +pr_input_t igmp_input; +pr_fasttimo_t igmp_fasttimo; +pr_slowtimo_t igmp_slowtimo; + void igmp_joingroup __P((struct in_multi *)); void igmp_leavegroup __P((struct in_multi *)); -void igmp_fasttimo __P((void)); -void igmp_slowtimo __P((void)); SYSCTL_DECL(_net_inet_igmp); Index: netinet/in.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.55 diff -u -r1.55 in.c --- netinet/in.c 2001/08/04 17:10:13 1.55 +++ netinet/in.c 2001/08/12 07:32:04 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include Index: netinet/in_gif.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.11 diff -u -r1.11 in_gif.c --- netinet/in_gif.c 2001/07/02 21:02:07 1.11 +++ netinet/in_gif.c 2001/08/12 07:32:04 @@ -42,6 +42,7 @@ #include #include #include +#include #include @@ -205,7 +206,7 @@ in_gif_input(m, off, proto) struct mbuf *m; int off; - int proto; + protonum_t proto; { struct ifnet *gifp = NULL; struct ip *ip; @@ -298,7 +299,7 @@ dst = (struct sockaddr_in *)sc->gif_pdst; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); /* check for address match */ addrmatch = 0; Index: netinet/in_gif.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_gif.h,v retrieving revision 1.5 diff -u -r1.5 in_gif.h --- netinet/in_gif.h 2001/07/02 21:02:07 1.5 +++ netinet/in_gif.h 2001/08/12 07:32:05 @@ -37,7 +37,7 @@ extern int ip_gif_ttl; -void in_gif_input __P((struct mbuf *, int off, int proto)); +pr_input_t in_gif_input; int in_gif_output __P((struct ifnet *, int, struct mbuf *, struct rtentry *)); int gif_encapcheck4 __P((const struct mbuf *, int, int, void *)); Index: netinet/in_proto.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_proto.c,v retrieving revision 1.57 diff -u -r1.57 in_proto.c --- netinet/in_proto.c 2001/07/02 21:02:07 1.57 +++ netinet/in_proto.c 2001/08/12 07:32:05 @@ -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, Index: netinet/in_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v retrieving revision 1.40 diff -u -r1.40 in_rmx.c --- netinet/in_rmx.c 2001/05/11 14:37:34 1.40 +++ netinet/in_rmx.c 2001/08/12 07:32:06 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include Index: netinet/ip_divert.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_divert.c,v retrieving revision 1.50 diff -u -r1.50 ip_divert.c --- netinet/ip_divert.c 2001/07/26 19:19:48 1.50 +++ netinet/ip_divert.c 2001/08/12 07:32:07 @@ -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, protonum_t proto) { ipstat.ips_noproto++; m_freem(m); Index: netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.39 diff -u -r1.39 ip_dummynet.c --- netinet/ip_dummynet.c 2001/02/10 00:10:18 1.39 +++ netinet/ip_dummynet.c 2001/08/12 07:32:10 @@ -63,6 +63,7 @@ #include /* XXX */ #include #include +#include #include #include #include Index: netinet/ip_encap.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_encap.c,v retrieving revision 1.5 diff -u -r1.5 ip_encap.c --- netinet/ip_encap.c 2001/07/25 20:15:49 1.5 +++ netinet/ip_encap.c 2001/08/12 07:32:10 @@ -77,7 +77,6 @@ #include #include #include -#include #ifdef INET6 #include @@ -127,27 +126,17 @@ #ifdef INET void -#if __STDC__ -encap4_input(struct mbuf *m, ...) -#else -encap4_input(m, va_alist) +encap4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + protonum_t proto; { - 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 *); bzero(&s, sizeof(s)); @@ -205,7 +194,7 @@ if (match) { /* found a match, "match" has the best one */ - psw = (const struct ipprotosw *)match->psw; + psw = (const struct protosw *)match->psw; if (psw && psw->pr_input) { encap_fillarg(m, match); (*psw->pr_input)(m, off, proto); Index: netinet/ip_encap.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_encap.h,v retrieving revision 1.1 diff -u -r1.1 ip_encap.h --- netinet/ip_encap.h 2000/07/04 16:35:05 1.1 +++ netinet/ip_encap.h 2001/08/12 07:32:10 @@ -48,9 +48,10 @@ void *arg; /* passed via m->m_pkthdr.aux */ }; -void encap_init __P((void)); -void encap4_input __P((struct mbuf *, ...)); -int encap6_input __P((struct mbuf **, int *, int)); +pr_init_t encap_init; +pr_input_t encap4_input; +pr_input6_t encap6_input; + const struct encaptab *encap_attach __P((int, int, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct protosw *, void *)); Index: netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.165 diff -u -r1.165 ip_fw.c --- netinet/ip_fw.c 2001/07/02 15:50:31 1.165 +++ netinet/ip_fw.c 2001/08/12 07:32:14 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include #include Index: netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.58 diff -u -r1.58 ip_icmp.c --- netinet/ip_icmp.c 2001/06/23 17:17:58 1.58 +++ netinet/ip_icmp.c 2001/08/12 07:32:15 @@ -232,7 +232,8 @@ void icmp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + protonum_t proto; { int hlen = off; register struct icmp *icp; Index: netinet/ip_icmp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.16 diff -u -r1.16 ip_icmp.h --- netinet/ip_icmp.h 1999/12/29 04:41:01 1.16 +++ netinet/ip_icmp.h 2001/08/12 07:32:16 @@ -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)); +pr_input_t icmp_input; #endif #endif Index: netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- netinet/ip_input.c 2001/06/23 17:17:58 1.174 +++ netinet/ip_input.c 2001/08/12 07:32:19 @@ -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 = (struct protosw *)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 = (struct protosw *)inetdomain.dom_protosw; + pr < (struct protosw *)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; Index: netinet/ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.64 diff -u -r1.64 ip_mroute.c --- netinet/ip_mroute.c 2001/07/25 20:15:49 1.64 +++ netinet/ip_mroute.c 2001/08/12 07:32:22 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include @@ -111,7 +110,7 @@ rsvp_input(m, off, proto) /* XXX must fixup manually */ struct mbuf *m; int off; - int proto; + protonum_t 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 @@ -132,7 +131,7 @@ m_freem(m); } -void ipip_input(struct mbuf *m, int off, int proto) { /* XXX must fixup manually */ +void ipip_input(struct mbuf *m, int off, protonum_t proto) { /* XXX must fixup manually */ rip_input(m, off, proto); } @@ -708,7 +707,7 @@ * claimed). */ static void -mroute_encap_input(struct mbuf *m, int off, int proto) +mroute_encap_input(struct mbuf *m, int off, protonum_t proto) { struct ip *ip = mtod(m, struct ip *); int hlen = ip->ip_hl << 2; @@ -732,7 +731,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, @@ -2111,7 +2110,7 @@ rsvp_input(m, off, proto) struct mbuf *m; int off; - int proto; + protonum_t proto; { int vifi; register struct ip *ip = mtod(m, struct ip *); Index: netinet/ip_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.57 diff -u -r1.57 ip_var.h --- netinet/ip_var.h 2001/06/11 18:41:57 1.57 +++ netinet/ip_var.h 2001/08/12 07:32:22 @@ -154,19 +154,21 @@ extern int (*legal_vif_num) __P((int)); extern u_long (*ip_mcast_src) __P((int)); extern int rsvp_on; + extern struct pr_usrreqs rip_usrreqs; + +pr_ctloutput_t ip_ctloutput; +pr_drain_t ip_drain; +pr_init_t ip_init; +pr_slowtimo_t ip_slowtimo; -int ip_ctloutput __P((struct socket *, struct sockopt *sopt)); -void ip_drain __P((void)); void ip_freemoptions __P((struct ip_moptions *)); -void ip_init __P((void)); extern int (*ip_mforward) __P((struct ip *, struct ifnet *, struct mbuf *, struct ip_moptions *)); int ip_output __P((struct mbuf *, struct mbuf *, struct route *, int, struct ip_moptions *)); void ip_savecontrol __P((struct inpcb *, struct mbuf **, struct ip *, struct mbuf *)); -void ip_slowtimo __P((void)); struct mbuf * ip_srcroute __P((void)); void ip_stripoptions __P((struct mbuf *, struct mbuf *)); @@ -174,13 +176,13 @@ u_int16_t ip_randomid __P((void)); #endif -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)); -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)); +pr_ctloutput_t rip_ctloutput; +pr_ctlinput_t rip_ctlinput; +pr_init_t rip_init; +pr_input_t rip_input; +pr_output_t rip_output; +pr_input_t ipip_input; +pr_input_t rsvp_input; int ip_rsvp_init __P((struct socket *)); int ip_rsvp_done __P((void)); int ip_rsvp_vif_init __P((struct socket *, struct sockopt *)); @@ -188,8 +190,8 @@ void ip_rsvp_force_done __P((struct socket *)); #ifdef IPDIVERT -void div_init __P((void)); -void div_input __P((struct mbuf *, int, int)); +pr_init_t div_init; +pr_input_t div_input; void divert_packet __P((struct mbuf *, int, int)); extern struct pr_usrreqs div_usrreqs; extern u_int16_t ip_divert_cookie; Index: netinet/raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.80 diff -u -r1.80 raw_ip.c --- netinet/raw_ip.c 2001/07/26 19:19:48 1.80 +++ netinet/raw_ip.c 2001/08/12 07:32:23 @@ -114,7 +114,8 @@ void rip_input(m, off, proto) struct mbuf *m; - int off, proto; + int off; + protonum_t proto; { register struct ip *ip = mtod(m, struct ip *); register struct inpcb *inp; @@ -196,10 +197,10 @@ * Tack on options user may have setup with control call. */ int -rip_output(m, so, dst) +rip_output(m, so, nam) struct mbuf *m; struct socket *so; - u_long dst; + struct sockaddr *nam; { register struct ip *ip; register struct inpcb *inp = sotoinpcb(so); @@ -214,6 +215,10 @@ m_freem(m); return(EMSGSIZE); } + if (nam == NULL) { + m_freem(m); + return ENOTCONN; + } M_PREPEND(m, sizeof(struct ip), M_TRYWAIT); ip = mtod(m, struct ip *); ip->ip_tos = inp->inp_ip_tos; @@ -221,7 +226,8 @@ ip->ip_p = inp->inp_ip_p; ip->ip_len = m->m_pkthdr.len; ip->ip_src = inp->inp_laddr; - ip->ip_dst.s_addr = dst; + ip->ip_dst.s_addr + = ((struct sockaddr_in *)nam)->sin_addr.s_addr; ip->ip_ttl = inp->inp_ip_ttl; } else { if (m->m_pkthdr.len > IP_MAXPACKET) { @@ -566,22 +572,26 @@ struct mbuf *control, struct proc *p) { struct inpcb *inp = sotoinpcb(so); - register u_long dst; + struct sockaddr_in dst_addr; + if (so->so_state & SS_ISCONNECTED) { if (nam) { m_freem(m); return EISCONN; } - dst = inp->inp_faddr.s_addr; + dst_addr.sin_len = sizeof(dst_addr); + dst_addr.sin_family = AF_INET; + dst_addr.sin_port = 0; + dst_addr.sin_addr.s_addr = inp->inp_faddr.s_addr; + nam = (struct sockaddr *)&dst_addr; } else { if (nam == NULL) { m_freem(m); return ENOTCONN; } - dst = ((struct sockaddr_in *)nam)->sin_addr.s_addr; } - return rip_output(m, so, dst); + return rip_output(m, so, nam); } static int Index: netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.136 diff -u -r1.136 tcp_input.c --- netinet/tcp_input.c 2001/07/08 02:20:46 1.136 +++ netinet/tcp_input.c 2001/08/12 07:32:28 @@ -331,7 +331,8 @@ void tcp_input(m, off0, proto) register struct mbuf *m; - int off0, proto; + int off0; + protonum_t proto; { register struct tcphdr *th; register struct ip *ip = NULL; Index: netinet/tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.112 diff -u -r1.112 tcp_subr.c --- netinet/tcp_subr.c 2001/07/27 00:04:39 1.112 +++ netinet/tcp_subr.c 2001/08/12 07:32:30 @@ -1107,8 +1107,8 @@ (struct sockaddr *)ip6cp->ip6c_src, th.th_sport, cmd, notify); } else - in6_pcbnotify(&tcb, sa, 0, (struct sockaddr *)sa6_src, - 0, cmd, notify); + in6_pcbnotify(&tcb, sa, 0, (struct sockaddr *)sa6_src, 0, + cmd, notify); } #endif /* INET6 */ Index: netinet/tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.70 diff -u -r1.70 tcp_var.h --- netinet/tcp_var.h 2001/07/08 02:20:47 1.70 +++ netinet/tcp_var.h 2001/08/12 07:32:31 @@ -372,19 +372,21 @@ extern int ss_fltsz; extern int ss_fltsz_local; +pr_ctlinput_t tcp_ctlinput; +pr_ctloutput_t tcp_ctloutput; +pr_fasttimo_t tcp_fasttimo; +pr_slowtimo_t tcp_slowtimo; +pr_init_t tcp_init; +pr_drain_t tcp_drain; +pr_input_t tcp_input; + void tcp_canceltimers __P((struct tcpcb *)); struct tcpcb * tcp_close __P((struct tcpcb *)); -void tcp_ctlinput __P((int, struct sockaddr *, void *)); -int tcp_ctloutput __P((struct socket *, struct sockopt *)); struct tcpcb * tcp_drop __P((struct tcpcb *, int)); -void tcp_drain __P((void)); -void tcp_fasttimo __P((void)); struct rmxp_tao * tcp_gettaocache __P((struct inpcb *)); -void tcp_init __P((void)); -void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); void tcp_drop_syn_sent __P((struct inpcb *, int)); @@ -398,7 +400,6 @@ struct rtentry * tcp_rtlookup __P((struct inpcb *)); void tcp_setpersist __P((struct tcpcb *)); -void tcp_slowtimo __P((void)); struct tcptemp * tcp_maketemplate __P((struct tcpcb *)); void tcp_fillheaders __P((struct tcpcb *, void *, void *)); Index: netinet/udp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.93 diff -u -r1.93 udp_usrreq.c --- netinet/udp_usrreq.c 2001/07/26 19:19:48 1.93 +++ netinet/udp_usrreq.c 2001/08/12 07:32:33 @@ -151,7 +151,8 @@ void udp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + protonum_t proto; { int iphlen = off; register struct ip *ip; Index: netinet/udp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_var.h,v retrieving revision 1.23 diff -u -r1.23 udp_var.h --- netinet/udp_var.h 2001/02/18 07:10:03 1.23 +++ netinet/udp_var.h 2001/08/12 07:32:33 @@ -103,9 +103,9 @@ extern struct udpstat udpstat; extern int log_in_vain; -void udp_ctlinput __P((int, struct sockaddr *, void *)); -void udp_init __P((void)); -void udp_input __P((struct mbuf *, int, int)); +pr_ctlinput_t udp_ctlinput; +pr_init_t udp_init; +pr_input_t udp_input; void udp_notify __P((struct inpcb *inp, int errno)); int udp_shutdown __P((struct socket *so)); Index: netinet6/ah.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah.h,v retrieving revision 1.5 diff -u -r1.5 ah.h --- netinet6/ah.h 2001/06/11 12:39:03 1.5 +++ netinet6/ah.h 2001/08/12 07:32:33 @@ -79,13 +79,14 @@ #define AH_MAXSUMSIZE 16 +extern pr_input_t ah4_input; extern const struct ah_algorithm *ah_algorithm_lookup __P((int)); + /* cksum routines */ extern int ah_hdrlen __P((struct secasvar *)); extern size_t ah_hdrsiz __P((struct ipsecrequest *)); -extern void ah4_input __P((struct mbuf *, ...)); extern int ah4_output __P((struct mbuf *, struct ipsecrequest *)); extern int ah4_calccksum __P((struct mbuf *, caddr_t, size_t, const struct ah_algorithm *, struct secasvar *)); Index: netinet6/ah_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah_input.c,v retrieving revision 1.7 diff -u -r1.7 ah_input.c --- netinet6/ah_input.c 2001/06/11 12:39:04 1.7 +++ netinet6/ah_input.c 2001/08/12 07:32:35 @@ -56,6 +56,7 @@ #include #include #include +#include #include #include #include @@ -94,17 +95,13 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -ah4_input(struct mbuf *m, ...) -#else -ah4_input(m, va_alist) +ah4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + protonum_t proto; { struct ip *ip; struct ah *ah; @@ -116,15 +113,8 @@ struct secasvar *sav = NULL; u_int16_t nxt; size_t hlen; - int off, proto; - va_list ap; size_t stripsiz = 0; - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); - #ifndef PULLDOWN_TEST if (m->m_len < off + sizeof(struct newah)) { m = m_pullup(m, off + sizeof(struct newah)); @@ -999,6 +989,7 @@ } else { m = NULL; ip6 = NULL; + off = 0; } if (ip6) { Index: netinet6/esp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp.h,v retrieving revision 1.4 diff -u -r1.4 esp.h --- netinet6/esp.h 2001/06/11 12:39:04 1.4 +++ netinet6/esp.h 2001/08/12 07:32:35 @@ -97,8 +97,8 @@ extern int esp_max_ivlen __P((void)); /* crypt routines */ +extern pr_input_t esp4_input; extern int esp4_output __P((struct mbuf *, struct ipsecrequest *)); -extern void esp4_input __P((struct mbuf *, ...)); extern size_t esp_hdrsiz __P((struct ipsecrequest *)); extern int esp_schedule __P((const struct esp_algorithm *, struct secasvar *)); Index: netinet6/esp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp_input.c,v retrieving revision 1.7 diff -u -r1.7 esp_input.c --- netinet6/esp_input.c 2001/06/11 12:39:05 1.7 +++ netinet6/esp_input.c 2001/08/12 07:32:37 @@ -56,6 +56,7 @@ #include #include #include +#include #include #include #ifdef INET6 @@ -97,17 +98,13 @@ ? sizeof(struct newesp) : sizeof(struct esp)) #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -esp4_input(struct mbuf *m, ...) -#else -esp4_input(m, va_alist) +esp4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + protonum_t proto; { struct ip *ip; struct esp *esp; @@ -120,13 +117,6 @@ int ivlen; size_t hlen; size_t esplen; - va_list ap; - int off, proto; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); /* sanity check for alignment. */ if (off % 4 != 0 || m->m_pkthdr.len % 4 != 0) { @@ -924,6 +914,7 @@ } else { m = NULL; ip6 = NULL; + off = 0; } if (ip6) { Index: netinet6/esp_rijndael.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp_rijndael.c,v retrieving revision 1.1 diff -u -r1.1 esp_rijndael.c --- netinet6/esp_rijndael.c 2001/06/11 12:39:05 1.1 +++ netinet6/esp_rijndael.c 2001/08/12 07:32:37 @@ -35,6 +35,7 @@ #include #include +#include #include #include Index: netinet6/in6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6.c,v retrieving revision 1.15 diff -u -r1.15 in6.c --- netinet6/in6.c 2001/08/03 19:10:31 1.15 +++ netinet6/in6.c 2001/08/12 07:32:41 @@ -79,6 +79,7 @@ #include #include #include +#include #include #include @@ -1789,8 +1790,8 @@ static char ip6buf[8][48]; int i; char *cp; - u_short *a = (u_short *)addr; - u_char *d; + const u_short *a = (const u_short *)addr; + const u_char *d; int dcolon = 0; ip6round = (ip6round + 1) & 7; @@ -1819,7 +1820,7 @@ a++; continue; } - d = (u_char *)a; + d = (const u_char *)a; *cp++ = digits[*d >> 4]; *cp++ = digits[*d++ & 0xf]; *cp++ = digits[*d >> 4]; Index: netinet6/in6_gif.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_gif.c,v retrieving revision 1.5 diff -u -r1.5 in6_gif.c --- netinet6/in6_gif.c 2001/06/11 12:39:05 1.5 +++ netinet6/in6_gif.c 2001/08/12 07:32:41 @@ -41,7 +41,7 @@ #include #include #include - +#include #include #include @@ -302,7 +302,7 @@ dst = (struct sockaddr_in6 *)sc->gif_pdst; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip6), (caddr_t)&ip6); + m_copydata(m, 0, sizeof(ip6), (caddr_t)&ip6); /* check for address match */ addrmatch = 0; Index: netinet6/in6_ifattach.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v retrieving revision 1.7 diff -u -r1.7 in6_ifattach.c --- netinet6/in6_ifattach.c 2001/08/04 17:10:13 1.7 +++ netinet6/in6_ifattach.c 2001/08/12 07:32:43 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include Index: netinet6/in6_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.c,v retrieving revision 1.16 diff -u -r1.16 in6_pcb.c --- netinet6/in6_pcb.c 2001/08/04 17:10:14 1.16 +++ netinet6/in6_pcb.c 2001/08/12 07:32:45 @@ -765,7 +765,8 @@ void in6_pcbnotify(head, dst, fport_arg, src, lport_arg, cmd, notify) struct inpcbhead *head; - struct sockaddr *dst, *src; + struct sockaddr *dst; + const struct sockaddr *src; u_int fport_arg, lport_arg; int cmd; void (*notify) __P((struct inpcb *, int)); Index: netinet6/in6_pcb.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.h,v retrieving revision 1.5 diff -u -r1.5 in6_pcb.h --- netinet6/in6_pcb.h 2001/08/04 17:10:14 1.5 +++ netinet6/in6_pcb.h 2001/08/12 07:32:45 @@ -91,7 +91,7 @@ struct in6_addr *, u_int, struct in6_addr *, u_int, int, struct ifnet *)); void in6_pcbnotify __P((struct inpcbhead *, struct sockaddr *, - u_int, struct sockaddr *, u_int, int, + u_int, const struct sockaddr *, u_int, int, void (*)(struct inpcb *, int))); void in6_rtchange __P((struct inpcb *, int)); int in6_setpeeraddr __P((struct socket *so, struct sockaddr **nam)); Index: netinet6/in6_prefix.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_prefix.c,v retrieving revision 1.7 diff -u -r1.7 in6_prefix.c --- netinet6/in6_prefix.c 2001/06/11 12:39:05 1.7 +++ netinet6/in6_prefix.c 2001/08/12 07:32:47 @@ -74,6 +74,7 @@ #include #include #include +#include #include Index: netinet6/in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.4 diff -u -r1.4 in6_rmx.c --- netinet6/in6_rmx.c 2001/06/11 12:39:05 1.4 +++ netinet6/in6_rmx.c 2001/08/12 07:32:48 @@ -82,6 +82,7 @@ #include #include #include +#include #include #include Index: netinet6/ip6_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_fw.c,v retrieving revision 1.13 diff -u -r1.13 ip6_fw.c --- netinet6/ip6_fw.c 2001/06/28 05:18:31 1.13 +++ netinet6/ip6_fw.c 2001/08/12 07:32:50 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include Index: netinet6/ip6_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_var.h,v retrieving revision 1.7 diff -u -r1.7 ip6_var.h --- netinet6/ip6_var.h 2001/06/11 12:39:05 1.7 +++ netinet6/ip6_var.h 2001/08/12 07:32:51 @@ -332,23 +332,22 @@ struct ip6_pktopts *ip6_copypktopts __P((struct ip6_pktopts *, int)); int ip6_optlen __P((struct inpcb *)); -int route6_input __P((struct mbuf **, int *, int)); +pr_input6_t route6_input; -void frag6_init __P((void)); -int frag6_input __P((struct mbuf **, int *, int)); -void frag6_slowtimo __P((void)); -void frag6_drain __P((void)); +pr_init_t frag6_init; +pr_input6_t frag6_input; +pr_slowtimo_t frag6_slowtimo; +pr_drain_t frag6_drain; -void rip6_init __P((void)); -int rip6_input __P((struct mbuf **mp, int *offp, int proto)); -void rip6_ctlinput __P((int, struct sockaddr *, void *)); -int rip6_ctloutput __P((struct socket *so, struct sockopt *sopt)); -int rip6_output __P((struct mbuf *, ...)); -int rip6_usrreq __P((struct socket *, - int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *)); +pr_init_t rip6_init; +pr_input6_t rip6_input; +pr_ctlinput_t rip6_ctlinput; +pr_ctloutput_t rip6_ctloutput; +pr_output_t rip6_output; +pr_usrreq_t rip6_usrreq; +pr_input6_t dest6_input; +pr_input6_t none_input; -int dest6_input __P((struct mbuf **, int *, int)); -int none_input __P((struct mbuf **, int *, int)); #endif /* _KERNEL */ #endif /* !_NETINET6_IP6_VAR_H_ */ Index: netinet6/ip6protosw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6protosw.h,v retrieving revision 1.6 diff -u -r1.6 ip6protosw.h --- netinet6/ip6protosw.h 2001/06/11 12:39:05 1.6 +++ netinet6/ip6protosw.h 2001/08/12 07:32:51 @@ -128,30 +128,20 @@ short pr_flags; /* see below */ /* protocol-protocol hooks */ - int (*pr_input) /* input to protocol (from below) */ - __P((struct mbuf **, int *, int)); - int (*pr_output) /* output to protocol (from above) */ - __P((struct mbuf *, ...)); - void (*pr_ctlinput) /* control input (from below) */ - __P((int, struct sockaddr *, void *)); - int (*pr_ctloutput) /* control output (from above) */ - __P((struct socket *, struct sockopt *)); + pr_input6_t *pr_input; /* input to protocol (from below) */ + pr_output_t *pr_output; /* output to protocol (from above) */ + pr_ctlinput_t *pr_ctlinput; /* control input (from below) */ + pr_ctloutput_t *pr_ctloutput; /* control output (from above) */ /* user-protocol hook */ - int (*pr_usrreq) /* user request: see list below */ - __P((struct socket *, int, struct mbuf *, - struct mbuf *, struct mbuf *, struct proc *)); + pr_usrreq_t *pr_usrreq; /* user request: see list below */ /* utility hooks */ - void (*pr_init) /* initialization hook */ - __P((void)); + pr_init_t *pr_init; + pr_fasttimo_t *pr_fasttimo; /* fast timeout (200ms) */ + pr_slowtimo_t *pr_slowtimo; /* slow timeout (500ms) */ + pr_drain_t *pr_drain; /* flush any excess space possible */ - void (*pr_fasttimo) /* fast timeout (200ms) */ - __P((void)); - void (*pr_slowtimo) /* slow timeout (500ms) */ - __P((void)); - void (*pr_drain) /* flush any excess space possible */ - __P((void)); struct pr_usrreqs *pr_usrreqs; /* supersedes pr_usrreq() */ struct pfil_head pr_pfh; }; Index: netinet6/ipcomp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ipcomp.h,v retrieving revision 1.2 diff -u -r1.2 ipcomp.h --- netinet6/ipcomp.h 2001/06/11 12:39:06 1.2 +++ netinet6/ipcomp.h 2001/08/12 07:32:51 @@ -62,9 +62,10 @@ size_t minplen; /* minimum required length for compression */ }; +extern pr_input_t ipcomp4_input; + struct ipsecrequest; extern const struct ipcomp_algorithm *ipcomp_algorithm_lookup __P((int)); -extern void ipcomp4_input __P((struct mbuf *, ...)); extern int ipcomp4_output __P((struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ Index: netinet6/ipcomp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ipcomp_input.c,v retrieving revision 1.2 diff -u -r1.2 ipcomp_input.c --- netinet6/ipcomp_input.c 2001/06/11 12:39:06 1.2 +++ netinet6/ipcomp_input.c 2001/08/12 07:32:52 @@ -83,17 +83,13 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -ipcomp4_input(struct mbuf *m, ...) -#else -ipcomp4_input(m, va_alist) +ipcomp4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + protonum_t proto; { struct mbuf *md; struct ip *ip; @@ -105,13 +101,6 @@ int error; size_t newlen, olen; struct secasvar *sav = NULL; - int off, proto; - va_list ap; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); if (m->m_pkthdr.len < off + sizeof(struct ipcomp)) { ipseclog((LOG_DEBUG, "IPv4 IPComp input: assumption failed " Index: netinet6/nd6_nbr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6_nbr.c,v retrieving revision 1.10 diff -u -r1.10 nd6_nbr.c --- netinet6/nd6_nbr.c 2001/06/19 14:48:02 1.10 +++ netinet6/nd6_nbr.c 2001/08/12 07:32:54 @@ -46,6 +46,7 @@ #include #include #include +#include #include #include Index: netinet6/nd6_rtr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6_rtr.c,v retrieving revision 1.8 diff -u -r1.8 nd6_rtr.c --- netinet6/nd6_rtr.c 2001/06/18 11:37:06 1.8 +++ netinet6/nd6_rtr.c 2001/08/12 07:32:57 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include Index: netinet6/raw_ip6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/raw_ip6.c,v retrieving revision 1.12 diff -u -r1.12 raw_ip6.c --- netinet6/raw_ip6.c 2001/07/26 19:19:49 1.12 +++ netinet6/raw_ip6.c 2001/08/12 07:32:58 @@ -286,7 +286,7 @@ sa6_src = &sa6_any; } - (void) in6_pcbnotify(&ripcb, sa, 0, (struct sockaddr *)sa6_src, + (void) in6_pcbnotify(&ripcb, sa, 0, (const struct sockaddr *)sa6_src, 0, cmd, notify); } @@ -295,16 +295,12 @@ * Tack on options user may have setup with control call. */ int -#if __STDC__ -rip6_output(struct mbuf *m, ...) -#else -rip6_output(m, va_alist) +rip6_output(m, so, sockaddr) struct mbuf *m; - va_dcl -#endif -{ struct socket *so; - struct sockaddr_in6 *dstsock; + struct sockaddr *sockaddr; +{ + struct sockaddr_in6 *dstsock = (struct sockaddr_in6 *)sockaddr; struct mbuf *control; struct in6_addr *dst; struct ip6_hdr *ip6; @@ -315,14 +311,12 @@ struct ifnet *oifp = NULL; int type = 0, code = 0; /* for ICMPv6 output statistics only */ int priv = 0; - va_list ap; - - va_start(ap, m); - so = va_arg(ap, struct socket *); - dstsock = va_arg(ap, struct sockaddr_in6 *); - control = va_arg(ap, struct mbuf *); - va_end(ap); + if (m->m_type == MT_CONTROL) { + control = m; + m = m->m_next; + } else + control = NULL; in6p = sotoin6pcb(so); priv = 0; @@ -718,7 +712,11 @@ dst->sin6_scope_id = scope6_addr2default(&dst->sin6_addr); } #endif - return rip6_output(m, so, dst, control); + if (control) { + control->m_next = m; + m = control; + } + return rip6_output(m, so, (struct sockaddr *)dst); } struct pr_usrreqs rip6_usrreqs = { Index: netinet6/route6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/route6.c,v retrieving revision 1.4 diff -u -r1.4 route6.c --- netinet6/route6.c 2001/06/11 12:39:06 1.4 +++ netinet6/route6.c 2001/08/12 07:32:58 @@ -38,6 +38,7 @@ #include #include #include +#include #include Index: netinet6/udp6_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.16 diff -u -r1.16 udp6_usrreq.c --- netinet6/udp6_usrreq.c 2001/07/26 19:19:49 1.16 +++ netinet6/udp6_usrreq.c 2001/08/12 07:33:00 @@ -456,10 +456,11 @@ bzero(&uh, sizeof(uh)); m_copydata(m, off, sizeof(*uhp), (caddr_t)&uh); - (void) in6_pcbnotify(&udb, sa, uh.uh_dport, ip6cp->ip6c_src, + (void) in6_pcbnotify(&udb, sa, uh.uh_dport, + (const struct sockaddr *)ip6cp->ip6c_src, uh.uh_sport, cmd, notify); } else - (void) in6_pcbnotify(&udb, sa, 0, (struct sockaddr *)&sa6_src, + (void) in6_pcbnotify(&udb, sa, 0, (const struct sockaddr *)&sa6_src, 0, cmd, notify); } Index: netipx/ipx_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netipx/ipx_ip.c,v retrieving revision 1.27 diff -u -r1.27 ipx_ip.c --- netipx/ipx_ip.c 2001/02/04 13:13:10 1.27 +++ netipx/ipx_ip.c 2001/08/12 07:33:00 @@ -162,9 +162,10 @@ static int ipxip_hold_input; void -ipxip_input(m, hlen) +ipxip_input(m, hlen, proto) register struct mbuf *m; int hlen; + protonum_t proto; /* ignored */ { register struct ip *ip; register struct ipx *ipx; Index: netipx/ipx_ip.h =================================================================== RCS file: /home/ncvs/src/sys/netipx/ipx_ip.h,v retrieving revision 1.14 diff -u -r1.14 ipx_ip.h --- netipx/ipx_ip.h 1999/12/29 04:46:08 1.14 +++ netipx/ipx_ip.h 2001/08/12 07:33:00 @@ -51,8 +51,8 @@ #ifdef _KERNEL -void ipxip_ctlinput __P((int cmd, struct sockaddr *sa, void *arg)); -void ipxip_input __P((struct mbuf *m, int hlen)); +pr_ctlinput_t ipxip_ctlinput; +pr_input_t ipxip_input; int ipxip_route __P((struct socket *so, struct sockopt *sopt)); #endif Index: netkey/keysock.c =================================================================== RCS file: /home/ncvs/src/sys/netkey/keysock.c,v retrieving revision 1.6 diff -u -r1.6 keysock.c --- netkey/keysock.c 2001/06/11 12:39:10 1.6 +++ netkey/keysock.c 2001/08/12 07:33:01 @@ -71,23 +71,14 @@ * key_output() */ int -#if __STDC__ -key_output(struct mbuf *m, ...) -#else -key_output(m, va_alist) +key_output(m, so, sockaddr) struct mbuf *m; - va_dcl -#endif + struct socket *so; + struct sockaddr *sockaddr; /* ignored */ { struct sadb_msg *msg; int len, error = 0; int s; - struct socket *so; - va_list ap; - - va_start(ap, m); - so = va_arg(ap, struct socket *); - va_end(ap); if (m == 0) panic("key_output: NULL pointer was passed.\n"); Index: netkey/keysock.h =================================================================== RCS file: /home/ncvs/src/sys/netkey/keysock.h,v retrieving revision 1.5 diff -u -r1.5 keysock.h --- netkey/keysock.h 2000/07/04 16:35:14 1.5 +++ netkey/keysock.h 2001/08/12 07:33:02 @@ -71,7 +71,7 @@ extern struct pfkeystat pfkeystat; -extern int key_output __P((struct mbuf *, ...)); +extern pr_output_t key_output; extern int key_usrreq __P((struct socket *, int, struct mbuf *, struct mbuf *, struct mbuf *)); Index: sys/mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.83 diff -u -r1.83 mbuf.h --- sys/mbuf.h 2001/07/26 18:47:40 1.83 +++ sys/mbuf.h 2001/08/12 07:33:04 @@ -434,7 +434,7 @@ void m_extadd(struct mbuf *, caddr_t, u_int, void (*free)(caddr_t, void *), void *, short, int); void m_copyback(struct mbuf *, int, int, caddr_t); -void m_copydata(struct mbuf *, int, int, caddr_t); +void m_copydata(const struct mbuf *, int, int, caddr_t); struct mbuf *m_copym(struct mbuf *, int, int, int); struct mbuf *m_copypacket(struct mbuf *, int); struct mbuf *m_devget(char *, int, int, struct ifnet *, Index: sys/protosw.h =================================================================== RCS file: /home/ncvs/src/sys/sys/protosw.h,v retrieving revision 1.34 diff -u -r1.34 protosw.h --- sys/protosw.h 2001/08/10 23:17:22 1.34 +++ sys/protosw.h 2001/08/12 07:33:05 @@ -73,9 +73,13 @@ * similar to the vnode VOP interface. */ /* USE THESE FOR YOUR PROTOTYPES ! */ -typedef void pr_input_t (struct mbuf *, int); + +typedef short int protonum_t; + +typedef void pr_input_t (struct mbuf *, int, protonum_t); +typedef int pr_input6_t (struct mbuf **, int*, int); /* XXX FIX THIS */ typedef void pr_in_input_t (struct mbuf *, int, int); /* XXX FIX THIS */ -typedef int pr_output_t (struct mbuf *, struct socket *); +typedef int pr_output_t (struct mbuf *, struct socket *, struct sockaddr *); typedef void pr_ctlinput_t (int, struct sockaddr *, void *); typedef int pr_ctloutput_t (struct socket *, struct sockopt *); typedef void pr_init_t (void); @@ -83,6 +87,9 @@ typedef void pr_slowtimo_t (void); typedef void pr_drain_t (void); +typedef int pr_usrreq_t(struct socket *, int, struct mbuf *, + struct mbuf *, struct mbuf *, struct proc *); + struct protosw { short pr_type; /* socket type used for */ @@ -95,7 +102,7 @@ pr_ctlinput_t *pr_ctlinput; /* control input (from below) */ pr_ctloutput_t *pr_ctloutput; /* control output (from above) */ /* user-protocol hook */ - void *pr_ousrreq; + pr_usrreq_t *pr_ousrreq; /* utility hooks */ pr_init_t *pr_init; pr_fasttimo_t *pr_fasttimo; /* fast timeout (200ms) */ --------------8E304995AC7CC80311DE7C03-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 2:40: 8 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 44EAA37B407 for ; Sun, 12 Aug 2001 02:40:06 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 643544B20; Sun, 12 Aug 2001 18:40:02 +0900 (JST) To: Julian Elischer Cc: net@freebsd.org In-reply-to: julian's message of Sun, 12 Aug 2001 00:41:02 MST. <3B76330E.86A0B689@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: Sun, 12 Aug 2001 18:40:02 +0900 Message-ID: <4246.997609202@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 >When KAME was added the mesh was less that perfect but there was so much to >be done that some shortcuts needed to be taken. > >now that time has passed some of these can be cleaned up. > >1/ Merging ipprotosw.h and protosw.h >2/ removal of all varargs stuff from the kernel >(this revealing the mismatched prototypes they were hiding) >removal of lotso warnings from the KAME stuff. the change does add pain to KAME integration side on upgrades. note that KAME codebase uses the same code across multiple *BSDs. please don't do this. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 2:51:32 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 0E16B37B40C for ; Sun, 12 Aug 2001 02:51:29 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EED454B21; Sun, 12 Aug 2001 18:51:27 +0900 (JST) To: Julian Elischer , net@freebsd.org In-reply-to: itojun's message of Sun, 12 Aug 2001 18:40:02 +0900. <4246.997609202@itojun.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: Sun, 12 Aug 2001 18:51:27 +0900 Message-ID: <4382.997609887@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 >>When KAME was added the mesh was less that perfect but there was so much to >>be done that some shortcuts needed to be taken. >> >>now that time has passed some of these can be cleaned up. >> >>1/ Merging ipprotosw.h and protosw.h >>2/ removal of all varargs stuff from the kernel >>(this revealing the mismatched prototypes they were hiding) >>removal of lotso warnings from the KAME stuff. > > the change does add pain to KAME integration side on upgrades. > note that KAME codebase uses the same code across multiple *BSDs. > please don't do this. also, IIRC, ipprotosw.h was added just for freebsd, as a result of some "code review" between shin@kame and other folks on freebsd mailig lists. some of you asked for it. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 5:41: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id EB26237B409 for ; Sun, 12 Aug 2001 05:40:54 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f7CCefa48172; Sun, 12 Aug 2001 21:40:43 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: net@FreeBSD.org In-Reply-To: <20010812120456.G661@daemon.ninth-circle.org> References: <20010809082042.C1448@daemon.ninth-circle.org> <20010810013103P.matusita@jp.FreeBSD.org> <20010812120456.G661@daemon.ninth-circle.org> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 22 From: Makoto MATSUSHITA To: asmodai@wxs.nl Subject: Re: BIND 8.2.4, dynamic DNS feature is broken Date: Sun, 12 Aug 2001 21:40:21 +0900 Message-Id: <20010812214021M.matusita@jp.FreeBSD.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 asmodai> Could you rebuild named as well, just in case? Yes, I've done as follows: rm -rf /usr/obj/* cd /usr/src/lib/libbind make obj; make depend; make cd /usr/src/lib/libisc make obj; make depend; make cd /usr/src/usr.sbin/named make obj; make depend; make; make install Anything goes wrong? I'm sure with buildlog that new named does link newly created libbind. asmodai> So the DRCNTDEC(tmpdp); is what triggers this ns_panic. Ya, but I wonder why 'tmpdp' goes wrong... -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 10:15:42 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 9B4A937B40C for ; Sun, 12 Aug 2001 10:15:34 -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 KAA97474; Sun, 12 Aug 2001 10:12:20 -0700 (PDT) Message-ID: <3B76B6D7.CDF0CFCF@elischer.org> Date: Sun, 12 Aug 2001 10:03: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: itojun@iijlab.net Cc: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <4382.997609887@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 itojun@iijlab.net wrote: > > also, IIRC, ipprotosw.h was added just for freebsd, as a result of > some "code review" between shin@kame and other folks on freebsd > mailig lists. some of you asked for it. we asked for it for "until after the next release" which was 4.0 or something. (I can't remember which) > > itojun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ 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 12 10:15:48 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 649C137B409 for ; Sun, 12 Aug 2001 10:15:36 -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 KAA97472; Sun, 12 Aug 2001 10:10:44 -0700 (PDT) Message-ID: <3B76B677.337B5E88@elischer.org> Date: Sun, 12 Aug 2001 10:01:43 -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: itojun@iijlab.net Cc: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <4382.997609887@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 itojun@iijlab.net wrote: > > >>When KAME was added the mesh was less that perfect but there was so much to > >>be done that some shortcuts needed to be taken. > >> > >>now that time has passed some of these can be cleaned up. > >> > >>1/ Merging ipprotosw.h and protosw.h > >>2/ removal of all varargs stuff from the kernel > >>(this revealing the mismatched prototypes they were hiding) > >>removal of lotso warnings from the KAME stuff. > > > > the change does add pain to KAME integration side on upgrades. > > note that KAME codebase uses the same code across multiple *BSDs. > > please don't do this. > > also, IIRC, ipprotosw.h was added just for freebsd, as a result of > some "code review" between shin@kame and other folks on freebsd > mailig lists. some of you asked for it. Well what is there now is plainly unacceptable I think that it was asked for as a VERY SHORT TERM hack. But it has been there a long time... I see no reasons so far to not make most of these changes.. 1/ removal of "control" argument from rip6_input and prepend control mbuf to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto type for input. (I have not confirmed that the information in control is a valid mbuf but it is an mbuf pointer). 2/ remove all var-args.. This is a disgusting hach that makes it impossible for the compiler to catch mismatched functions and arguments. NetBSD should know better than this.. they changed it.. they can bear the costs of compatibility.. we are NOT going to do that. 3/ define all prototypes in terms of predefined types to allow the compiler to catch wrong assignments quicker (or to change them quicker). (this was planned a long time ago but not done for reasons I forget) 4/ Addition of the "proto" field to output to allow ipprotosw to be completely removed. (the special type for that filed need not be done as I only did that to ensure that KAME was not using it somewhere to pass something OTHER than an proto type.) (other protocols can ignore this field). You have had a long time to clean up the mess, and some of these fixes needed to be made to the base code for a long time. We cannot hold off making them forever because of KAME. Unless given a better excuse for the mess other than "It'll be inconvenient" I propose to commit these cleanups in 1 week. (minus the protonum_t change) If KAME applies something similar first then they can the choice as to how are done. Mandatory features: remove ipprotosw remove varargs ALL entries to protosw to conform exactly to their prototypes. (no error messages) -error messages from kame code is costing me hours as I do the KSE work as I see them going past and have to check each time that they are the same old ones and that there are no new ones amongst them- Fix all case of warnings about "discarding 'const' " (or whatever the message is). "Pass me that axe poul-henning" > > itojun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ 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 12 10:35:41 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 CAEFB37B405 for ; Sun, 12 Aug 2001 10:35:32 -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 KAA97539; Sun, 12 Aug 2001 10:21:20 -0700 (PDT) Message-ID: <3B76B8F3.1AC69B88@elischer.org> Date: Sun, 12 Aug 2001 10:12: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: itojun@iijlab.net Cc: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <4382.997609887@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 itojun@iijlab.net wrote: > > >>When KAME was added the mesh was less that perfect but there was so much to > >>be done that some shortcuts needed to be taken. > >> > >>now that time has passed some of these can be cleaned up. > >> > >>1/ Merging ipprotosw.h and protosw.h > >>2/ removal of all varargs stuff from the kernel > >>(this revealing the mismatched prototypes they were hiding) > >>removal of lotso warnings from the KAME stuff. > > > > the change does add pain to KAME integration side on upgrades. > > note that KAME codebase uses the same code across multiple *BSDs. > > please don't do this. > > also, IIRC, ipprotosw.h was added just for freebsd, as a result of > some "code review" between shin@kame and other folks on freebsd > mailig lists. some of you asked for it. Please note that the ip6protosw is ALSO very broken protosw is supposed to be a "protocol independent" structure. It defines entrypoints that are called by PROTOCOL INDEPENDENT CODE. Either IPv6 should be taught to conform to protosw (exactly) or the definition of protosw and the protocol independent code should be changed to take into account the needs of IPv6. Having a separate version of the struct for IPv6 is also unacceptable and I'll have a go at fixing that soon if you guys don't do so first.. these interfaces are FIXED for a particular release of the software. ALL USERS of the interfaces must conform to the (single) definition of the interface.. "rolling your own" is only an option in SHORT development periods (e.g 2 months). For longer periods, either the interface or the code should change. i.e. add an input2 entry to the structure with different semantics and teach the protocol independent code how to deal with it, or REALLY prove to yourself and us that the interface is deficient and needs to be changed. (be prepared to also change all the other protocols so that they conform to the new interface). > > itojun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ 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 12 11:56:34 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 D175837B407 for ; Sun, 12 Aug 2001 11:55:38 -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 LAA97859; Sun, 12 Aug 2001 11:59:01 -0700 (PDT) Message-ID: <3B76CFD3.4C6D4DDE@elischer.org> Date: Sun, 12 Aug 2001 11:49:55 -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: itojun@iijlab.net, net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <4382.997609887@itojun.org> <3B76B8F3.1AC69B88@elischer.org> Content-Type: multipart/mixed; boundary="------------368BE1ACB0C8DBFA3CF8FDC2" 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. --------------368BE1ACB0C8DBFA3CF8FDC2 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Julian Elischer wrote: Here is the patch I will consider committing in a week (unless I see these issues being handled elsewhere) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v --------------368BE1ACB0C8DBFA3CF8FDC2 Content-Type: text/plain; charset=iso-8859-2; name="protosw.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="protosw.diff" ? i386/conf/LINT Index: contrib/ipfilter/netinet/mlfk_ipl.c =================================================================== RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/mlfk_ipl.c,v retrieving revision 1.9 diff -u -r1.9 mlfk_ipl.c --- contrib/ipfilter/netinet/mlfk_ipl.c 2001/03/26 12:41:18 1.9 +++ contrib/ipfilter/netinet/mlfk_ipl.c 2001/08/12 18:50:37 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include Index: kern/uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.86 diff -u -r1.86 uipc_mbuf.c --- kern/uipc_mbuf.c 2001/06/22 06:34:59 1.86 +++ kern/uipc_mbuf.c 2001/08/12 18:50:43 @@ -303,7 +303,7 @@ * continuing for "len" bytes, into the indicated buffer. */ void -m_copydata(struct mbuf *m, int off, int len, caddr_t cp) +m_copydata(const struct mbuf *m, int off, int len, caddr_t cp) { unsigned count; Index: net/if_faith.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_faith.c,v retrieving revision 1.6 diff -u -r1.6 if_faith.c --- net/if_faith.c 2001/07/05 14:42:54 1.6 +++ net/if_faith.c 2001/08/12 18:50:49 @@ -58,6 +58,7 @@ #include #include #include +#include #include #include Index: net/if_gif.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_gif.c,v retrieving revision 1.12 diff -u -r1.12 if_gif.c --- net/if_gif.c 2001/07/02 21:02:05 1.12 +++ net/if_gif.c 2001/08/12 18:50:49 @@ -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, @@ -110,7 +109,7 @@ }; #endif #ifdef INET6 -extern struct domain6 inet6domain; +extern struct domain inet6domain; struct ip6protosw in6_gif_protosw = { SOCK_RAW, &inet6domain, 0/*IPPROTO_IPV[46]*/, PR_ATOMIC|PR_ADDR, in6_gif_input, rip6_output, 0, rip6_ctloutput, @@ -321,7 +320,7 @@ } /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); switch (ip.ip_v) { #ifdef INET @@ -571,6 +570,9 @@ &(((struct if_laddrreq *)data)->addr); dst = (struct sockaddr *) &(((struct if_laddrreq *)data)->dstaddr); + break; + default: + panic("gif_ioctl"); } /* sa_family must be equal */ Index: net/if_stf.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.9 diff -u -r1.9 if_stf.c --- net/if_stf.c 2001/07/02 21:02:05 1.9 +++ net/if_stf.c 2001/08/12 18:50:49 @@ -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, @@ -247,7 +246,7 @@ return 0; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); if (ip.ip_v != 4) return 0; @@ -531,14 +530,11 @@ } void -#if __STDC__ -in_stf_input(struct mbuf *m, ...) -#else -in_stf_input(m, va_alist) +in_stf_input(m, off, proto) struct mbuf *m; -#endif + int off; + int proto; { - int off, proto; struct stf_softc *sc; struct ip *ip; struct ip6_hdr *ip6; @@ -546,12 +542,6 @@ int len, isr; struct ifqueue *ifq = NULL; struct ifnet *ifp; - va_list ap; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); if (proto != IPPROTO_IPV6) { m_freem(m); Index: net/if_stf.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_stf.h,v retrieving revision 1.1 diff -u -r1.1 if_stf.h --- net/if_stf.h 2000/07/04 16:35:04 1.1 +++ net/if_stf.h 2001/08/12 18:50:49 @@ -33,6 +33,6 @@ #ifndef _NET_IF_STF_H_ #define _NET_IF_STF_H_ -void in_stf_input __P((struct mbuf *, ...)); +pr_input_t in_stf_input; #endif /* _NET_IF_STF_H_ */ Index: net/net_osdep.h =================================================================== RCS file: /home/ncvs/src/sys/net/net_osdep.h,v retrieving revision 1.5 diff -u -r1.5 net_osdep.h --- net/net_osdep.h 2001/06/11 12:38:58 1.5 +++ net/net_osdep.h 2001/08/12 18:50:49 @@ -195,6 +195,7 @@ * - protosw for IPv4 (sys/netinet) * FreeBSD4: struct ipprotosw in netinet/ipprotosw.h * others: struct protosw in sys/protosw.h + * (including FreeBSD5) * * - protosw in general. * NetBSD 1.5 has extra member for ipfilter (netbsd-current dropped Index: net/raw_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/net/raw_usrreq.c,v retrieving revision 1.19 diff -u -r1.19 raw_usrreq.c --- net/raw_usrreq.c 2000/10/29 16:06:43 1.19 +++ net/raw_usrreq.c 2001/08/12 18:50:49 @@ -249,15 +249,14 @@ error = EISCONN; goto release; } - rp->rcb_faddr = nam; } else if (rp->rcb_faddr == 0) { error = ENOTCONN; goto release; + } else { + nam = rp->rcb_faddr; } - error = (*so->so_proto->pr_output)(m, so); + error = (*so->so_proto->pr_output)(m, so, nam); m = NULL; - if (nam) - rp->rcb_faddr = 0; release: if (m != NULL) m_freem(m); Index: net/rtsock.c =================================================================== RCS file: /home/ncvs/src/sys/net/rtsock.c,v retrieving revision 1.55 diff -u -r1.55 rtsock.c --- net/rtsock.c 2001/08/02 19:56:29 1.55 +++ net/rtsock.c 2001/08/12 18:50:50 @@ -73,7 +73,7 @@ static int rt_xaddrs __P((caddr_t, caddr_t, struct rt_addrinfo *)); static int sysctl_dumpentry __P((struct radix_node *rn, void *vw)); static int sysctl_iflist __P((int af, struct walkarg *w)); -static int route_output __P((struct mbuf *, struct socket *)); +static pr_output_t route_output; static void rt_setmetrics __P((u_long, struct rt_metrics *, struct rt_metrics *)); /* Sleazy use of local variables throughout file, warning!!!! */ @@ -264,18 +264,34 @@ } static struct pr_usrreqs route_usrreqs = { - rts_abort, pru_accept_notsupp, rts_attach, rts_bind, rts_connect, - pru_connect2_notsupp, pru_control_notsupp, rts_detach, rts_disconnect, - pru_listen_notsupp, rts_peeraddr, pru_rcvd_notsupp, pru_rcvoob_notsupp, - rts_send, pru_sense_null, rts_shutdown, rts_sockaddr, - sosend, soreceive, sopoll + rts_abort, + pru_accept_notsupp, + rts_attach, + rts_bind, + rts_connect, + pru_connect2_notsupp, + pru_control_notsupp, + rts_detach, + rts_disconnect, + pru_listen_notsupp, + rts_peeraddr, + pru_rcvd_notsupp, + pru_rcvoob_notsupp, + rts_send, + pru_sense_null, + rts_shutdown, + rts_sockaddr, + sosend, + soreceive, + sopoll }; /*ARGSUSED*/ static int -route_output(m, so) +route_output(m, so, addr) register struct mbuf *m; struct socket *so; + struct sockaddr *addr; { register struct rt_msghdr *rtm = 0; register struct rtentry *rt = 0; Index: netinet/igmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/igmp.c,v retrieving revision 1.31 diff -u -r1.31 igmp.c --- netinet/igmp.c 2001/06/23 17:17:58 1.31 +++ netinet/igmp.c 2001/08/12 18:50:51 @@ -150,7 +150,8 @@ void igmp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + int proto; { register int iphlen = off; register struct igmp *igmp; Index: netinet/igmp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/igmp_var.h,v retrieving revision 1.17 diff -u -r1.17 igmp_var.h --- netinet/igmp_var.h 1999/12/29 04:40:59 1.17 +++ netinet/igmp_var.h 2001/08/12 18:50:52 @@ -85,12 +85,13 @@ */ #define IGMP_AGE_THRESHOLD 540 -void igmp_init __P((void)); -void igmp_input __P((struct mbuf *, int, int)); +pr_init_t igmp_init; +pr_input_t igmp_input; +pr_fasttimo_t igmp_fasttimo; +pr_slowtimo_t igmp_slowtimo; + void igmp_joingroup __P((struct in_multi *)); void igmp_leavegroup __P((struct in_multi *)); -void igmp_fasttimo __P((void)); -void igmp_slowtimo __P((void)); SYSCTL_DECL(_net_inet_igmp); Index: netinet/in.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.55 diff -u -r1.55 in.c --- netinet/in.c 2001/08/04 17:10:13 1.55 +++ netinet/in.c 2001/08/12 18:50:53 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include Index: netinet/in_gif.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.11 diff -u -r1.11 in_gif.c --- netinet/in_gif.c 2001/07/02 21:02:07 1.11 +++ netinet/in_gif.c 2001/08/12 18:50:53 @@ -42,6 +42,7 @@ #include #include #include +#include #include @@ -298,7 +299,7 @@ dst = (struct sockaddr_in *)sc->gif_pdst; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip), (caddr_t)&ip); + m_copydata(m, 0, sizeof(ip), (caddr_t)&ip); /* check for address match */ addrmatch = 0; Index: netinet/in_gif.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_gif.h,v retrieving revision 1.5 diff -u -r1.5 in_gif.h --- netinet/in_gif.h 2001/07/02 21:02:07 1.5 +++ netinet/in_gif.h 2001/08/12 18:50:54 @@ -37,7 +37,7 @@ extern int ip_gif_ttl; -void in_gif_input __P((struct mbuf *, int off, int proto)); +pr_input_t in_gif_input; int in_gif_output __P((struct ifnet *, int, struct mbuf *, struct rtentry *)); int gif_encapcheck4 __P((const struct mbuf *, int, int, void *)); Index: netinet/in_proto.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_proto.c,v retrieving revision 1.57 diff -u -r1.57 in_proto.c --- netinet/in_proto.c 2001/07/02 21:02:07 1.57 +++ netinet/in_proto.c 2001/08/12 18:50:54 @@ -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, Index: netinet/in_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v retrieving revision 1.40 diff -u -r1.40 in_rmx.c --- netinet/in_rmx.c 2001/05/11 14:37:34 1.40 +++ netinet/in_rmx.c 2001/08/12 18:50:55 @@ -49,6 +49,7 @@ #include #include #include +#include #include #include Index: netinet/ip_dummynet.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v retrieving revision 1.39 diff -u -r1.39 ip_dummynet.c --- netinet/ip_dummynet.c 2001/02/10 00:10:18 1.39 +++ netinet/ip_dummynet.c 2001/08/12 18:50:58 @@ -63,6 +63,7 @@ #include /* XXX */ #include #include +#include #include #include #include Index: netinet/ip_encap.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_encap.c,v retrieving revision 1.5 diff -u -r1.5 ip_encap.c --- netinet/ip_encap.c 2001/07/25 20:15:49 1.5 +++ netinet/ip_encap.c 2001/08/12 18:50:59 @@ -77,7 +77,6 @@ #include #include #include -#include #ifdef INET6 #include @@ -127,27 +126,17 @@ #ifdef INET void -#if __STDC__ -encap4_input(struct mbuf *m, ...) -#else -encap4_input(m, va_alist) +encap4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + int proto; { - 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 *); bzero(&s, sizeof(s)); @@ -205,7 +194,7 @@ if (match) { /* found a match, "match" has the best one */ - psw = (const struct ipprotosw *)match->psw; + psw = (const struct protosw *)match->psw; if (psw && psw->pr_input) { encap_fillarg(m, match); (*psw->pr_input)(m, off, proto); Index: netinet/ip_encap.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_encap.h,v retrieving revision 1.1 diff -u -r1.1 ip_encap.h --- netinet/ip_encap.h 2000/07/04 16:35:05 1.1 +++ netinet/ip_encap.h 2001/08/12 18:50:59 @@ -48,9 +48,10 @@ void *arg; /* passed via m->m_pkthdr.aux */ }; -void encap_init __P((void)); -void encap4_input __P((struct mbuf *, ...)); -int encap6_input __P((struct mbuf **, int *, int)); +pr_init_t encap_init; +pr_input_t encap4_input; +pr_input6_t encap6_input; + const struct encaptab *encap_attach __P((int, int, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct sockaddr *, const struct protosw *, void *)); Index: netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.165 diff -u -r1.165 ip_fw.c --- netinet/ip_fw.c 2001/07/02 15:50:31 1.165 +++ netinet/ip_fw.c 2001/08/12 18:51:02 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include #include Index: netinet/ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.58 diff -u -r1.58 ip_icmp.c --- netinet/ip_icmp.c 2001/06/23 17:17:58 1.58 +++ netinet/ip_icmp.c 2001/08/12 18:51:04 @@ -232,7 +232,8 @@ void icmp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + int proto; { int hlen = off; register struct icmp *icp; Index: netinet/ip_icmp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.16 diff -u -r1.16 ip_icmp.h --- netinet/ip_icmp.h 1999/12/29 04:41:01 1.16 +++ netinet/ip_icmp.h 2001/08/12 18:51:04 @@ -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)); +pr_input_t icmp_input; #endif #endif Index: netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.174 diff -u -r1.174 ip_input.c --- netinet/ip_input.c 2001/06/23 17:17:58 1.174 +++ netinet/ip_input.c 2001/08/12 18:51:07 @@ -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 = (struct protosw *)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 = (struct protosw *)inetdomain.dom_protosw; + pr < (struct protosw *)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; Index: netinet/ip_mroute.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_mroute.c,v retrieving revision 1.64 diff -u -r1.64 ip_mroute.c --- netinet/ip_mroute.c 2001/07/25 20:15:49 1.64 +++ netinet/ip_mroute.c 2001/08/12 18:51:10 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include @@ -732,7 +731,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, Index: netinet/ip_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.57 diff -u -r1.57 ip_var.h --- netinet/ip_var.h 2001/06/11 18:41:57 1.57 +++ netinet/ip_var.h 2001/08/12 18:51:11 @@ -154,19 +154,21 @@ extern int (*legal_vif_num) __P((int)); extern u_long (*ip_mcast_src) __P((int)); extern int rsvp_on; + extern struct pr_usrreqs rip_usrreqs; + +pr_ctloutput_t ip_ctloutput; +pr_drain_t ip_drain; +pr_init_t ip_init; +pr_slowtimo_t ip_slowtimo; -int ip_ctloutput __P((struct socket *, struct sockopt *sopt)); -void ip_drain __P((void)); void ip_freemoptions __P((struct ip_moptions *)); -void ip_init __P((void)); extern int (*ip_mforward) __P((struct ip *, struct ifnet *, struct mbuf *, struct ip_moptions *)); int ip_output __P((struct mbuf *, struct mbuf *, struct route *, int, struct ip_moptions *)); void ip_savecontrol __P((struct inpcb *, struct mbuf **, struct ip *, struct mbuf *)); -void ip_slowtimo __P((void)); struct mbuf * ip_srcroute __P((void)); void ip_stripoptions __P((struct mbuf *, struct mbuf *)); @@ -174,13 +176,13 @@ u_int16_t ip_randomid __P((void)); #endif -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)); -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)); +pr_ctloutput_t rip_ctloutput; +pr_ctlinput_t rip_ctlinput; +pr_init_t rip_init; +pr_input_t rip_input; +pr_output_t rip_output; +pr_input_t ipip_input; +pr_input_t rsvp_input; int ip_rsvp_init __P((struct socket *)); int ip_rsvp_done __P((void)); int ip_rsvp_vif_init __P((struct socket *, struct sockopt *)); @@ -188,8 +190,8 @@ void ip_rsvp_force_done __P((struct socket *)); #ifdef IPDIVERT -void div_init __P((void)); -void div_input __P((struct mbuf *, int, int)); +pr_init_t div_init; +pr_input_t div_input; void divert_packet __P((struct mbuf *, int, int)); extern struct pr_usrreqs div_usrreqs; extern u_int16_t ip_divert_cookie; Index: netinet/raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.80 diff -u -r1.80 raw_ip.c --- netinet/raw_ip.c 2001/07/26 19:19:48 1.80 +++ netinet/raw_ip.c 2001/08/12 18:51:12 @@ -114,7 +114,8 @@ void rip_input(m, off, proto) struct mbuf *m; - int off, proto; + int off; + int proto; { register struct ip *ip = mtod(m, struct ip *); register struct inpcb *inp; @@ -196,10 +197,10 @@ * Tack on options user may have setup with control call. */ int -rip_output(m, so, dst) +rip_output(m, so, nam) struct mbuf *m; struct socket *so; - u_long dst; + struct sockaddr *nam; { register struct ip *ip; register struct inpcb *inp = sotoinpcb(so); @@ -214,6 +215,10 @@ m_freem(m); return(EMSGSIZE); } + if (nam == NULL) { + m_freem(m); + return ENOTCONN; + } M_PREPEND(m, sizeof(struct ip), M_TRYWAIT); ip = mtod(m, struct ip *); ip->ip_tos = inp->inp_ip_tos; @@ -221,7 +226,8 @@ ip->ip_p = inp->inp_ip_p; ip->ip_len = m->m_pkthdr.len; ip->ip_src = inp->inp_laddr; - ip->ip_dst.s_addr = dst; + ip->ip_dst.s_addr + = ((struct sockaddr_in *)nam)->sin_addr.s_addr; ip->ip_ttl = inp->inp_ip_ttl; } else { if (m->m_pkthdr.len > IP_MAXPACKET) { @@ -566,22 +572,26 @@ struct mbuf *control, struct proc *p) { struct inpcb *inp = sotoinpcb(so); - register u_long dst; + struct sockaddr_in dst_addr; + if (so->so_state & SS_ISCONNECTED) { if (nam) { m_freem(m); return EISCONN; } - dst = inp->inp_faddr.s_addr; + dst_addr.sin_len = sizeof(dst_addr); + dst_addr.sin_family = AF_INET; + dst_addr.sin_port = 0; + dst_addr.sin_addr.s_addr = inp->inp_faddr.s_addr; + nam = (struct sockaddr *)&dst_addr; } else { if (nam == NULL) { m_freem(m); return ENOTCONN; } - dst = ((struct sockaddr_in *)nam)->sin_addr.s_addr; } - return rip_output(m, so, dst); + return rip_output(m, so, nam); } static int Index: netinet/tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.136 diff -u -r1.136 tcp_input.c --- netinet/tcp_input.c 2001/07/08 02:20:46 1.136 +++ netinet/tcp_input.c 2001/08/12 18:51:17 @@ -331,7 +331,8 @@ void tcp_input(m, off0, proto) register struct mbuf *m; - int off0, proto; + int off0; + int proto; { register struct tcphdr *th; register struct ip *ip = NULL; Index: netinet/tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.112 diff -u -r1.112 tcp_subr.c --- netinet/tcp_subr.c 2001/07/27 00:04:39 1.112 +++ netinet/tcp_subr.c 2001/08/12 18:51:19 @@ -1107,8 +1107,8 @@ (struct sockaddr *)ip6cp->ip6c_src, th.th_sport, cmd, notify); } else - in6_pcbnotify(&tcb, sa, 0, (struct sockaddr *)sa6_src, - 0, cmd, notify); + in6_pcbnotify(&tcb, sa, 0, (struct sockaddr *)sa6_src, 0, + cmd, notify); } #endif /* INET6 */ Index: netinet/tcp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.70 diff -u -r1.70 tcp_var.h --- netinet/tcp_var.h 2001/07/08 02:20:47 1.70 +++ netinet/tcp_var.h 2001/08/12 18:51:20 @@ -372,19 +372,21 @@ extern int ss_fltsz; extern int ss_fltsz_local; +pr_ctlinput_t tcp_ctlinput; +pr_ctloutput_t tcp_ctloutput; +pr_fasttimo_t tcp_fasttimo; +pr_slowtimo_t tcp_slowtimo; +pr_init_t tcp_init; +pr_drain_t tcp_drain; +pr_input_t tcp_input; + void tcp_canceltimers __P((struct tcpcb *)); struct tcpcb * tcp_close __P((struct tcpcb *)); -void tcp_ctlinput __P((int, struct sockaddr *, void *)); -int tcp_ctloutput __P((struct socket *, struct sockopt *)); struct tcpcb * tcp_drop __P((struct tcpcb *, int)); -void tcp_drain __P((void)); -void tcp_fasttimo __P((void)); struct rmxp_tao * tcp_gettaocache __P((struct inpcb *)); -void tcp_init __P((void)); -void tcp_input __P((struct mbuf *, int, int)); void tcp_mss __P((struct tcpcb *, int)); int tcp_mssopt __P((struct tcpcb *)); void tcp_drop_syn_sent __P((struct inpcb *, int)); @@ -398,7 +400,6 @@ struct rtentry * tcp_rtlookup __P((struct inpcb *)); void tcp_setpersist __P((struct tcpcb *)); -void tcp_slowtimo __P((void)); struct tcptemp * tcp_maketemplate __P((struct tcpcb *)); void tcp_fillheaders __P((struct tcpcb *, void *, void *)); Index: netinet/udp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.93 diff -u -r1.93 udp_usrreq.c --- netinet/udp_usrreq.c 2001/07/26 19:19:48 1.93 +++ netinet/udp_usrreq.c 2001/08/12 18:51:21 @@ -151,7 +151,8 @@ void udp_input(m, off, proto) register struct mbuf *m; - int off, proto; + int off; + int proto; { int iphlen = off; register struct ip *ip; Index: netinet/udp_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/udp_var.h,v retrieving revision 1.23 diff -u -r1.23 udp_var.h --- netinet/udp_var.h 2001/02/18 07:10:03 1.23 +++ netinet/udp_var.h 2001/08/12 18:51:21 @@ -103,9 +103,9 @@ extern struct udpstat udpstat; extern int log_in_vain; -void udp_ctlinput __P((int, struct sockaddr *, void *)); -void udp_init __P((void)); -void udp_input __P((struct mbuf *, int, int)); +pr_ctlinput_t udp_ctlinput; +pr_init_t udp_init; +pr_input_t udp_input; void udp_notify __P((struct inpcb *inp, int errno)); int udp_shutdown __P((struct socket *so)); Index: netinet6/ah.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah.h,v retrieving revision 1.5 diff -u -r1.5 ah.h --- netinet6/ah.h 2001/06/11 12:39:03 1.5 +++ netinet6/ah.h 2001/08/12 18:51:21 @@ -79,13 +79,14 @@ #define AH_MAXSUMSIZE 16 +extern pr_input_t ah4_input; extern const struct ah_algorithm *ah_algorithm_lookup __P((int)); + /* cksum routines */ extern int ah_hdrlen __P((struct secasvar *)); extern size_t ah_hdrsiz __P((struct ipsecrequest *)); -extern void ah4_input __P((struct mbuf *, ...)); extern int ah4_output __P((struct mbuf *, struct ipsecrequest *)); extern int ah4_calccksum __P((struct mbuf *, caddr_t, size_t, const struct ah_algorithm *, struct secasvar *)); Index: netinet6/ah_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ah_input.c,v retrieving revision 1.7 diff -u -r1.7 ah_input.c --- netinet6/ah_input.c 2001/06/11 12:39:04 1.7 +++ netinet6/ah_input.c 2001/08/12 18:51:23 @@ -56,6 +56,7 @@ #include #include #include +#include #include #include #include @@ -94,17 +95,13 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -ah4_input(struct mbuf *m, ...) -#else -ah4_input(m, va_alist) +ah4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + int proto; { struct ip *ip; struct ah *ah; @@ -116,15 +113,8 @@ struct secasvar *sav = NULL; u_int16_t nxt; size_t hlen; - int off, proto; - va_list ap; size_t stripsiz = 0; - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); - #ifndef PULLDOWN_TEST if (m->m_len < off + sizeof(struct newah)) { m = m_pullup(m, off + sizeof(struct newah)); @@ -999,6 +989,7 @@ } else { m = NULL; ip6 = NULL; + off = 0; } if (ip6) { Index: netinet6/esp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp.h,v retrieving revision 1.4 diff -u -r1.4 esp.h --- netinet6/esp.h 2001/06/11 12:39:04 1.4 +++ netinet6/esp.h 2001/08/12 18:51:23 @@ -97,8 +97,8 @@ extern int esp_max_ivlen __P((void)); /* crypt routines */ +extern pr_input_t esp4_input; extern int esp4_output __P((struct mbuf *, struct ipsecrequest *)); -extern void esp4_input __P((struct mbuf *, ...)); extern size_t esp_hdrsiz __P((struct ipsecrequest *)); extern int esp_schedule __P((const struct esp_algorithm *, struct secasvar *)); Index: netinet6/esp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp_input.c,v retrieving revision 1.7 diff -u -r1.7 esp_input.c --- netinet6/esp_input.c 2001/06/11 12:39:05 1.7 +++ netinet6/esp_input.c 2001/08/12 18:51:25 @@ -56,6 +56,7 @@ #include #include #include +#include #include #include #ifdef INET6 @@ -97,17 +98,13 @@ ? sizeof(struct newesp) : sizeof(struct esp)) #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -esp4_input(struct mbuf *m, ...) -#else -esp4_input(m, va_alist) +esp4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + int proto; { struct ip *ip; struct esp *esp; @@ -120,13 +117,6 @@ int ivlen; size_t hlen; size_t esplen; - va_list ap; - int off, proto; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); /* sanity check for alignment. */ if (off % 4 != 0 || m->m_pkthdr.len % 4 != 0) { @@ -924,6 +914,7 @@ } else { m = NULL; ip6 = NULL; + off = 0; } if (ip6) { Index: netinet6/esp_rijndael.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/esp_rijndael.c,v retrieving revision 1.1 diff -u -r1.1 esp_rijndael.c --- netinet6/esp_rijndael.c 2001/06/11 12:39:05 1.1 +++ netinet6/esp_rijndael.c 2001/08/12 18:51:25 @@ -35,6 +35,7 @@ #include #include +#include #include #include Index: netinet6/in6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6.c,v retrieving revision 1.15 diff -u -r1.15 in6.c --- netinet6/in6.c 2001/08/03 19:10:31 1.15 +++ netinet6/in6.c 2001/08/12 18:51:29 @@ -79,6 +79,7 @@ #include #include #include +#include #include #include @@ -1789,8 +1790,8 @@ static char ip6buf[8][48]; int i; char *cp; - u_short *a = (u_short *)addr; - u_char *d; + const u_short *a = (const u_short *)addr; + const u_char *d; int dcolon = 0; ip6round = (ip6round + 1) & 7; @@ -1819,7 +1820,7 @@ a++; continue; } - d = (u_char *)a; + d = (const u_char *)a; *cp++ = digits[*d >> 4]; *cp++ = digits[*d++ & 0xf]; *cp++ = digits[*d >> 4]; Index: netinet6/in6_gif.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_gif.c,v retrieving revision 1.5 diff -u -r1.5 in6_gif.c --- netinet6/in6_gif.c 2001/06/11 12:39:05 1.5 +++ netinet6/in6_gif.c 2001/08/12 18:51:30 @@ -41,7 +41,7 @@ #include #include #include - +#include #include #include @@ -302,7 +302,7 @@ dst = (struct sockaddr_in6 *)sc->gif_pdst; /* LINTED const cast */ - m_copydata((struct mbuf *)m, 0, sizeof(ip6), (caddr_t)&ip6); + m_copydata(m, 0, sizeof(ip6), (caddr_t)&ip6); /* check for address match */ addrmatch = 0; Index: netinet6/in6_ifattach.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v retrieving revision 1.7 diff -u -r1.7 in6_ifattach.c --- netinet6/in6_ifattach.c 2001/08/04 17:10:13 1.7 +++ netinet6/in6_ifattach.c 2001/08/12 18:51:31 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include Index: netinet6/in6_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.c,v retrieving revision 1.16 diff -u -r1.16 in6_pcb.c --- netinet6/in6_pcb.c 2001/08/04 17:10:14 1.16 +++ netinet6/in6_pcb.c 2001/08/12 18:51:33 @@ -765,7 +765,8 @@ void in6_pcbnotify(head, dst, fport_arg, src, lport_arg, cmd, notify) struct inpcbhead *head; - struct sockaddr *dst, *src; + struct sockaddr *dst; + const struct sockaddr *src; u_int fport_arg, lport_arg; int cmd; void (*notify) __P((struct inpcb *, int)); Index: netinet6/in6_pcb.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_pcb.h,v retrieving revision 1.5 diff -u -r1.5 in6_pcb.h --- netinet6/in6_pcb.h 2001/08/04 17:10:14 1.5 +++ netinet6/in6_pcb.h 2001/08/12 18:51:34 @@ -91,7 +91,7 @@ struct in6_addr *, u_int, struct in6_addr *, u_int, int, struct ifnet *)); void in6_pcbnotify __P((struct inpcbhead *, struct sockaddr *, - u_int, struct sockaddr *, u_int, int, + u_int, const struct sockaddr *, u_int, int, void (*)(struct inpcb *, int))); void in6_rtchange __P((struct inpcb *, int)); int in6_setpeeraddr __P((struct socket *so, struct sockaddr **nam)); Index: netinet6/in6_prefix.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_prefix.c,v retrieving revision 1.7 diff -u -r1.7 in6_prefix.c --- netinet6/in6_prefix.c 2001/06/11 12:39:05 1.7 +++ netinet6/in6_prefix.c 2001/08/12 18:51:35 @@ -74,6 +74,7 @@ #include #include #include +#include #include Index: netinet6/in6_rmx.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/in6_rmx.c,v retrieving revision 1.4 diff -u -r1.4 in6_rmx.c --- netinet6/in6_rmx.c 2001/06/11 12:39:05 1.4 +++ netinet6/in6_rmx.c 2001/08/12 18:51:36 @@ -82,6 +82,7 @@ #include #include #include +#include #include #include Index: netinet6/ip6_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_fw.c,v retrieving revision 1.13 diff -u -r1.13 ip6_fw.c --- netinet6/ip6_fw.c 2001/06/28 05:18:31 1.13 +++ netinet6/ip6_fw.c 2001/08/12 18:51:38 @@ -42,6 +42,7 @@ #include #include #include +#include #include #include #include Index: netinet6/ip6_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6_var.h,v retrieving revision 1.7 diff -u -r1.7 ip6_var.h --- netinet6/ip6_var.h 2001/06/11 12:39:05 1.7 +++ netinet6/ip6_var.h 2001/08/12 18:51:39 @@ -332,23 +332,22 @@ struct ip6_pktopts *ip6_copypktopts __P((struct ip6_pktopts *, int)); int ip6_optlen __P((struct inpcb *)); -int route6_input __P((struct mbuf **, int *, int)); +pr_input6_t route6_input; -void frag6_init __P((void)); -int frag6_input __P((struct mbuf **, int *, int)); -void frag6_slowtimo __P((void)); -void frag6_drain __P((void)); +pr_init_t frag6_init; +pr_input6_t frag6_input; +pr_slowtimo_t frag6_slowtimo; +pr_drain_t frag6_drain; -void rip6_init __P((void)); -int rip6_input __P((struct mbuf **mp, int *offp, int proto)); -void rip6_ctlinput __P((int, struct sockaddr *, void *)); -int rip6_ctloutput __P((struct socket *so, struct sockopt *sopt)); -int rip6_output __P((struct mbuf *, ...)); -int rip6_usrreq __P((struct socket *, - int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *)); +pr_init_t rip6_init; +pr_input6_t rip6_input; +pr_ctlinput_t rip6_ctlinput; +pr_ctloutput_t rip6_ctloutput; +pr_output_t rip6_output; +pr_usrreq_t rip6_usrreq; +pr_input6_t dest6_input; +pr_input6_t none_input; -int dest6_input __P((struct mbuf **, int *, int)); -int none_input __P((struct mbuf **, int *, int)); #endif /* _KERNEL */ #endif /* !_NETINET6_IP6_VAR_H_ */ Index: netinet6/ip6protosw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ip6protosw.h,v retrieving revision 1.6 diff -u -r1.6 ip6protosw.h --- netinet6/ip6protosw.h 2001/06/11 12:39:05 1.6 +++ netinet6/ip6protosw.h 2001/08/12 18:51:39 @@ -128,30 +128,20 @@ short pr_flags; /* see below */ /* protocol-protocol hooks */ - int (*pr_input) /* input to protocol (from below) */ - __P((struct mbuf **, int *, int)); - int (*pr_output) /* output to protocol (from above) */ - __P((struct mbuf *, ...)); - void (*pr_ctlinput) /* control input (from below) */ - __P((int, struct sockaddr *, void *)); - int (*pr_ctloutput) /* control output (from above) */ - __P((struct socket *, struct sockopt *)); + pr_input6_t *pr_input; /* input to protocol (from below) */ + pr_output_t *pr_output; /* output to protocol (from above) */ + pr_ctlinput_t *pr_ctlinput; /* control input (from below) */ + pr_ctloutput_t *pr_ctloutput; /* control output (from above) */ /* user-protocol hook */ - int (*pr_usrreq) /* user request: see list below */ - __P((struct socket *, int, struct mbuf *, - struct mbuf *, struct mbuf *, struct proc *)); + pr_usrreq_t *pr_usrreq; /* user request: see list below */ /* utility hooks */ - void (*pr_init) /* initialization hook */ - __P((void)); + pr_init_t *pr_init; + pr_fasttimo_t *pr_fasttimo; /* fast timeout (200ms) */ + pr_slowtimo_t *pr_slowtimo; /* slow timeout (500ms) */ + pr_drain_t *pr_drain; /* flush any excess space possible */ - void (*pr_fasttimo) /* fast timeout (200ms) */ - __P((void)); - void (*pr_slowtimo) /* slow timeout (500ms) */ - __P((void)); - void (*pr_drain) /* flush any excess space possible */ - __P((void)); struct pr_usrreqs *pr_usrreqs; /* supersedes pr_usrreq() */ struct pfil_head pr_pfh; }; Index: netinet6/ipcomp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ipcomp.h,v retrieving revision 1.2 diff -u -r1.2 ipcomp.h --- netinet6/ipcomp.h 2001/06/11 12:39:06 1.2 +++ netinet6/ipcomp.h 2001/08/12 18:51:39 @@ -62,9 +62,10 @@ size_t minplen; /* minimum required length for compression */ }; +extern pr_input_t ipcomp4_input; + struct ipsecrequest; extern const struct ipcomp_algorithm *ipcomp_algorithm_lookup __P((int)); -extern void ipcomp4_input __P((struct mbuf *, ...)); extern int ipcomp4_output __P((struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ Index: netinet6/ipcomp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/ipcomp_input.c,v retrieving revision 1.2 diff -u -r1.2 ipcomp_input.c --- netinet6/ipcomp_input.c 2001/06/11 12:39:06 1.2 +++ netinet6/ipcomp_input.c 2001/08/12 18:51:40 @@ -83,17 +83,13 @@ #define IPLEN_FLIPPED #ifdef INET -#include -extern struct ipprotosw inetsw[]; +extern struct protosw inetsw[]; void -#if __STDC__ -ipcomp4_input(struct mbuf *m, ...) -#else -ipcomp4_input(m, va_alist) +ipcomp4_input(m, off, proto) struct mbuf *m; - va_dcl -#endif + int off; + int proto; { struct mbuf *md; struct ip *ip; @@ -105,13 +101,6 @@ int error; size_t newlen, olen; struct secasvar *sav = NULL; - int off, proto; - va_list ap; - - va_start(ap, m); - off = va_arg(ap, int); - proto = va_arg(ap, int); - va_end(ap); if (m->m_pkthdr.len < off + sizeof(struct ipcomp)) { ipseclog((LOG_DEBUG, "IPv4 IPComp input: assumption failed " Index: netinet6/nd6_nbr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6_nbr.c,v retrieving revision 1.10 diff -u -r1.10 nd6_nbr.c --- netinet6/nd6_nbr.c 2001/06/19 14:48:02 1.10 +++ netinet6/nd6_nbr.c 2001/08/12 18:51:42 @@ -46,6 +46,7 @@ #include #include #include +#include #include #include Index: netinet6/nd6_rtr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6_rtr.c,v retrieving revision 1.8 diff -u -r1.8 nd6_rtr.c --- netinet6/nd6_rtr.c 2001/06/18 11:37:06 1.8 +++ netinet6/nd6_rtr.c 2001/08/12 18:51:45 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include Index: netinet6/raw_ip6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/raw_ip6.c,v retrieving revision 1.12 diff -u -r1.12 raw_ip6.c --- netinet6/raw_ip6.c 2001/07/26 19:19:49 1.12 +++ netinet6/raw_ip6.c 2001/08/12 18:51:47 @@ -286,7 +286,7 @@ sa6_src = &sa6_any; } - (void) in6_pcbnotify(&ripcb, sa, 0, (struct sockaddr *)sa6_src, + (void) in6_pcbnotify(&ripcb, sa, 0, (const struct sockaddr *)sa6_src, 0, cmd, notify); } @@ -295,16 +295,12 @@ * Tack on options user may have setup with control call. */ int -#if __STDC__ -rip6_output(struct mbuf *m, ...) -#else -rip6_output(m, va_alist) +rip6_output(m, so, sockaddr) struct mbuf *m; - va_dcl -#endif -{ struct socket *so; - struct sockaddr_in6 *dstsock; + struct sockaddr *sockaddr; +{ + struct sockaddr_in6 *dstsock = (struct sockaddr_in6 *)sockaddr; struct mbuf *control; struct in6_addr *dst; struct ip6_hdr *ip6; @@ -315,14 +311,12 @@ struct ifnet *oifp = NULL; int type = 0, code = 0; /* for ICMPv6 output statistics only */ int priv = 0; - va_list ap; - - va_start(ap, m); - so = va_arg(ap, struct socket *); - dstsock = va_arg(ap, struct sockaddr_in6 *); - control = va_arg(ap, struct mbuf *); - va_end(ap); + if (m->m_type == MT_CONTROL) { + control = m; + m = m->m_next; + } else + control = NULL; in6p = sotoin6pcb(so); priv = 0; @@ -718,7 +712,11 @@ dst->sin6_scope_id = scope6_addr2default(&dst->sin6_addr); } #endif - return rip6_output(m, so, dst, control); + if (control) { + control->m_next = m; + m = control; + } + return rip6_output(m, so, (struct sockaddr *)dst); } struct pr_usrreqs rip6_usrreqs = { Index: netinet6/route6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/route6.c,v retrieving revision 1.4 diff -u -r1.4 route6.c --- netinet6/route6.c 2001/06/11 12:39:06 1.4 +++ netinet6/route6.c 2001/08/12 18:51:47 @@ -38,6 +38,7 @@ #include #include #include +#include #include Index: netinet6/udp6_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/udp6_usrreq.c,v retrieving revision 1.16 diff -u -r1.16 udp6_usrreq.c --- netinet6/udp6_usrreq.c 2001/07/26 19:19:49 1.16 +++ netinet6/udp6_usrreq.c 2001/08/12 18:51:48 @@ -456,10 +456,11 @@ bzero(&uh, sizeof(uh)); m_copydata(m, off, sizeof(*uhp), (caddr_t)&uh); - (void) in6_pcbnotify(&udb, sa, uh.uh_dport, ip6cp->ip6c_src, + (void) in6_pcbnotify(&udb, sa, uh.uh_dport, + (const struct sockaddr *)ip6cp->ip6c_src, uh.uh_sport, cmd, notify); } else - (void) in6_pcbnotify(&udb, sa, 0, (struct sockaddr *)&sa6_src, + (void) in6_pcbnotify(&udb, sa, 0, (const struct sockaddr *)&sa6_src, 0, cmd, notify); } Index: netipx/ipx_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netipx/ipx_ip.c,v retrieving revision 1.27 diff -u -r1.27 ipx_ip.c --- netipx/ipx_ip.c 2001/02/04 13:13:10 1.27 +++ netipx/ipx_ip.c 2001/08/12 18:51:48 @@ -162,9 +162,10 @@ static int ipxip_hold_input; void -ipxip_input(m, hlen) +ipxip_input(m, hlen, proto) register struct mbuf *m; int hlen; + int proto; /* ignored */ { register struct ip *ip; register struct ipx *ipx; Index: netipx/ipx_ip.h =================================================================== RCS file: /home/ncvs/src/sys/netipx/ipx_ip.h,v retrieving revision 1.14 diff -u -r1.14 ipx_ip.h --- netipx/ipx_ip.h 1999/12/29 04:46:08 1.14 +++ netipx/ipx_ip.h 2001/08/12 18:51:49 @@ -51,8 +51,8 @@ #ifdef _KERNEL -void ipxip_ctlinput __P((int cmd, struct sockaddr *sa, void *arg)); -void ipxip_input __P((struct mbuf *m, int hlen)); +pr_ctlinput_t ipxip_ctlinput; +pr_input_t ipxip_input; int ipxip_route __P((struct socket *so, struct sockopt *sopt)); #endif Index: netkey/keysock.c =================================================================== RCS file: /home/ncvs/src/sys/netkey/keysock.c,v retrieving revision 1.6 diff -u -r1.6 keysock.c --- netkey/keysock.c 2001/06/11 12:39:10 1.6 +++ netkey/keysock.c 2001/08/12 18:51:50 @@ -71,23 +71,14 @@ * key_output() */ int -#if __STDC__ -key_output(struct mbuf *m, ...) -#else -key_output(m, va_alist) +key_output(m, so, sockaddr) struct mbuf *m; - va_dcl -#endif + struct socket *so; + struct sockaddr *sockaddr; /* ignored */ { struct sadb_msg *msg; int len, error = 0; int s; - struct socket *so; - va_list ap; - - va_start(ap, m); - so = va_arg(ap, struct socket *); - va_end(ap); if (m == 0) panic("key_output: NULL pointer was passed.\n"); Index: netkey/keysock.h =================================================================== RCS file: /home/ncvs/src/sys/netkey/keysock.h,v retrieving revision 1.5 diff -u -r1.5 keysock.h --- netkey/keysock.h 2000/07/04 16:35:14 1.5 +++ netkey/keysock.h 2001/08/12 18:51:50 @@ -71,7 +71,7 @@ extern struct pfkeystat pfkeystat; -extern int key_output __P((struct mbuf *, ...)); +extern pr_output_t key_output; extern int key_usrreq __P((struct socket *, int, struct mbuf *, struct mbuf *, struct mbuf *)); Index: sys/mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.83 diff -u -r1.83 mbuf.h --- sys/mbuf.h 2001/07/26 18:47:40 1.83 +++ sys/mbuf.h 2001/08/12 18:51:52 @@ -434,7 +434,7 @@ void m_extadd(struct mbuf *, caddr_t, u_int, void (*free)(caddr_t, void *), void *, short, int); void m_copyback(struct mbuf *, int, int, caddr_t); -void m_copydata(struct mbuf *, int, int, caddr_t); +void m_copydata(const struct mbuf *, int, int, caddr_t); struct mbuf *m_copym(struct mbuf *, int, int, int); struct mbuf *m_copypacket(struct mbuf *, int); struct mbuf *m_devget(char *, int, int, struct ifnet *, Index: sys/protosw.h =================================================================== RCS file: /home/ncvs/src/sys/sys/protosw.h,v retrieving revision 1.34 diff -u -r1.34 protosw.h --- sys/protosw.h 2001/08/10 23:17:22 1.34 +++ sys/protosw.h 2001/08/12 18:51:53 @@ -73,9 +73,11 @@ * similar to the vnode VOP interface. */ /* USE THESE FOR YOUR PROTOTYPES ! */ -typedef void pr_input_t (struct mbuf *, int); + +typedef void pr_input_t (struct mbuf *, int, int); +typedef int pr_input6_t (struct mbuf **, int*, int); /* XXX FIX THIS */ typedef void pr_in_input_t (struct mbuf *, int, int); /* XXX FIX THIS */ -typedef int pr_output_t (struct mbuf *, struct socket *); +typedef int pr_output_t (struct mbuf *, struct socket *, struct sockaddr *); typedef void pr_ctlinput_t (int, struct sockaddr *, void *); typedef int pr_ctloutput_t (struct socket *, struct sockopt *); typedef void pr_init_t (void); @@ -83,6 +85,9 @@ typedef void pr_slowtimo_t (void); typedef void pr_drain_t (void); +typedef int pr_usrreq_t(struct socket *, int, struct mbuf *, + struct mbuf *, struct mbuf *, struct proc *); + struct protosw { short pr_type; /* socket type used for */ @@ -95,7 +100,7 @@ pr_ctlinput_t *pr_ctlinput; /* control input (from below) */ pr_ctloutput_t *pr_ctloutput; /* control output (from above) */ /* user-protocol hook */ - void *pr_ousrreq; + pr_usrreq_t *pr_ousrreq; /* utility hooks */ pr_init_t *pr_init; pr_fasttimo_t *pr_fasttimo; /* fast timeout (200ms) */ --------------368BE1ACB0C8DBFA3CF8FDC2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 13:35:25 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 9668B37B408 for ; Sun, 12 Aug 2001 13:35:21 -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 NAA98243; Sun, 12 Aug 2001 13:28:19 -0700 (PDT) Message-ID: <3B76E4BD.45E83378@elischer.org> Date: Sun, 12 Aug 2001 13:19:09 -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: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <20010812200929.C276E7BA@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: > > >Please note that the ip6protosw is ALSO very broken > > unfortunately, you are wrong. yes, protosw is supposed to be > protocol-independent. however, due to the nature of IPv6 extension > headers (you can have infinite number of them) you can blow the kernel > stack very easily. therefore, we had to do ip6protosw.h. > please read my Usenix paper (on m_pulldown and mbuf issues in BSD > IPv6 support) two years ago. I didn't say it could be easily fixed, and note that I am not touching it now.. > > 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 Sun Aug 12 13:35:35 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 6AF9A37B407 for ; Sun, 12 Aug 2001 13:35:23 -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 NAA98251; Sun, 12 Aug 2001 13:34:33 -0700 (PDT) Message-ID: <3B76E632.28BE644@elischer.org> Date: Sun, 12 Aug 2001 13:25:22 -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: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <20010812201530.DBF2D7BB@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: > > >Well what is there now is plainly unacceptable > >I think that it was asked for as a VERY SHORT TERM hack. > >But it has been there a long time... > >I see no reasons so far to not make most of these changes.. > > well, you are ignoging our design decisions. they are all done > for reasons. no, I just disagree about some of them. > > >1/ removal of "control" argument from rip6_input and prepend control mbuf > >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto > >type for input. (I have not confirmed that the information in control > >is a valid mbuf but it is an mbuf pointer). > > i don't see any "control" argument in rip6_input in kame tree, as well > as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision > are you looking at? Sorry, wrong function.. it was output.... here is the fix @@ -295,16 +295,12 @@ * Tack on options user may have setup with control call. */ int -#if __STDC__ -rip6_output(struct mbuf *m, ...) -#else -rip6_output(m, va_alist) +rip6_output(m, so, sockaddr) struct mbuf *m; - va_dcl -#endif -{ struct socket *so; - struct sockaddr_in6 *dstsock; + struct sockaddr *sockaddr; +{ + struct sockaddr_in6 *dstsock = (struct sockaddr_in6 *)sockaddr; struct mbuf *control; struct in6_addr *dst; struct ip6_hdr *ip6; @@ -315,14 +311,12 @@ struct ifnet *oifp = NULL; int type = 0, code = 0; /* for ICMPv6 output statistics only */ int priv = 0; - va_list ap; - - va_start(ap, m); - so = va_arg(ap, struct socket *); - dstsock = va_arg(ap, struct sockaddr_in6 *); - control = va_arg(ap, struct mbuf *); - va_end(ap); + if (m->m_type == MT_CONTROL) { + control = m; + m = m->m_next; + } else + control = NULL; in6p = sotoin6pcb(so); priv = 0; @@ -718,7 +712,11 @@ > >2/ remove all var-args.. This is a disgusting hach that makes it impossible > >for the compiler to catch mismatched functions and arguments. > >NetBSD should know better than this.. they changed it.. they can bear the costs > >of compatibility.. we are NOT going to do that. > >3/ define all prototypes in terms of predefined types to allow > >the compiler to catch wrong assignments quicker (or to change them quicker). > >(this was planned a long time ago but not done for reasons I forget) > > i can partially buy this, but for *BSD code sharing, i do need a > compromise here. permit us to use varargs. > no. it can be in the netbsd compatibility code. it's going away. > >4/ Addition of the "proto" field to output to allow ipprotosw to be completely > >removed. (the special type for that filed need not be done as I only did that > >to ensure that KAME was not using it somewhere to pass something OTHER than > >an proto type.) (other protocols can ignore this field). > > no you can't remove "proto" argument from the argument list. > because of the way ipv6 extension header chain (and IPv4 AH/ESP > header) is designed, proto argument has to be passed around, otherwise > we can't know which protocol we are processing (think of raw ip header > processing, like rip_input). I din't say remove.. I said ADD. > > 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 Sun Aug 12 14:37:46 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 6CAF937B405 for ; Sun, 12 Aug 2001 14:37:43 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f7CLa4f43385; Sun, 12 Aug 2001 17:36:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 12 Aug 2001 17:36:04 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: itojun@iijlab.net, net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B76CFD3.4C6D4DDE@elischer.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 It strikes me that, although some code cleanup may be called for, a week is too agressive a deadline for many of them to be pushed through, especially in light of the code maintenance issue on the KAME side. I suggest that we look at a more gradual approach, as there's no rush right now for 5.0-RELEASE, and attempt to address technical issues one at a time (rather than a mega-patch). This would allow changes to be integrated as necessary into the KAME tree one-by-one, allow synchronization with code on other platforms, and allow the resolution of any technical problems to be done in a manner that all consumers of the KAME code can accept. Increasing the differences between the FreeBSD and KAME trees will only serve to exacerbatese these difficilties, especially in light of other changes coming in on the FreeBSD side (such as fine-grained locking). We benefit a great deal from the work performed by the KAME team, and I think I speak for everyone on the FreeBSD side when I say that we certainly wish to continue to be able to take advantage of the KAME IP stack work :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Sun, 12 Aug 2001, Julian Elischer wrote: > Julian Elischer wrote: > > Here is the patch I will consider committing in a week (unless I see these > issues > being handled elsewhere) > > -- > +------------------------------------+ ______ _ __ > | __--_|\ 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 12 14:53:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (ip193-66-149-4.dial.kpnqwest.fi [193.66.149.4]) by hub.freebsd.org (Postfix) with ESMTP id A48C537B407 for ; Sun, 12 Aug 2001 14:53:41 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id BE5027BC; Mon, 13 Aug 2001 05:54:33 +0900 (JST) To: Julian Elischer Cc: net@freebsd.org In-reply-to: julian's message of Sun, 12 Aug 2001 13:25:22 MST. <3B76E632.28BE644@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, 13 Aug 2001 05:54:33 +0900 Message-Id: <20010812205433.BE5027BC@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 >> >1/ removal of "control" argument from rip6_input and prepend control mbuf >> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto >> >type for input. (I have not confirmed that the information in control >> >is a valid mbuf but it is an mbuf pointer). >> i don't see any "control" argument in rip6_input in kame tree, as well >> as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision >> are you looking at? >Sorry, wrong function.. it was output.... ok, >here is the fix xx_output() has never been governed by protocol switch structure and therefore ther are numerous variations we see in the tree. i don't see your problem at all. >> i can partially buy this, but for *BSD code sharing, i do need a >> compromise here. permit us to use varargs. >no. are you the one who decide the rule here? >it can be in the netbsd compatibility code. >it's going away. more #ifdef = more bug, and kame/freebsd gets left behind. i really hate all the cosmetic differences *BSD has. freebsd has more of it than anyone else. >> no you can't remove "proto" argument from the argument list. >> because of the way ipv6 extension header chain (and IPv4 AH/ESP >> header) is designed, proto argument has to be passed around, otherwise >> we can't know which protocol we are processing (think of raw ip header >> processing, like rip_input). >I din't say remove.. >I said ADD. so are you proposing to compromise protocol-independent protosw for the sake of IP? I guess your opinion is too IP centric... itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 22:12: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id F366437B401 for ; Sun, 12 Aug 2001 22:12:05 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13689; Mon, 13 Aug 2001 14:15:02 +0900 (JST) Date: Mon, 13 Aug 2001 05:19:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: prefixes advertised by routers. In-Reply-To: <20B5BA4D.2584EAB3.9513E96F@netscape.net> References: <20B5BA4D.2584EAB3.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 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, 09 Aug 2001 01:04:54 -0400, >>>>> raviprasad20@netscape.net said: > Assume that two prefix are advertised by router to hosts in the network. After some time the administrator deletes one of the prefixes and the future router advertisement will carry only one prefix. > What will hosts do with the deleted prefix? > Whether the addresses will be deleted after some time? What is this time? After the lifetime of the removed prefix expires. >> From the specs i found that the addresses are deleted only if the router advertises prefix with valid life time of zero. Whether the rtadvd daemon has to send any such message with deleted prefix life time set to zero? Yes. However, we should also note that the autoconfigured address is not (immediately) invalidated by an RA with the valid lifetime being 0, unless the RA is authenticated by IPsec. We'll see two-hour lag before the actual expiration. For more details, please read carefully RFC 2462. > I feel that the addresses should be deleted immediately if a router stops advertising the prefix. No, they shouldn't. First of all, there is no effective mechanism that a host knows a router stops advertising RA. The only thing it can is to decrement lifetimes when it does not hear succeeding RAs. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 22:12:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 34C0537B408 for ; Sun, 12 Aug 2001 22:12:41 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13702; Mon, 13 Aug 2001 14:15:25 +0900 (JST) Date: Mon, 13 Aug 2001 06:15:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Hajimu UMEMOTO Cc: roam@ringlet.net, net@FreeBSD.ORG Subject: Re: getaddrinfo() returning AF_INET only? In-Reply-To: <20010811.013242.74671505.ume@mahoroba.org> References: <20010810163757.B14158@ringworld.oblivion.bg> <20010811.013242.74671505.ume@mahoroba.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 43 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, 11 Aug 2001 01:32:42 +0900 (JST), >>>>> Hajimu UMEMOTO said: roam> Is there a configuration file or environment variable or some other roam> way to make getaddrinfo(3) not return AF_INET6 addresses even if roam> those are available? I know that most utilities that use getaddrinfo(3) roam> have an IPv4-only command-line option, but is there a way to turn it roam> on globally? > There is no option to do so. But, I believe it shouldn't cause any > problem. I also want to know why the original requester wanted to disable IPv6. Is it just a personal preference, or is there any essential problems with listing (and preferring) IPv6 addresses? > However, current getaddrinfo() doesn't see sortlist at all. It breaks > backward compatibility against gethostbyname(). So, I'm writing a > code to add sortlist facility to getaddrinfo(). Though the patch I > sent to cvs-all touches only IPv4 address, I have the version which > touches IPv6 address as well here. Once the patch is applied, you can > write as following into /etc/resolv.conf: > sortlist 0.0.0.0/0.0.0.0 ::/0 > It means I want to see IPv4 address 1st. > There is a discussion at IPng about destination address selection. > This feature may be conflict with it in the future. So, I'm wandering > if committing it into FreeBSD is better? Any suggestion? Recent KAME snaps have (partial) support of the destination address selection algorithm. At this moment, however, it does not support the flexible policy table, which is a generalization of the sortlist mechanism. Since the policy table has really an extension of sortlist, we will not be able to just reuse sortlist as an implementation of the table, when we add full support of the policy table. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 22:13: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 2302437B405 for ; Sun, 12 Aug 2001 22:13:02 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13740; Mon, 13 Aug 2001 14:16:00 +0900 (JST) Date: Mon, 13 Aug 2001 07:22:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Julian Elischer , net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <4246.997609202@itojun.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <4246.997609202@itojun.org> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 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, 12 Aug 2001 18:40:02 +0900, >>>>> itojun@iijlab.net said: >> When KAME was added the mesh was less that perfect but there was so much to >> be done that some shortcuts needed to be taken. >> >> now that time has passed some of these can be cleaned up. >> >> 1/ Merging ipprotosw.h and protosw.h >> 2/ removal of all varargs stuff from the kernel >> (this revealing the mismatched prototypes they were hiding) >> removal of lotso warnings from the KAME stuff. > the change does add pain to KAME integration side on upgrades. > note that KAME codebase uses the same code across multiple *BSDs. > please don't do this. I tend to agree with itojun. Although I understand FreeBSD guys want to make code from KAME cleaner in terms of FreeBSD's own point of view, it will make future merge from KAME to FreeBSD harder. This is a trade-off issue, but at this moment, I think we'll still need further merge from KAME to FreeBSD, so I'd prefer keeping the code "as is" for a while. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Aug 12 23:34:59 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 0E53837B40F for ; Sun, 12 Aug 2001 23:34:55 -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 XAA00455; Sun, 12 Aug 2001 23:33:44 -0700 (PDT) Message-ID: <3B777284.AA5A1DE8@elischer.org> Date: Sun, 12 Aug 2001 23:24:04 -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: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: <20010812205433.BE5027BC@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: > > >> >1/ removal of "control" argument from rip6_input and prepend control mbuf > >> >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto > >> >type for input. (I have not confirmed that the information in control > >> >is a valid mbuf but it is an mbuf pointer). > >> i don't see any "control" argument in rip6_input in kame tree, as well > >> as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision > >> are you looking at? > >Sorry, wrong function.. it was output.... > > ok, > > >here is the fix > > xx_output() has never been governed by protocol switch structure > and therefore ther are numerous variations we see in the tree. > i don't see your problem at all. then why is it in ip6protosw? julian@jules:grep rip6_output */*.c net/if_gif.c: in6_gif_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output, rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: icmp6_input, rip6_output, rip6_ctlinput, rip6_ctloutput, netinet6/in6_proto.c: encap6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: encap6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: pim6_input, rip6_output, 0, rip6_ctloutput, netinet6/in6_proto.c: rip6_input, rip6_output, 0, rip6_ctloutput, rip_output is also in protosw and I've changed that to pass a sockaddr* instead of a long. if it's in a protosw then it MUST have the same prototype as defined in the protosw. (no "if"s or "but"s) Using varargs to try hide this bug is not an acceptable answer. define ip6protosw's output to have the right definition. then it can be enforced by the compiler. > > >> i can partially buy this, but for *BSD code sharing, i do need a > >> compromise here. permit us to use varargs. > >no. > are you the one who decide the rule here? I think I can round up quite a lot of support here on NOT using varargs for things they were never designed for. The only thing varargs achieve here is the masking and hiding of bugs. I doubt that it is a design goal of KAME to hide bugs. I have seen no good argument for their use. printf's use of varargs in the kernel is shakey enough, but there is support for it in the compiler. > > >it can be in the netbsd compatibility code. > >it's going away. > > more #ifdef = more bug, and kame/freebsd gets left behind. > i really hate all the cosmetic differences *BSD has. freebsd has more > of it than anyone else. NetBSD is the one using varargs in the protosw are they not? > > >I din't say remove.. > >I said ADD. > > so are you proposing to compromise protocol-independent protosw > for the sake of IP? I guess your opinion is too IP centric... I propose to ammend our protosw to add the third argument you require. thus making the two structures the same, and then deleting the ipprotosw. It is needed for any protocol that wants to tunnel over another protocol. it could be generically useful. Certainly IP has always contrilled what is in the networking, but this need not be useful purely for IP. It must solve a class of problems that could also occur with other protocols. Certainly it's preferable to having a different structure for IP vs generic. IPV6 has it's own problems but we'll look at that later as it's still to early. > > itojun > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ 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 12 23:55:10 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 CAD6037B40D for ; Sun, 12 Aug 2001 23:55:02 -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 XAA00513 for ; Sun, 12 Aug 2001 23:41:10 -0700 (PDT) Message-ID: <3B777442.59D83AC4@elischer.org> Date: Sun, 12 Aug 2001 23:31:30 -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 Cc: net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup References: <4246.997609202@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 note: I cannot respond to this address directly. JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Sun, 12 Aug 2001 18:40:02 +0900, > >>>>> itojun@iijlab.net said: > > >> When KAME was added the mesh was less that perfect but there was so much to > >> be done that some shortcuts needed to be taken. > >> > >> now that time has passed some of these can be cleaned up. > >> > >> 1/ Merging ipprotosw.h and protosw.h > >> 2/ removal of all varargs stuff from the kernel > >> (this revealing the mismatched prototypes they were hiding) > >> removal of lotso warnings from the KAME stuff. > > > the change does add pain to KAME integration side on upgrades. > > note that KAME codebase uses the same code across multiple *BSDs. > > please don't do this. If other BSDs WANT varargs for this they are crazier than I thought. > > I tend to agree with itojun. Although I understand FreeBSD guys want > to make code from KAME cleaner in terms of FreeBSD's own point of > view, it will make future merge from KAME to FreeBSD harder. This is > a trade-off issue, but at this moment, I think we'll still need > further merge from KAME to FreeBSD, so I'd prefer keeping the code "as > is" for a while. > Although I understand KAME guys want to make code from KAME cleaner in terms of KAME's own point of view, it will make future merge from Almost anywhere else to FreeBSD harder. varargs is not an acceptable solution. please find some other method. (make a macro start that is defined differently for each platform for example). -- +------------------------------------+ ______ _ __ | __--_|\ 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 12 23:55:12 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 4E55437B40F; Sun, 12 Aug 2001 23:55: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 XAA00536; Sun, 12 Aug 2001 23:48:59 -0700 (PDT) Message-ID: <3B777616.F70D384E@elischer.org> Date: Sun, 12 Aug 2001 23:39:18 -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: Robert Watson Cc: itojun@iijlab.net, net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup References: 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 Robert Watson wrote: > > It strikes me that, although some code cleanup may be called for, a week > is too agressive a deadline for many of them to be pushed through, > especially in light of the code maintenance issue on the KAME side. I sugggest no changes in 4.x They have had over a year for cleaning it up.. how much time do they need considering I've given them patches for most of it.. > I > suggest that we look at a more gradual approach, as there's no rush right > now for 5.0-RELEASE, and attempt to address technical issues one at a time > (rather than a mega-patch). This would allow changes to be integrated as > necessary into the KAME tree one-by-one, allow synchronization with code > on other platforms, and allow the resolution of any technical problems to > be done in a manner that all consumers of the KAME code can accept. I've asked them to start working on it.. If they don't even start then I'll act but if they start cleaning up the code (90% of the WARNING messages we see in a kernel compile come from potential bugs introduced with KAME) I'm happy to let them do it at their own pace.. as long as there IS a pace. > > Increasing the differences between the FreeBSD and KAME trees will only > serve to exacerbatese these difficilties, especially in light of other > changes coming in on the FreeBSD side (such as fine-grained locking). We > benefit a great deal from the work performed by the KAME team, and I think > I speak for everyone on the FreeBSD side when I say that we certainly wish > to continue to be able to take advantage of the KAME IP stack work :-). Sure, but we need to make sure that it sticks to quality goals. How for example can you audit for correct function passing if they start using random varargs in protocol modules? what if someone wants to use a differnt combination of modules to those envisionned by the writers? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > On Sun, 12 Aug 2001, Julian Elischer wrote: > > > Julian Elischer wrote: > > > > Here is the patch I will consider committing in a week (unless I see these > > issues > > being handled elsewhere) > > > > -- > > +------------------------------------+ ______ _ __ > > | __--_|\ Julian Elischer | \ U \/ / hard at work in > > | / \ julian@elischer.org +------>x USA \ a very strange > > | ( OZ ) \___ ___ | country ! > > +- X_.---._/ presently in San Francisco \_/ \\ > > v -- +------------------------------------+ ______ _ __ | __--_|\ 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 13 1: 9:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dhcp-227.bakeoff.ipsec.com [130.233.11.227]) by hub.freebsd.org (Postfix) with ESMTP id C8BB437B40A for ; Mon, 13 Aug 2001 01:09:18 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C276E7BA; Mon, 13 Aug 2001 05:09:29 +0900 (JST) To: Julian Elischer Cc: net@freebsd.org In-reply-to: julian's message of Sun, 12 Aug 2001 10:12:19 MST. <3B76B8F3.1AC69B88@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, 13 Aug 2001 05:09:29 +0900 Message-Id: <20010812200929.C276E7BA@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 >Please note that the ip6protosw is ALSO very broken unfortunately, you are wrong. yes, protosw is supposed to be protocol-independent. however, due to the nature of IPv6 extension headers (you can have infinite number of them) you can blow the kernel stack very easily. therefore, we had to do ip6protosw.h. please read my Usenix paper (on m_pulldown and mbuf issues in BSD IPv6 support) two years ago. 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 13 1: 9:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from starfruit.itojun.org (dhcp-227.bakeoff.ipsec.com [130.233.11.227]) by hub.freebsd.org (Postfix) with ESMTP id C828E37B408 for ; Mon, 13 Aug 2001 01:09:18 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DBF2D7BB; Mon, 13 Aug 2001 05:15:30 +0900 (JST) To: Julian Elischer Cc: net@freebsd.org In-reply-to: julian's message of Sun, 12 Aug 2001 10:01:43 MST. <3B76B677.337B5E88@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, 13 Aug 2001 05:15:30 +0900 Message-Id: <20010812201530.DBF2D7BB@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 >Well what is there now is plainly unacceptable >I think that it was asked for as a VERY SHORT TERM hack. >But it has been there a long time... >I see no reasons so far to not make most of these changes.. well, you are ignoging our design decisions. they are all done for reasons. >1/ removal of "control" argument from rip6_input and prepend control mbuf >to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto >type for input. (I have not confirmed that the information in control >is a valid mbuf but it is an mbuf pointer). i don't see any "control" argument in rip6_input in kame tree, as well as freebsd sys/netinet6/raw_ip6.c revision 1.12. which revision are you looking at? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/raw_ip6.c?rev=1.12&content-type=text/x-cvsweb-markup if you are talking about rip6_ctlinput(), they are void * from the start with reason. each of the protocols can define any argument for xx_ctlinput() from the control input path. therefore, it is okay for us to define types passed up from icmp6_input() from xx_ctlinput(). >2/ remove all var-args.. This is a disgusting hach that makes it impossible >for the compiler to catch mismatched functions and arguments. >NetBSD should know better than this.. they changed it.. they can bear the costs >of compatibility.. we are NOT going to do that. >3/ define all prototypes in terms of predefined types to allow >the compiler to catch wrong assignments quicker (or to change them quicker). >(this was planned a long time ago but not done for reasons I forget) i can partially buy this, but for *BSD code sharing, i do need a compromise here. permit us to use varargs. >4/ Addition of the "proto" field to output to allow ipprotosw to be completely >removed. (the special type for that filed need not be done as I only did that >to ensure that KAME was not using it somewhere to pass something OTHER than >an proto type.) (other protocols can ignore this field). no you can't remove "proto" argument from the argument list. because of the way ipv6 extension header chain (and IPv4 AH/ESP header) is designed, proto argument has to be passed around, otherwise we can't know which protocol we are processing (think of raw ip header processing, like rip_input). 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 13 1:44:36 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 5162237B406 for ; Mon, 13 Aug 2001 01:44:32 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B410F4B20; Mon, 13 Aug 2001 17:44:29 +0900 (JST) To: Julian Elischer Cc: net@freebsd.org In-reply-to: julian's message of Sun, 12 Aug 2001 23:24:04 MST. <3B777284.AA5A1DE8@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, 13 Aug 2001 17:44:29 +0900 Message-ID: <14737.997692269@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 >> xx_output() has never been governed by protocol switch structure >> and therefore ther are numerous variations we see in the tree. >> i don't see your problem at all. >then why is it in ip6protosw? ok, I stand corrected. >> more #ifdef = more bug, and kame/freebsd gets left behind. >> i really hate all the cosmetic differences *BSD has. freebsd has more >> of it than anyone else. >NetBSD is the one using varargs in the protosw are they not? other BSDs are happy (or have almost never raised voice, or okay so far) with varargs. what's the difference in passing "control" arg in m->m_nextpkt from varargs? it's cryptic to the same degree. there's no big difference. it's the matter of taste and you are enforcing others to obey your taste. 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 13 12:32: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from shell.devco.net (shell.devco.net [196.15.188.7]) by hub.freebsd.org (Postfix) with ESMTP id C525C37B408 for ; Mon, 13 Aug 2001 12:31:56 -0700 (PDT) (envelope-from bvi@shell.devco.net) Received: from bvi by shell.devco.net with local (Exim 3.20 #2) id 15WNRg-000H7K-00; Mon, 13 Aug 2001 21:32:16 +0200 Date: Mon, 13 Aug 2001 21:32:16 +0200 From: Barry Irwin To: incidents@securityfocus.org, net@freebsd.org Subject: FreeBSD NATd problems Message-ID: <20010813213216.I684@itouchlabs.com> 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 Hi All Just wondering if anyone else has experiance the following problem: I have a number of networks running with FreeBSD firewalls providing a nat service to a number of hosts behind the wall itself. Both outgoing nat, and port_redirection is provided. THis has been running stabily for over a year. However in the last 10 days I have had a number of these natd mprocesses suddenly bloat ( looking at 48Megs upwards when they normally sit at around 700K-1Meg. Ping times to the firewalls ( infact any packets passing through the natd process are delayed, it seems to suffer a type of exponential decay, with the highest delay I have recorded being in the order of 240 seconds! At this kind of latency, network connectivity is non existant. One of the first signs of an impending slowdown is that DNS starts timing out. The firewalls are running prettey standard martian filters ( see Darft-manning-dusa03.txt) to filter out the majority of the cruft floating around. This has sofar impacted 4.0-Release, 4.1-RELEASE as well as 4.3-STABLE. Reviews of tcpdumps collected once slowdown has been noticed do not show any signs of strange activity. What I am wondering is , is there some new Scanning /DoS tool, which is causing natd to get its data structures in a knot, and thereby grow massively, in addition to the slowdown. Without having looked at the data structures in detail, it appears as tho there is a long linked list, that is getting exponentially grown, and therby accounting for the increas in memory usage, as well as the massively increased latency caused by performing lookups in the data structure chain. So back to the question, has anyone else hear/experianced/seen this ? Barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 13 12:57:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 4DE3437B401 for ; Mon, 13 Aug 2001 12:57:42 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f7DJvVA28722; Mon, 13 Aug 2001 14:57:32 -0500 (CDT) (envelope-from nick@rogness.net) Date: Mon, 13 Aug 2001 14:57:31 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Barry Irwin Cc: incidents@securityfocus.org, net@FreeBSD.ORG Subject: Re: FreeBSD NATd problems In-Reply-To: <20010813213216.I684@itouchlabs.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, 13 Aug 2001, Barry Irwin wrote: > Hi All > > Just wondering if anyone else has experiance the following problem: > > I have a number of networks running with FreeBSD firewalls providing a > nat service to a number of hosts behind the wall itself. Both outgoing > nat, and port_redirection is provided. THis has been running stabily > for over a year. However in the last 10 days I have had a number of > these natd mprocesses suddenly bloat ( looking at 48Megs upwards when > they normally sit at around 700K-1Meg. Ping times to the firewalls ( > infact any packets passing through the natd process are delayed, it > seems to suffer a type of exponential decay, with the highest delay I > have recorded being in the order of 240 seconds! > > At this kind of latency, network connectivity is non existant. One of > the first signs of an impending slowdown is that DNS starts timing > out. The firewalls are running prettey standard martian filters ( see > Darft-manning-dusa03.txt) to filter out the majority of the cruft > floating around. > > This has sofar impacted 4.0-Release, 4.1-RELEASE as well as > 4.3-STABLE. Reviews of tcpdumps collected once slowdown has been > noticed do not show any signs of strange activity. What I am > wondering is , is there some new Scanning /DoS tool, which is causing > natd to get its data structures in a knot, and thereby grow massively, > in addition to the slowdown. Turn on natd logging when this occurs and see what is happening. Submit log if necessary. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 13 21:23:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from ariel.phys.wesleyan.edu (ariel.phys.wesleyan.edu [129.133.71.143]) by hub.freebsd.org (Postfix) with ESMTP id 9D29037B403 for ; Mon, 13 Aug 2001 21:23:23 -0700 (PDT) (envelope-from vlad@ariel.phys.wesleyan.edu) Received: by ariel.phys.wesleyan.edu (Postfix, from userid 1001) id DAC9A1EA313; Tue, 14 Aug 2001 00:23:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ariel.phys.wesleyan.edu (Postfix) with ESMTP id BA8E81E6513 for ; Tue, 14 Aug 2001 00:23:23 -0400 (EDT) Date: Tue, 14 Aug 2001 00:23:23 -0400 (EDT) From: Vladimir Savichev To: Subject: altq in FreeBSD/src ? Message-ID: <20010814001143.Q59678-100000@ariel.phys.wesleyan.edu> 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 couldn't find /altq in FreeBSD/src, Open(6week)/NetBSD(7month) are up with it ? seems like many folks on fbsd's do it by hand after all. --Vlad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Aug 13 22:17:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from mndr.com (dsl081-091-099.lax1.dsl.speakeasy.net [64.81.91.99]) by hub.freebsd.org (Postfix) with ESMTP id C388837B409 for ; Mon, 13 Aug 2001 22:17:18 -0700 (PDT) (envelope-from torqumada@paladincorp.com.au) Received: from debussy.paladincorp.com.au (co3007888-a.blktn1.nsw.optushome.com.au [203.164.10.230]) by mndr.com (Postfix) with ESMTP id 2E7581F1F2F; Tue, 14 Aug 2001 05:17:17 +0000 (GMT) Received: from wagner.paladincorp.com.au (wagner.paladincorp.com.au [192.168.0.6]) by debussy.paladincorp.com.au (8.11.4/8.10.1) with ESMTP id f7E5HGf64517; Tue, 14 Aug 2001 15:17:16 +1000 (EST) Date: Tue, 14 Aug 2001 15:17:16 +1000 (EST) From: To: Vladimir Savichev Cc: net@FreeBSD.ORG Subject: Re: altq in FreeBSD/src ? In-Reply-To: <20010814001143.Q59678-100000@ariel.phys.wesleyan.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, 14 Aug 2001, Vladimir Savichev wrote: heres my howto, should work easy, i applied the frag/signal/telnet patches after applying the kame/altq patches http://www.paladincorp.com.au/unix/altq/ > > couldn't find /altq in FreeBSD/src, Open(6week)/NetBSD(7month) are up > with it ? seems like many folks on fbsd's do it by hand after all. > --Vlad Peace, 3B)+< /Torqumada -- As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. Paladin Corporation Pty Ltd. Ph:+612 9835-4782 Fax:+612 9864-0487 Software Engineering: c/c++/perl/sql/eiffel/pascal/haskell/php/java Powered by FreeBSD/SMP http://www.paladincorp.com.au/ The lyf so short, the craft so long to lerne - Chaucer This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward disclose or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 0: 1:18 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 2A6C337B409 for ; Tue, 14 Aug 2001 00:01:12 -0700 (PDT) (envelope-from keiichi@iij.ad.jp) Received: by neogw.osaka.iij.ad.jp; id QAA01015; Tue, 14 Aug 2001 16:01:11 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma001008; Tue, 14 Aug 01 16:00:24 +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 f7E70Gf02426; Tue, 14 Aug 2001 16:00:16 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Tue, 14 Aug 2001 16:00:16 +0900 Message-ID: <86elqf15z3.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B777442.59D83AC4@elischer.org> References: <4246.997609202@itojun.org> <3B777442.59D83AC4@elischer.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 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 Julian, Julian Elischer wrote: > > > I tend to agree with itojun. Although I understand FreeBSD guys want > > to make code from KAME cleaner in terms of FreeBSD's own point of > > view, it will make future merge from KAME to FreeBSD harder. This is > > a trade-off issue, but at this moment, I think we'll still need > > further merge from KAME to FreeBSD, so I'd prefer keeping the code "as > > is" for a while. > > Although I understand KAME guys want > to make code from KAME cleaner in terms of KAME's own point of > view, it will make future merge from Almost anywhere else to FreeBSD harder. Let us express that KAME code is designed for all the *BSDs. We don't have enough resources to arrange KAME code for each BSD as they want to be. Althogh I understand your point that some parts of KAME code is not a FreeBSD's manner, but currentry, this is the best compromise to support all the BSDs with minimum efforts. Please understand our approach... --- Keiichi SHIMA IIJ Research Laboratory / KAME project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 1:44: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from pikus.o2.pl (pikus.o2.pl [212.126.20.2]) by hub.freebsd.org (Postfix) with ESMTP id DDD7837B405 for ; Tue, 14 Aug 2001 01:43:55 -0700 (PDT) (envelope-from conyo@go2.pl) Received: from konradrz (unknown [195.116.201.107]) by pikus.o2.pl (Postfix) with SMTP id 8A02114764D; Tue, 14 Aug 2001 10:40:48 +0200 (CEST) Message-ID: <000b01c1249d$38bb9f10$6c66a8c0@konradrz> From: "Konrad Rzadzinski" To: "Barry Irwin" Cc: , References: <20010813213216.I684@itouchlabs.com> Subject: Re: FreeBSD NATd problems Date: Tue, 14 Aug 2001 10:43:39 +0200 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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: "Barry Irwin" : Just wondering if anyone else has experiance the following problem: Yup. FreeBSD 4.3. : I have a number of networks running with FreeBSD firewalls providing a : nat service to a number of hosts behind the wall itself. Both outgoing nat, : and port_redirection is provided. THis has been running stabily for over a : year. However in the last 10 days I have had a number of these natd : mprocesses suddenly bloat ( looking at 48Megs upwards when they normally sit : at around 700K-1Meg. Ping times to the firewalls ( infact any packets : passing through the natd process are delayed, it seems to suffer a type of : exponential decay, with the highest delay I have recorded being in the order : of 240 seconds! Same kind of things. CPU loss, network congestion. : This has sofar impacted 4.0-Release, 4.1-RELEASE as well as 4.3-STABLE. : Reviews of tcpdumps collected once slowdown has been noticed do not show any : signs of strange activity. What I am wondering is , is there some new : Scanning /DoS tool, which is causing natd to get its data structures in a : knot, and thereby grow massively, in addition to the slowdown. CodeRed, in my case. One machine (Win2000, IIS) had port 80 redirected to 'the world', got caught by this worm, infected other machines. Natd took 99% CPU time, pings were dramatically long. Cleaning infected machines (only 9 of them) helped. Now natd takes 0.1% CPU, pings are < 1 ms. As it should be :) Hope it helps. -- Konrad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 2:57:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from scan1.fhg.de (scan1.fhg.de [153.96.1.35]) by hub.freebsd.org (Postfix) with ESMTP id D300637B407 for ; Tue, 14 Aug 2001 02:57:45 -0700 (PDT) (envelope-from gerhard.butscher@esk.fhg.de) Received: from scan1.fhg.de (localhost [127.0.0.1]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id f7E9vgt11998; Tue, 14 Aug 2001 11:57:42 +0200 (MET DST) Received: from esk.esk.fhg.de (esk.esk.fhg.de [153.96.161.2]) by scan1.fhg.de (8.11.1/8.11.1) with ESMTP id f7E9vfW11994; Tue, 14 Aug 2001 11:57:41 +0200 (MET DST) Received: from esk.fhg.de (host5-14 [192.168.5.14]) by esk.esk.fhg.de (8.9.3/8.9.3) with ESMTP id LAA03444; Tue, 14 Aug 2001 11:57:39 +0200 (MET DST) Message-ID: <3B78F5E1.475FF891@esk.fhg.de> Date: Tue, 14 Aug 2001 11:56:49 +0200 From: Gerhard Butscher Organization: FhG - ESK X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de,fr MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: syslinux@linux.kernel.org, net@FreeBSD.ORG Subject: TFTP sorcerer's apprentice syndrome 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 Hello, I am using the linux (SuSE 7.0) tftp server with an embedded tftp client (running on an embedded target). I changed that client code and caused by that change a considerable amount of delay. And the Sorcerer's Apprentice Syndrome appeared: From that point where the server has sent a duplicate data packet (after the client's ACK timed out), there were always duplicate data (and of course ACK) packets until the end of the file transfer. I am not a protocol expert nor a unix programming expert but as far as I understand the tftp server code (e.g. tftp-hpa-0.21) there is a handling for duplicate ACK packets. But (maybe) not exactly the handling proposed by the RFC 1350. On paget 7 of RFC 1350 it is said: "All packets other than duplicate ACK's and those used for termination are acknowledged unless a timeout occcurs." So the strategy would be to discard the duplicate ACK and let the timer keep running. Not repeating the previous data packet - which I think is done in the existing code. The data packet would only be repeated in case of a timeout. I would appreciate if you could write a comment whether I am right or wrong or something in between. Best regards, Gerhard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 8:13:19 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 8121637B406 for ; Tue, 14 Aug 2001 08:13:10 -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 f7EFDqc45106 for ; Tue, 14 Aug 2001 18:13:53 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200108141513.f7EFDqc45106@star.rila.bg> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.3 To: freebsd-hackers@freebsd.org From: "Vladimir Terziev" Subject: tcpdump newbie question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 16:37:40 +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 hackers, I appologize for the next question if it is stuppied. How can print the IP packet length, matched by tcpdump expression? I read the tcpdump man page, but I couldn't find the answer of my question! regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 8:16:54 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 0160937B405 for ; Tue, 14 Aug 2001 08:16:50 -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 f7EFHYc45155 for ; Tue, 14 Aug 2001 18:17:34 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200108141517.f7EFHYc45155@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: tcpdump newbie question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 18:17:34 +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 hackers, I appologize for the next question if it is stuppied. How can print the IP packet length, matched by tcpdump expression? I read the tcpdump man page, but I couldn't find the answer of my question! regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 11:47:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hub.freebsd.org (Postfix) with ESMTP id 11EC437B405 for ; Tue, 14 Aug 2001 11:47:54 -0700 (PDT) (envelope-from hpa@zytor.com) Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id JAA31803; Tue, 14 Aug 2001 09:41:11 -0700 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031790; Tue, 14 Aug 01 09:40:56 -0700 Received: from tazenda.transmeta.com (tazenda.transmeta.com [10.8.42.16]) by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id JAA09061; Tue, 14 Aug 2001 09:40:57 -0700 (PDT) Received: from zytor.com (hpa@localhost [127.0.0.1]) by tazenda.transmeta.com (8.9.3/8.7.3) with ESMTP id JAA00730; Tue, 14 Aug 2001 09:40:57 -0700 Message-ID: <3B795499.4050307@zytor.com> Date: Tue, 14 Aug 2001 09:40:57 -0700 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en, sv MIME-Version: 1.0 To: Gerhard Butscher Cc: syslinux@linux.kernel.org, net@FreeBSD.ORG Subject: Re: TFTP sorcerer's apprentice syndrome References: <3B78F5E1.475FF891@esk.fhg.de> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Gerhard Butscher wrote: > Hello, > > I am using the linux (SuSE 7.0) tftp server with an embedded > tftp client (running on an embedded target). I changed that > client code and caused by that change a considerable amount of > delay. And the Sorcerer's Apprentice Syndrome appeared: > >>From that point where the server has sent a duplicate data > packet (after the client's ACK timed out), there were always > duplicate data (and of course ACK) packets until the end > of the file transfer. > > I am not a protocol expert nor a unix programming expert > but as far as I understand the tftp server code (e.g. > tftp-hpa-0.21) there is a handling for duplicate ACK packets. > But (maybe) not exactly the handling proposed by the RFC 1350. > It's hard to know if this really is Sorcerer's Apprentice without seeing a trace of the traffic. There are other pathologies that can cause this. Besides, you're talking about the "SuSE 7.0 tftp server", which definitely isn't tftp-hpa-0.21, so I don't know what baseline code you're talking about. -hpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 16:43:16 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 6F96A37B407; Tue, 14 Aug 2001 16:43:12 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from freke.odin.pdx.edu (freke.odin.pdx.edu [131.252.120.43]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f7ENhBe21237; Tue, 14 Aug 2001 16:43:11 -0700 (PDT) Received: from localhost (singh@localhost) by freke.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f7ENhBb02317; Tue, 14 Aug 2001 16:43:11 -0700 (PDT) X-Authentication-Warning: freke.odin.pdx.edu: singh owned process doing -bs Date: Tue, 14 Aug 2001 16:43:11 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Cc: Subject: TcpTrace filter option 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 Greetings! I have a querry about using tcptrace in wireless network. In sequence graphs I am getting many "hardware level dup acks". Tcptrace user manual describes filtering option to avoid "hardware level dup acks". I use following command (which gives error message) : ~/tcptrace -f num_hw_dups myTcpdumpFile I would appreciate if someone can guide me about how to use filtering option with tcptrace. Regards, Harkirat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 14 19: 1: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id C6B6937B401 for ; Tue, 14 Aug 2001 19:00:57 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA28872; Wed, 15 Aug 2001 11:03:58 +0900 (JST) Date: Wed, 15 Aug 2001 11:03:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B777442.59D83AC4@elischer.org> References: <4246.997609202@itojun.org> <3B777442.59D83AC4@elischer.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 41 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, 12 Aug 2001 23:31:30 -0700, >>>>> Julian Elischer said: >> I tend to agree with itojun. Although I understand FreeBSD guys want >> to make code from KAME cleaner in terms of FreeBSD's own point of >> view, it will make future merge from KAME to FreeBSD harder. This is >> a trade-off issue, but at this moment, I think we'll still need >> further merge from KAME to FreeBSD, so I'd prefer keeping the code "as >> is" for a while. > Although I understand KAME guys want > to make code from KAME cleaner in terms of KAME's own point of > view, it will make future merge from Almost anywhere else to FreeBSD harder. Yes, of course, you could say that. I guess this is a tradeoff issue. If we change the KAME-based code (which is shared by other *BSDs), port from KAME to FreeBSD would be harder, but other efforts to the code would be easier. If we keep the KAME-based code as is, and if the code has different logic from the FreBSD's latest one, port from KAME to FreeBSD would be easier, but other efforts to the code would be harder. I guess, at this moment, we'll still see more merge efforts to the KAME-based code from the KAME side than from others. (Of course, my view might be wrong, and even if it is the case, I don't think it's a good thing. Changing the KAME-based code according to FreeBSD might cause much more work to the code from others, and we should eventually aim at that goal.) > varargs is not an acceptable solution. please find some other method. > (make a macro start that is defined differently for each platform for example). We'll discuss the best way in the KAME team today. Through this thread, I guess your main concern is about the va_arg hack in the output routines, and we can make compromise on other points, as long as the result is friendly with compiler warnings. If my understanding is wrong, please point it out. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 15 7:31: 9 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 89A7C37B40C for ; Wed, 15 Aug 2001 07:31:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f7FEUjf80666; Wed, 15 Aug 2001 10:30:45 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 15 Aug 2001 10:30:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: itojun@iijlab.net, net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <3B777616.F70D384E@elischer.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, 12 Aug 2001, Julian Elischer wrote: > Robert Watson wrote: > > > > It strikes me that, although some code cleanup may be called for, a week > > is too agressive a deadline for many of them to be pushed through, > > especially in light of the code maintenance issue on the KAME side. > > I sugggest no changes in 4.x They have had over a year for cleaning it > up.. how much time do they need considering I've given them patches for > most of it.. Julian, I've taken a few minutes to review the archives of both the freebsd-net and freebsd-arch mailing lists, as well as the kame-snap mailings list. In the past three years worth of archives, I've found no evidence of you raising the ipprotosw-related issues. In fact, the only messages I found from you on the KAME list were cross-posts promoting netgraph, and the only posts on the -arch list relating to ipprotosw were from Yoshinobu Inoue requesting extensive review of changes he was making for KAME, to which you did not publically respond. In my experience, the KAME team has been responsive to both my questions and concerns regarding the IPv6 implementation, and so certainly my experience seems inconsistent with the sweeping assertions of un-responsiveness you have expressed; this is the experience of a number of other FreeBSD developers I have talked to concerning the KAME work in the past. While the KAME team is resource-constrained, they have been highly responsive. When working with the KAME team, it is necessary to make use of the appropriate forums, including *their* mailing lists. > > I > > suggest that we look at a more gradual approach, as there's no rush right > > now for 5.0-RELEASE, and attempt to address technical issues one at a time > > (rather than a mega-patch). This would allow changes to be integrated as > > necessary into the KAME tree one-by-one, allow synchronization with code > > on other platforms, and allow the resolution of any technical problems to > > be done in a manner that all consumers of the KAME code can accept. > > I've asked them to start working on it.. If they don't even start then > I'll act but if they start cleaning up the code (90% of the WARNING > messages we see in a kernel compile come from potential bugs introduced > with KAME) I'm happy to let them do it at their own pace.. as long as > there IS a pace. The KAME team faces a number of substantial hurdles in the task they have taken on, including the task of balancing concerns from a number of development communities other than ours. For them to realistically perform this task well, they need our cooperation and understanding of the problems they face. I'm not making a technical judgement of either their code or your changes here: I'm making an observation about the development process, and the real-world considerations that need to be made. If we want to continue to benefit from the KAME team's development efforts, we need to work with them, both to integrate their work into FreeBSD more tightly, and to contribute back to their efforts in a cooperative (and non-confrontational) manner. This means participating on the KAME mailing lists, and working with their developers to find solutions to the really hard problems, including the management of their development trees. Imagine for a moment you maintained Netgraph on the following platforms: FreeBSD, NetBSD, OpenBSD, Darwin, and BSD/OS. Each has subtly modified their network stacks, memory allocators, kernel threading and scheduling systems, and synchronization primitives. They've each made changes to the flags passed to a variety of routines, expectations for style compliance, and focus on memory and performance tradeoffs. Under those circumstances, the development of fundamentally new (and still, in many ways, experimental) technology is extremely challenging. And under those circumstances, you'd have substantial insight into the differences between the systems, and how to both manage code taking into account those differences in a resource-effective manner. This doesn't mean that you wouldn't change your code to respond to the needs of individual projects, just that your view of the world would reflect your circumstances, and that you'd attempt to find common ground. That search for common ground can only be performed with the censent of all the parties, through public discussion of the tradeoffs (and there will always be tradeoffs), and with patience rather than ultimatums. > > Increasing the differences between the FreeBSD and KAME trees will only > > serve to exacerbatese these difficilties, especially in light of other > > changes coming in on the FreeBSD side (such as fine-grained locking). We > > benefit a great deal from the work performed by the KAME team, and I think > > I speak for everyone on the FreeBSD side when I say that we certainly wish > > to continue to be able to take advantage of the KAME IP stack work :-). > > Sure, but we need to make sure that it sticks to quality goals. How for > example can you audit for correct function passing if they start using > random varargs in protocol modules? what if someone wants to use a > differnt combination of modules to those envisionned by the writers? No one is suggesting that quality goals should be sacrificed. What's being suggested is that KAME development naturally involves tradeoffs, and that in order to have the feature set they offer, we need to respect their ability to determine the necessary tradeoffs. That doesn't mean we can't attempt to change their minds about tradeoffs, possibly by presenting additional evidence, or working to build concensus with other KAME consumers, resolving some of the portability and consistency issues that currently present barriers. I won't challenge your view of architectural cleanliness: in the past, you've demonstrated high levels of competence in the area of architecture, and the ability to take on substantial challenges and come out with both clean and highly extensible abstractions. But you can't simply assert "this is the one true way, I'm committing in a week". To make assertions that the FreeBSD project mandates specific changes (of which you have made a number in your e-mails), you need to do a lot more concensus-building, and the KAME team needs to play a part in that, as they have substantial stakes in (and have made substantial contributions to) the network stack. Since your initial post, you've had a number of responses from the KAME team, both agreeing with some points and accepting changes, and noting that other points require further consideration in light of the code portability issues. They've offered you respectful and carefully thought out responses, taking into account your architectural concerns. We owe them similarly respectful (and non-confrontational) responses. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 15 10:32:11 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 6D14E37B412 for ; Wed, 15 Aug 2001 10:32:05 -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 KAA12878 for ; Wed, 15 Aug 2001 10:20:54 -0700 (PDT) Date: Wed, 15 Aug 2001 10:20:53 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup 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 Firstly I would like to appologise to the KAME folks. I think that in general they are doing a wonderful job, and I was in a bad spot at the time and let my better judgement get over-run by my annoyance at what I saw (still do) as a rather poor implementation decision. Some of the KAME folks have gotten back to me in private and I believe that my issues have been at least considered and some of them will be addressed. I'm cycling through the compile/edit/compile sequence about 50 times a day here in the KSE stuff and all the false-hits I was getting due to KAME error messages was just getting overly annoying. Then I had to actually go through the KAME code liiking for process references and came across the VARARGS stuff... it was too much.. anyhow I'm satisfied that they are doing as good of a job as they can and that they will be considering whether any changes can be made to assit compiler checking of their stacks. I will not be doing any changes that affect them, Though I may still add the prototype definitions in protsw.h as that's a generally useful thing to do. On Wed, 15 Aug 2001, Robert Watson wrote: > > On Sun, 12 Aug 2001, Julian Elischer wrote: > > > Robert Watson wrote: > > > [rebuke] julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 1:33:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6FE9E37B40F for ; Thu, 16 Aug 2001 01:33:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA12896; Thu, 16 Aug 2001 18:33:30 +1000 Date: Thu, 16 Aug 2001 18:33:29 +1000 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: Message-ID: <20010816180314.P27152-100000@besplex.bde.org> 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 will not be doing any changes that affect them, Though I may still add > the prototype definitions in protsw.h as that's a generally useful thing > to do. I think those are the least useful of your changes. They are certainly the most intrusive if the function typedefs are actually used. The corresponding function typedefs for the cdevsw functions are even less useful since all the cdevsw's are now static and the prototypes can't be used in function bodies (except for variants which give the args in a list like SYSCTL_HANDLER_ARGS, but don't go there). In most cases, forward declarations of the cdevsw functions aren't necessary provided we move the cdevsw data declarations after all the function bodies. I normally dislike shuffling code to avoid forward declarations, and like to forward-declare even static functions that are defined before they are used (since this gives an easy to find list of the functions and doesn't depend on the order of the function bodies), but the cdevsw data declaration already provides a lot of structure including a list of all the cdevsw functions, so I don't mind making a special case for it. It's normal to use a similar hack for modules (put DRIVER_MODULE() declarators at the end). Protosw's are still externed, so more declarations are needed, but that should change. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 4: 9:35 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 048F237B40B for ; Thu, 16 Aug 2001 04:09:29 -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 NAA13614 for ; Thu, 16 Aug 2001 13:09:27 +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 NAA15310; Thu, 16 Aug 2001 13:09:26 +0200 (MET DST) Received: (from lev@localhost) by melle.fkie.fgan.de (8.10.2+Sun/8.10.2) id f7GB9PF02076; Thu, 16 Aug 2001 13:09:25 +0200 (MEST) Date: Thu, 16 Aug 2001 13:09:25 +0200 (MEST) Message-Id: <200108161109.f7GB9PF02076@melle.fkie.fgan.de> From: Anastasia Leventi-Peetz To: net@FreeBSD.ORG Cc: leventi@fgan.de Subject: tunnel configuration 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 dear all, I run FreeBSD-4.0 (no changes on the generic kernel) and try to establish a tunnel between a Linux pc and the FreeBSD pc. Unfortunately there is no documentation in the book how should it work, not even for tunnel from FreeBSD to FreeBSD. I have found Information in Internet and I use of course the commands # gifconfig gif0 inet IPv4(1) IPv4(2) (tunnel endpoints) # ifconfig gif0 up # route add -inet6 3ffe:bla:bla::bla -prefixlen 64 -interface gif0 On the other side for Linux I have togive # ifconfig sit0 up # ifconfig sit0 tunnel ::IPV4(remote) # route -A inet6 add 3ffe:..etc. fe80::IPV4(remote) dev sit1 (sit1 will be automatically there when one configures sit0) This address: fe80::IPv4(remote) appears as nexthop in the routing table of the Linux pc, as well as the fe80::IPv4(local). These are addresses on Link which i don't automatically get on the FreeBSD pc! And of course I can't reach the FreeBSD and inversely if they don't understand the same on Link addresse. I hapenned to see on the routing table of a FreeBSD pc, (a side on the internet) that the fe80::IPv4 address was included. Can anybody give me a hint? It will be greatly appreciated. Regards:A.L-P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 6:14:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 924FA37B426 for ; Thu, 16 Aug 2001 06:13:58 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (k5fll3x1irrehl4z@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f7GD8iL26108 for ; Thu, 16 Aug 2001 10:08:44 -0300 Message-ID: <3B7BC5CE.7040906@tcoip.com.br> Date: Thu, 16 Aug 2001 10:08:30 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: net@freebsd.org Subject: RTM_INFO Content-Type: text/plain; charset=us-ascii; format=flowed 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 Another question... when the interface goes up and an RTM_INFO message is generated, shouldn't the interface addresses be passed? -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Raising pet electric eels is gaining a lot of current popularity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 6:14:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A2AB37B41C for ; Thu, 16 Aug 2001 06:14:04 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (pdbqjildwxmnpud8@dcs.intra.tcoip.com.br [192.168.60.194]) by purus.tcoip (8.11.1/8.11.1) with ESMTP id f7DKA9L12474; Mon, 13 Aug 2001 17:10:09 -0300 Message-ID: <3B783422.4010201@tcoip.com.br> Date: Mon, 13 Aug 2001 17:10:10 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Barry Irwin Cc: incidents@securityfocus.org, net@freebsd.org Subject: Re: FreeBSD NATd problems References: <20010813213216.I684@itouchlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Do you, by any chance, have a Microsoft IIS server running? Barry Irwin wrote: > Hi All > > Just wondering if anyone else has experiance the following problem: > > I have a number of networks running with FreeBSD firewalls providing a > nat service to a number of hosts behind the wall itself. Both outgoing nat, > and port_redirection is provided. THis has been running stabily for over a > year. However in the last 10 days I have had a number of these natd > mprocesses suddenly bloat ( looking at 48Megs upwards when they normally sit > at around 700K-1Meg. Ping times to the firewalls ( infact any packets > passing through the natd process are delayed, it seems to suffer a type of > exponential decay, with the highest delay I have recorded being in the order > of 240 seconds! > > At this kind of latency, network connectivity is non existant. One of the > first signs of an impending slowdown is that DNS starts timing out. The > firewalls are running prettey standard martian filters ( see > Darft-manning-dusa03.txt) to filter out the majority of the cruft floating > around. > > This has sofar impacted 4.0-Release, 4.1-RELEASE as well as 4.3-STABLE. > Reviews of tcpdumps collected once slowdown has been noticed do not show any > signs of strange activity. What I am wondering is , is there some new > Scanning /DoS tool, which is causing natd to get its data structures in a > knot, and thereby grow massively, in addition to the slowdown. > > Without having looked at the data structures in detail, it appears as tho > there is a long linked list, that is getting exponentially grown, and > therby accounting for the increas in memory usage, as well as the massively > increased latency caused by performing lookups in the data structure chain. > > So back to the question, has anyone else hear/experianced/seen this ? > > Barry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net An exotic young lady named Suki Once danced in a troupe of kabuki When asked for a fuck She said, "Solly, no luck-- See here: looky looky, no nuki " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 6:17: 8 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 AFD3337B40E; Thu, 16 Aug 2001 06:16:56 -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 f7GDHbc59657; Thu, 16 Aug 2001 16:17:38 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200108161317.f7GDHbc59657@star.rila.bg> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.3 To: hackers@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG From: "Vladimir Terziev" Subject: Cisco AIR-PCI 352 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Aug 2001 16:17:37 +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, The FreeBSD an driver (for Cisco Aironet cards) supports 340 series cards. I want to know if the an driver supports Cisco Aironet 350 series cards. regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 6:26:53 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 1FA2437B40D for ; Thu, 16 Aug 2001 06:26:44 -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 f7GDQBb09466; Thu, 16 Aug 2001 16:26:11 +0300 (EEST) (envelope-from ru) Date: Thu, 16 Aug 2001 16:26:11 +0300 From: Ruslan Ermilov To: "Daniel C. Sobral" Cc: net@FreeBSD.ORG Subject: Re: RTM_INFO Message-ID: <20010816162611.G73183@sunbay.com> References: <3B7BC5CE.7040906@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B7BC5CE.7040906@tcoip.com.br>; from daniel.sobral@tcoip.com.br on Thu, Aug 16, 2001 at 10:08:30AM -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 On Thu, Aug 16, 2001 at 10:08:30AM -0300, Daniel C. Sobral wrote: > Another question... when the interface goes up and an RTM_INFO message s/RTM_INFO/RTM_IFINFO > is generated, shouldn't the interface addresses be passed? > Why? In the down/up event, only interface's status changes: : # route -vn monitor : got message of size 124 on Thu Aug 16 16:19:12 2001 : RTM_DELETE: Delete Route: len 124, pid: 0, seq 0, errno 0, flags: : locks: inits: : sockaddrs: : 127.0.0.1 127.0.0.1 : : got message of size 116 on Thu Aug 16 16:19:12 2001 : RTM_DELADDR: address being removed from iface: len 116, metric 0, flags: : sockaddrs: : (0) 0 ff lo0 127.0.0.1 127.0.0.1 : : got message of size 96 on Thu Aug 16 16:19:12 2001 : RTM_IFINFO: iface status change: len 96, if# 3, flags: : : got message of size 116 on Thu Aug 16 16:21:02 2001 : RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: : sockaddrs: : (0) 0 ff lo0 127.0.0.1 127.0.0.1 : : got message of size 124 on Thu Aug 16 16:21:02 2001 : RTM_ADD: Add Route: len 124, pid: 0, seq 0, errno 0, flags: : locks: inits: : sockaddrs: : 127.0.0.1 127.0.0.1 : : got message of size 96 on Thu Aug 16 16:21:02 2001 : RTM_IFINFO: iface status change: len 96, if# 3, flags: The first three are from ``ifconfig lo0 down'', and first two of them are from in_ifscrub() which deletes interface route. The last three are from ``ifconfig lo0 up'', and first two of them are from in_ifinit() which adds interface route. 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 16 6:30: 5 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 8067637B40C for ; Thu, 16 Aug 2001 06:30:00 -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 f7GDUic59839 for ; Thu, 16 Aug 2001 16:30:44 +0300 (EEST) (envelope-from vlady@star.rila.bg) Message-Id: <200108161330.f7GDUic59839@star.rila.bg> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.3 To: net@freebsd.org From: "Vladimir Terziev" Subject: Cisco Aironet 350 series Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Aug 2001 16:30:44 +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, The FreeBSD an driver (for Cisco Aironet cards) supports 340 series cards. I want to know if the an driver supports Cisco Aironet 350 series cards. regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 8:38:18 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 14FDB37B407 for ; Thu, 16 Aug 2001 08:38:15 -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 f7GFc3n53669; Thu, 16 Aug 2001 11:38:03 -0400 (EDT) (envelope-from wollman) Date: Thu, 16 Aug 2001 11:38:03 -0400 (EDT) From: Garrett Wollman Message-Id: <200108161538.f7GFc3n53669@khavrinen.lcs.mit.edu> To: Bruce Evans Cc: Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <20010816180314.P27152-100000@besplex.bde.org> References: <20010816180314.P27152-100000@besplex.bde.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 < said: > Protosw's are still externed, so more declarations are needed, but > that should change. I have wanted to move the protosw[] entries into the individual protocols for a long time. We're already halfway there. -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 16 9:53: 6 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 D63E137B403 for ; Thu, 16 Aug 2001 09:53:03 -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 f7GGqvK54639; Thu, 16 Aug 2001 12:52:57 -0400 (EDT) (envelope-from wollman) Date: Thu, 16 Aug 2001 12:52:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200108161652.f7GGqvK54639@khavrinen.lcs.mit.edu> To: "Daniel C. Sobral" Cc: net@FreeBSD.ORG Subject: RTM_INFO In-Reply-To: <3B7BC5CE.7040906@tcoip.com.br> References: <3B7BC5CE.7040906@tcoip.com.br> 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: > Another question... when the interface goes up and an RTM_INFO message > is generated, shouldn't the interface addresses be passed? No; there is enough information in the RTM_IFINFO message for a listener to determine which interface is being referred to. At least on my machine it is in any case almost immediately preceded by an RTM_NEWADDR: # first we see the address being restored... got message of size 116 on Thu Aug 16 12:49:52 2001 RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: sockaddrs: (0) 0 ffff ff fxp0:0.d0.b7.54.3e.d3 khavrinen 18.24.4.255 # then the network route is added back... got message of size 172 on Thu Aug 16 12:49:52 2001 RTM_ADD: Add Route: len 172, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 18.24.4.0 (255) ffff ffff ff # and now our interface comes back up got message of size 96 on Thu Aug 16 12:49:52 2001 RTM_IFINFO: iface status change: len 96, if# 1, flags: -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 16 11: 8:23 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 334B737B409; Thu, 16 Aug 2001 11:08:16 -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 f7GI8Ct02493; Thu, 16 Aug 2001 11:08:12 -0700 Date: Thu, 16 Aug 2001 11:08:11 -0700 From: Brooks Davis To: Vladimir Terziev Cc: hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Cisco AIR-PCI 352 Message-ID: <20010816110811.A30894@Odin.AC.HMC.Edu> References: <200108161317.f7GDHbc59657@star.rila.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108161317.f7GDHbc59657@star.rila.bg>; from vlady@rila.bg on Thu, Aug 16, 2001 at 04:17:37PM +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 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 16, 2001 at 04:17:37PM +0300, Vladimir Terziev wrote: > The FreeBSD an driver (for Cisco Aironet cards) supports 340 series car= ds. > I want to know if the an driver supports Cisco Aironet 350 series cards. Yes they are, though the PCI cards require a two line MFC before they will work. -- 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 --9amGYk9869ThD9tj 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 iD8DBQE7fAwLXY6L6fI4GtQRAqIQAJ4zymPt7qTADSEHsaQfiIqxaD+vdACdFEz8 SwNi3tqfCyzCEgKJEj87HQc= =qub6 -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 11:14: 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 A502F37B407 for ; Thu, 16 Aug 2001 11:14:02 -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 LAA18494; Thu, 16 Aug 2001 11:01:54 -0700 (PDT) Date: Thu, 16 Aug 2001 11:01:53 -0700 (PDT) From: Julian Elischer To: Bruce Evans Cc: net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <20010816180314.P27152-100000@besplex.bde.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 Thu, 16 Aug 2001, Bruce Evans wrote: > > I will not be doing any changes that affect them, Though I may still add > > the prototype definitions in protsw.h as that's a generally useful thing > > to do. > > I think those are the least useful of your changes. They are certainly > the most intrusive if the function typedefs are actually used. yes but the rest of them have been argued against by the KAME folk and I have agreed to let them do it.. (which changes in specific terms, are you refering to?) > > The corresponding function typedefs for the cdevsw functions are even > less useful since all the cdevsw's are now static and the prototypes > can't be used in function bodies (except for variants which give the > args in a list like SYSCTL_HANDLER_ARGS, but don't go there). In most > cases, forward declarations of the cdevsw functions aren't necessary > provided we move the cdevsw data declarations after all the function > bodies. I normally dislike shuffling code to avoid forward declarations, > and like to forward-declare even static functions that are defined > before they are used (since this gives an easy to find list of the > functions and doesn't depend on the order of the function bodies), but > the cdevsw data declaration already provides a lot of structure including > a list of all the cdevsw functions, so I don't mind making a special > case for it. It's normal to use a similar hack for modules (put > DRIVER_MODULE() declarators at the end). The good thing about the typedefs is that if you change them, then you automatically change all teh prototypes that use them, which means that when you compile, you get failures on all teh functions that mismatch their prototypes which means that you HAVE to fix all the mismatching functions. Without them you just get warning messages on the structure initialisations, which you can easily miss, or ignore.. > > Protosw's are still externed, so more declarations are needed, but > that should change. That is not really relevent to what I'm describing above. > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 11:14:11 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 1D07137B407 for ; Thu, 16 Aug 2001 11:14:09 -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 LAA18496; Thu, 16 Aug 2001 11:02:45 -0700 (PDT) Date: Thu, 16 Aug 2001 11:02:45 -0700 (PDT) From: Julian Elischer To: Garrett Wollman Cc: Bruce Evans , net@FreeBSD.ORG Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: <200108161538.f7GFc3n53669@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 Thu, 16 Aug 2001, Garrett Wollman wrote: > < said: > > > Protosw's are still externed, so more declarations are needed, but > > that should change. > > I have wanted to move the protosw[] entries into the individual > protocols for a long time. We're already halfway there. yes, but it is orthogonal to the issue I was trying to address. > > -GAWollman > > > 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 Thu Aug 16 11:25:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 625E337B40B for ; Thu, 16 Aug 2001 11:25:11 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (3xb5onovkbv0gop3@dcs.intra.tcoip.com.br [192.168.60.194]) by mail.tcoip.com.br (8.11.1/8.11.1) with ESMTP id f7GILsS03450; Thu, 16 Aug 2001 15:21:54 -0300 Message-ID: <3B7C0F33.3080100@tcoip.com.br> Date: Thu, 16 Aug 2001 15:21:39 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: RTM_INFO References: <3B7BC5CE.7040906@tcoip.com.br> <200108161652.f7GGqvK54639@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Garrett Wollman wrote: > < said: > > >>Another question... when the interface goes up and an RTM_INFO message >>is generated, shouldn't the interface addresses be passed? >> > > No; there is enough information in the RTM_IFINFO message for a > listener to determine which interface is being referred to. At least > on my machine it is in any case almost immediately preceded by an > RTM_NEWADDR: > > # first we see the address being restored... > got message of size 116 on Thu Aug 16 12:49:52 2001 > RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: > sockaddrs: > (0) 0 ffff ff fxp0:0.d0.b7.54.3e.d3 khavrinen 18.24.4.255 > > # then the network route is added back... > got message of size 172 on Thu Aug 16 12:49:52 2001 > RTM_ADD: Add Route: len 172, pid: 0, seq 0, errno 0, flags: > locks: inits: > sockaddrs: > 18.24.4.0 (255) ffff ffff ff > > # and now our interface comes back up > got message of size 96 on Thu Aug 16 12:49:52 2001 > RTM_IFINFO: iface status change: len 96, if# 1, flags: Funny. I don't see RTM_NEWADDR being generated. Of course, no route is added when the interface is simply brought up. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Include me out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 11:31: 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 5D3A537B405; Thu, 16 Aug 2001 11:31:00 -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 LAA18601; Thu, 16 Aug 2001 11:39:29 -0700 (PDT) Date: Thu, 16 Aug 2001 11:39:28 -0700 (PDT) From: Julian Elischer To: Brooks Davis Cc: Vladimir Terziev , hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Cisco AIR-PCI 352 In-Reply-To: <20010816110811.A30894@Odin.AC.HMC.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 What is the MFC? will it be in 4.4? If not it might be a good thing to try get it in.. On Thu, 16 Aug 2001, Brooks Davis wrote: > On Thu, Aug 16, 2001 at 04:17:37PM +0300, Vladimir Terziev wrote: > > The FreeBSD an driver (for Cisco Aironet cards) supports 340 series cards. > > I want to know if the an driver supports Cisco Aironet 350 series cards. > > Yes they are, though the PCI cards require a two line MFC before they > will work. > > -- Brooks > > -- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 11:32:57 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 A7C8737B40B; Thu, 16 Aug 2001 11:32:48 -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 f7GIWin05121; Thu, 16 Aug 2001 11:32:44 -0700 Date: Thu, 16 Aug 2001 11:32:44 -0700 From: Brooks Davis To: Julian Elischer Cc: Vladimir Terziev , hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Cisco AIR-PCI 352 Message-ID: <20010816113244.A4905@Odin.AC.HMC.Edu> References: <20010816110811.A30894@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Thu, Aug 16, 2001 at 11:39:28AM -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 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 16, 2001 at 11:39:28AM -0700, Julian Elischer wrote: > What is the MFC? > will it be in 4.4? > If not it might be a good thing to try get it in.. It adds a PCI id. I just sent a request to MFC the change. -- 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 --gBBFr7Ir9EOA20Yy 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 iD8DBQE7fBHLXY6L6fI4GtQRAnPvAJ0acpprBRJ/UxrGbkaWJyXEJrXRLACgs6+U s2w1mVh2GhRNq4J5O6PiC5U= =IQYU -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 11:55: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id F1BFE37B407; Thu, 16 Aug 2001 11:55:01 -0700 (PDT) (envelope-from daniel.sobral@tcoip.com.br) Received: from tcoip.com.br (8b84culnbhv40vju@dcs.intra.tcoip.com.br [192.168.60.194]) by mail.tcoip.com.br (8.11.1/8.11.1) with ESMTP id f7GIsbS04365; Thu, 16 Aug 2001 15:54:37 -0300 Message-ID: <3B7C16DD.5020100@tcoip.com.br> Date: Thu, 16 Aug 2001 15:54:21 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: RTM_INFO References: <3B7BC5CE.7040906@tcoip.com.br> <20010816162611.G73183@sunbay.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Ruslan Ermilov wrote: > On Thu, Aug 16, 2001 at 10:08:30AM -0300, Daniel C. Sobral wrote: > >>Another question... when the interface goes up and an RTM_INFO message >> > s/RTM_INFO/RTM_IFINFO > >>is generated, shouldn't the interface addresses be passed? >> >> > Why? In the down/up event, only interface's status changes: So interested parties may get that if they want. Actually Solaris does not generate events for interface address changes on an interface that is down, but apparently does pass the if addresses on RTM_IFINFO (meaning Zebra plays nice with Solaris but not with FreeBSD). > : # route -vn monitor Damn, I wrote a whole program to do just that! > : got message of size 124 on Thu Aug 16 16:19:12 2001 > : RTM_DELETE: Delete Route: len 124, pid: 0, seq 0, errno 0, flags: > : locks: inits: > : sockaddrs: > : 127.0.0.1 127.0.0.1 > : > : got message of size 116 on Thu Aug 16 16:19:12 2001 > : RTM_DELADDR: address being removed from iface: len 116, metric 0, flags: > : sockaddrs: > : (0) 0 ff lo0 127.0.0.1 127.0.0.1 > : > : got message of size 96 on Thu Aug 16 16:19:12 2001 > : RTM_IFINFO: iface status change: len 96, if# 3, flags: > : > : got message of size 116 on Thu Aug 16 16:21:02 2001 > : RTM_NEWADDR: address being added to iface: len 116, metric 0, flags: > : sockaddrs: > : (0) 0 ff lo0 127.0.0.1 127.0.0.1 > : > : got message of size 124 on Thu Aug 16 16:21:02 2001 > : RTM_ADD: Add Route: len 124, pid: 0, seq 0, errno 0, flags: > : locks: inits: > : sockaddrs: > : 127.0.0.1 127.0.0.1 > : > : got message of size 96 on Thu Aug 16 16:21:02 2001 > : RTM_IFINFO: iface status change: len 96, if# 3, flags: > > The first three are from ``ifconfig lo0 down'', and first two of them are from > in_ifscrub() which deletes interface route. > > The last three are from ``ifconfig lo0 up'', and first two of them are from > in_ifinit() which adds interface route. Funny, my results are somewhat different: got message of size 96 on Thu Aug 16 15:39:06 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: got message of size 140 on Thu Aug 16 15:39:06 2001 RTM_ADD: Add Route: len 140, pid: 3310, seq 885, errno 0, flags: locks: inits: sockaddrs: 10.9.33.0 172.31.199.3 (0) 0 ffff 80ff 0 0 0 0 got message of size 96 on Thu Aug 16 15:39:17 2001 RTM_IFINFO: iface status change: len 96, if# 8, flags: First is ifconfig vlan2 down, second is OSPF rerouting it, third is ifconfig vlan2 up. -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net A proper wife should be as obedient as a slave... The female is a female by virtue of a certain lack of qualities -- a natural defectiveness. -- Aristotle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 12: 4:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5636137B406; Thu, 16 Aug 2001 12:04:25 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f7GJ4Nq17687; Thu, 16 Aug 2001 13:04:23 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f7GJ4MW34797; Thu, 16 Aug 2001 13:04:23 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200108161904.f7GJ4MW34797@harmony.village.org> To: "Vladimir Terziev" Subject: Re: Cisco AIR-PCI 352 Cc: hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-reply-to: Your message of "Thu, 16 Aug 2001 16:17:37 +0300." <200108161317.f7GDHbc59657@star.rila.bg> References: <200108161317.f7GDHbc59657@star.rila.bg> Date: Thu, 16 Aug 2001 13:04:22 -0600 From: Warner Losh 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 message <200108161317.f7GDHbc59657@star.rila.bg> "Vladimir Terziev" writes: : The FreeBSD an driver (for Cisco Aironet cards) supports 340 series cards. : I want to know if the an driver supports Cisco Aironet 350 series cards. Yes. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 13:33:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from quarter.csl.sri.com (quarter.csl.sri.com [130.107.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 6282E37B40D; Thu, 16 Aug 2001 13:33:42 -0700 (PDT) (envelope-from hogsett@csl.sri.com) Received: from glob.csl.sri.com (glob.csl.sri.com [130.107.15.161]) by quarter.csl.sri.com (8.11.1/8.11.1) with ESMTP id f7GKXgP29709; Thu, 16 Aug 2001 13:33:42 -0700 Received: from glob.csl.sri.com (hogsett@localhost) by glob.csl.sri.com (8.11.2/8.8.7) with ESMTP id f7GKXfA10365; Thu, 16 Aug 2001 13:33:41 -0700 Message-Id: <200108162033.f7GKXfA10365@glob.csl.sri.com> X-Authentication-Warning: glob.csl.sri.com: hogsett owned process doing -bs To: freebsd-net@freebsd.org Cc: Mike Smith , hogsett@csl.sri.com Subject: Question : vlan -> fec -> fxp Date: Thu, 16 Aug 2001 13:33:01 -0700 From: Mike Hogsett 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 Previously I had been posting to freebsd-stable regarding my questions, but this seems to be a better list for this. First let me explain my goal, then I will explain the problem. My goal is to use two fxp's "bonded" together using the fast ether channel netgraph module ( from http://people.freebsd.org/~wpaul/FEC/ ) then create n vlan interfaces with the fec0 interface as the parent dev for the vlan interfaces. fxp0 fxp1 \________/ | fec0 / | \ / | \ / | \ vlan0 vlan1 vlanN I have built and installed a new kernel with "pseudo-device vlan 1" and have built and installed the fec module. I have confirmed that fxp{0,1} interfaces work stand alone. I have confirmed that the fec0 interface works (using "set_mode_inet"). I have confirmed that the vlan interfaces work when the parent device is either fxp0 or fxp1. What does not work is when the fec0 interface is the parent for the vlan interfaces. Here is the setup : ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"fxp0"' ngctl msg fec0: add_iface '"fxp1"' ngctl msg fec0: set_mode_mac #(I have also tried using "set_mode_inet") ifconfig fxp0 up ifconfig fxp1 up ifconfig fec0 up ifconfig vlan0 192.168.1.10 netmask 255.255.255.0 vlan 505 vlandev fec0 up mtu 1500 Nothing complains. The interfaces all look good in ifconfig, mtu's are correct, all are "UP". When pinging this machine from another machine on the lan here is the behavior that I get : Running "tcpdump -ni vlan0" shows the arp requests and the arp replies Running "tcpdump -ni fec0" shows the 802.1q tagged arp reqests and the arp replies Running "tcpdump -ni fxp{0,1}" shows the 802.1q tagged arp requests So the packets climb the chain but seem to enter a blackhole back down... Suggestions? - Michael Hogsett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 16:53:41 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 44DB537B408; Thu, 16 Aug 2001 16:53:35 -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 f7GNrUv08053; Thu, 16 Aug 2001 16:53:30 -0700 Date: Thu, 16 Aug 2001 16:53:30 -0700 From: Brooks Davis To: Brooks Davis Cc: Vladimir Terziev , hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Cisco AIR-PCI 352 Message-ID: <20010816165330.A3920@Odin.AC.HMC.Edu> References: <200108161317.f7GDHbc59657@star.rila.bg> <20010816110811.A30894@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010816110811.A30894@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Aug 16, 2001 at 11:08:11AM -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 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 16, 2001 at 11:08:11AM -0700, Brooks Davis wrote: > On Thu, Aug 16, 2001 at 04:17:37PM +0300, Vladimir Terziev wrote: > > The FreeBSD an driver (for Cisco Aironet cards) supports 340 series c= ards. > > I want to know if the an driver supports Cisco Aironet 350 series cards. >=20 > Yes they are, though the PCI cards require a two line MFC before they > will work. I've MFC'd the change to detect 350 Series PCI cards. -- 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 --liOOAslEiF7prFVr 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 iD8DBQE7fFz6XY6L6fI4GtQRArybAJ9ZcYWGFBciyOQQm3/FkEdUgCz59wCeJs5x HJIcyN91WVQEGjv+inpwzeQ= =OteU -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 23:22:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 47AA537B434 for ; Thu, 16 Aug 2001 23:22:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA21174; Fri, 17 Aug 2001 16:22:46 +1000 Date: Fri, 17 Aug 2001 16:22:44 +1000 (EST) From: Bruce Evans X-X-Sender: To: Julian Elischer Cc: Subject: Re: IPV6/KAME/protosw integration cleanup In-Reply-To: Message-ID: <20010817161114.S34202-100000@besplex.bde.org> 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 Thu, 16 Aug 2001, Julian Elischer wrote: > On Thu, 16 Aug 2001, Bruce Evans wrote: > > > > I will not be doing any changes that affect them, Though I may still add > > > the prototype definitions in protsw.h as that's a generally useful thing > > > to do. > > > > I think those are the least useful of your changes. They are certainly > > the most intrusive if the function typedefs are actually used. > > yes but the rest of them have been argued against by the KAME folk > and I have agreed to let them do it.. > (which changes in specific terms, are you refering to?) Function typedefs. > The good thing about the typedefs is that > if you change them, then you automatically change all teh prototypes that > use them, So there is no benefit if no prototypes use them. > which means that when you compile, you get failures on all teh > functions that mismatch their prototypes which means that you HAVE to fix > all the mismatching functions. Without them you just get warning messages > on the structure initialisations, which you can easily miss, or ignore.. They aren't easy to miss :-). You see them once every time you build a kernel with them configured. I think it's just a gcc "feature" that mismatches in initializers are only warnings. Warnings for initializers can be suppressed using casts. That is really evil (worse than varargs :-) but we do it for syscalls and vops. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 23:24:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from rbn-gw.bgtu.debryansk.ru (rbn-gw.bgtu.debryansk.ru [62.76.89.2]) by hub.freebsd.org (Postfix) with ESMTP id 30DC137B40D for ; Thu, 16 Aug 2001 23:24:41 -0700 (PDT) (envelope-from kapr@acm.org) Received: from server.bitmcnit.bryansk.su (root@bitmcnit.bryansk.su [192.168.121.2]) by rbn-gw.bgtu.debryansk.ru (8.11.2/8.11.2) with ESMTP id f7H6L0S01338 for ; Fri, 17 Aug 2001 10:21:00 +0400 Received: (from uucp@localhost) by server.bitmcnit.bryansk.su (8.9.3/8.9.3) with UUCP id LAA05045 for freebsd-net@freebsd.org; Thu, 16 Aug 2001 11:05:34 +0400 Received: (from alex@localhost) by kapran.bitmcnit.bryansk.su (8.11.4/8.11.4) id f7G7BnD01440 for freebsd-net@freebsd.org; Thu, 16 Aug 2001 11:11:49 +0400 (MSD) (envelope-from kapr@acm.org) X-Authentication-Warning: kapran.bitmcnit.bryansk.su: alex set sender to kapr@acm.org using -f Date: Thu, 16 Aug 2001 11:11:48 +0400 From: Alex Kapranoff To: freebsd-net@FreeBSD.ORG Subject: What is 'checksum offload'? Message-ID: <20010816111147.A1328@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i X-Operating-System: FreeBSD 5.0-CURRENT i386 Organization: Inner Mongolia 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 Good day, I'm in the process of translation release notes and have trouble understanding and thus interpreting the term 'checksum offload' which is a feature of nge(4) and lge(4) drivers. Does it mean that the controllers are able to compute TCP/IP checksums in hardware thus taking off load from CPU? Don't hesitate to tell me I'm stupid and this has nothing to do with TCP/IP :) Oh, and what's a jumbogram? Can someone clarify this with one or two sentences to a man with a negligible Ethernet knowledge? Thanks! -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 5457 hours in the brand new millenium... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 16 23:29:39 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 8CB6B37B405 for ; Thu, 16 Aug 2001 23:29:36 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 592FE81D07; Fri, 17 Aug 2001 01:29:26 -0500 (CDT) Date: Fri, 17 Aug 2001 01:29:26 -0500 From: Alfred Perlstein To: Alex Kapranoff Cc: freebsd-net@FreeBSD.ORG Subject: Re: What is 'checksum offload'? Message-ID: <20010817012926.O38066@elvis.mu.org> References: <20010816111147.A1328@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010816111147.A1328@kapran.bitmcnit.bryansk.su>; from kapr@acm.org on Thu, Aug 16, 2001 at 11:11:48AM +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 * Alex Kapranoff [010817 01:24] wrote: > Good day, > > I'm in the process of translation release notes and have trouble > understanding and thus interpreting the term 'checksum offload' which is > a feature of nge(4) and lge(4) drivers. Does it mean that the > controllers are able to compute TCP/IP checksums in hardware thus taking > off load from CPU? Don't hesitate to tell me I'm stupid and this has > nothing to do with TCP/IP :) Yes, that's the point of checksum offloading. > Oh, and what's a jumbogram? Large frames, larger than standard ethernet MTU, afaik they're 8 or 9k. -- -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 Fri Aug 17 1:30:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from nu.cuk.nu (nu.cuk.nu [212.30.95.50]) by hub.freebsd.org (Postfix) with ESMTP id 964E037B409; Fri, 17 Aug 2001 01:30:29 -0700 (PDT) (envelope-from cuk@cuk.nu) Received: from localhost (localhost.nu.cuk.nu [127.0.0.1]) by nu.cuk.nu (Postfix) with ESMTP id B0CDC1AB62; Fri, 17 Aug 2001 10:30:34 +0200 (CEST) Received: from cuk.nu (note.nat.xenya.si [192.168.1.223]) by nu.cuk.nu (Postfix) with ESMTP id 3006D1AB64; Fri, 17 Aug 2001 10:30:33 +0200 (CEST) Message-ID: <3B7CD61F.5B03B8D8@cuk.nu> Date: Fri, 17 Aug 2001 10:30:23 +0200 From: Marko Cuk X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: gif tunnel timeout problems References: <200108170358.f7H3wfW37532@harmony.village.org> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Virus-Scanned: by Cuk.Nu server -- This e-mail is virus clean 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 noticed, that over a certain period of time, if there is no packets going trough tunnel, other side of tunnel becomes unreachable. I must ping or made a connection to physical address to reestablish connection or ping tunneling IP class on other side and wait for 10 -15 seconds to reestablish tunnel. Strange. I have that problem in 4.3 release cvsupped before month ago and the problem persists in newer versions ( when gif has been modified ). Many thanks, Cuk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 5:54:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by hub.freebsd.org (Postfix) with ESMTP id D9DFE37B409; Fri, 17 Aug 2001 05:54:18 -0700 (PDT) (envelope-from keiichi@iij.ad.jp) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA07377; Fri, 17 Aug 2001 21:54:16 +0900 (JST) Received: from keiichi00.osaka.iij.ad.jp (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA01346; Fri, 17 Aug 2001 21:54:16 +0900 (JST) Date: Fri, 17 Aug 2001 21:54:49 +0900 Message-ID: <877kw2q21y.wl@keiichi00.osaka.iij.ad.jp> From: Keiichi SHIMA To: Marko Cuk Cc: stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: gif tunnel timeout problems In-Reply-To: <3B7CD61F.5B03B8D8@cuk.nu> References: <200108170358.f7H3wfW37532@harmony.village.org> <3B7CD61F.5B03B8D8@cuk.nu> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 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 Marko, Marko Cuk wrote: > > I have noticed, that over a certain period of time, if there is no packets going trough tunnel, other side of tunnel becomes unreachable. Could you show us your network configuration of both sides? Also, how long time does it take from when you have succeeded to communicate with the other tunnel end to when you see the problem? > I must ping or made a connection to physical address to reestablish connection or ping tunneling IP class on other side and wait for 10 -15 seconds to reestablish tunnel. > > Strange. I have that problem in 4.3 release cvsupped before month ago and the problem persists in newer versions ( when gif has been modified ). The routing table information, arp/ndp table information of BEFORE the problem and AFTER the problem may help. Please capture these information using netstat -nr, arp -na, ndp -na and show us too. --- Keiichi SHIMA Internet Initiative Japan Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 7:22:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from chrobd01.vailsys.com (chrobd01.vailsys.com [63.210.102.138]) by hub.freebsd.org (Postfix) with ESMTP id 3A39837B407 for ; Fri, 17 Aug 2001 07:22:53 -0700 (PDT) (envelope-from hal@vailsys.com) Received: from area51.vail (area51.vail [192.168.129.30]) by chrobd01.vailsys.com (Postfix) with ESMTP id D41B94976 for ; Fri, 17 Aug 2001 09:22:47 -0500 (CDT) Received: from gamera.vail (gamera.vail [172.16.15.1]) by area51.vail (8.9.3/8.9.3) with ESMTP id JAA64079 for ; Fri, 17 Aug 2001 09:22:47 -0500 (CDT) (envelope-from hal@vailsys.com) Received: (from hal@localhost) by gamera.vail (8.11.4/8.11.3) id f7HEMkw05924; Fri, 17 Aug 2001 09:22:46 -0500 (CDT) X-Authentication-Warning: gamera.vail: hal set sender to hal@vailsys.com using -f To: freebsd-net@FreeBSD.ORG Subject: Re: What is 'checksum offload'? References: <20010816111147.A1328@kapran.bitmcnit.bryansk.su> <20010817012926.O38066@elvis.mu.org> From: Hal Snyder Date: 17 Aug 2001 09:22:45 -0500 In-Reply-To: <20010817012926.O38066@elvis.mu.org> (Alfred Perlstein's message of "Fri, 17 Aug 2001 01:29:26 -0500") Message-ID: <87g0aqlqa2.fsf@gamera.vail> Lines: 11 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) 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 Alfred Perlstein writes: > * Alex Kapranoff [010817 01:24] wrote: ... >> Oh, and what's a jumbogram? > > Large frames, larger than standard ethernet MTU, afaik they're > 8 or 9k. I thought it was an IPv6 packet with payload >= 2^16 bytes. rfc2675 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 9:28:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (softweyr.com [208.247.99.111]) by hub.freebsd.org (Postfix) with ESMTP id D6D9A37B409 for ; Fri, 17 Aug 2001 09:28:07 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from wes by softweyr.com with local (Exim 3.22 #1) id 15XmYz-00098f-00; Fri, 17 Aug 2001 10:33:37 -0600 Subject: Re: What is 'checksum offload'? To: hal@vailsys.com (Hal Snyder) Date: Fri, 17 Aug 2001 10:33:37 -0600 (MDT) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <87g0aqlqa2.fsf@gamera.vail> from "Hal Snyder" at Aug 17, 2001 09:22:45 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Wes Peters 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 > > Alfred Perlstein writes: > > > * Alex Kapranoff [010817 01:24] wrote: > ... > >> Oh, and what's a jumbogram? > > > > Large frames, larger than standard ethernet MTU, afaik they're > > 8 or 9k. > > I thought it was an IPv6 packet with payload >= 2^16 bytes. > rfc2675 "Jumbo Frames" are (gigabit) ethernet data frames holding up to 9 Kbytes. I am certain "jumbogram" is referring to the same thing. -- Wes Peters To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 14:22:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from ginsberg.uol.com.br (ginsberg.uol.com.br [200.231.206.26]) by hub.freebsd.org (Postfix) with ESMTP id 98C5937B405 for ; Fri, 17 Aug 2001 14:22:38 -0700 (PDT) (envelope-from tirloni@users.sourceforge.net) Received: from 200191083238-dial-user-UOL.acessonet.com.br (200191083238-dial-user-UOL.acessonet.com.br [200.191.83.238]) by ginsberg.uol.com.br (8.9.1/8.9.1) with ESMTP id SAA23390; Fri, 17 Aug 2001 18:20:35 -0300 (BRT) Date: Fri, 17 Aug 2001 18:22:19 -0300 (BRT) From: Giovanni Picoli Tirloni X-X-Sender: To: Alfred Perlstein Cc: Subject: Re: What is 'checksum offload'? In-Reply-To: <20010817012926.O38066@elvis.mu.org> Message-ID: <20010817181316.R370-100000@mink.ath.cx> 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'm in the process of translation release notes and have trouble > > understanding and thus interpreting the term 'checksum offload' which is > > a feature of nge(4) and lge(4) drivers. Does it mean that the > > controllers are able to compute TCP/IP checksums in hardware thus taking > > off load from CPU? Don't hesitate to tell me I'm stupid and this has > > nothing to do with TCP/IP :) > > Yes, that's the point of checksum offloading. Is there a FastEthernet card that has this feature? I'm not sure if it'd be all that useful since the throughput isn't as high as in gigabit ethernet but perhaps it has its uses in a CPU limited device. Just curious. -- Giovanni Pohl's law: Nothing is so good that somebody, somewhere, will not hate it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 14:47:50 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 C7E8D37B408 for ; Fri, 17 Aug 2001 14:47:42 -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 f7HLk1V31803; Fri, 17 Aug 2001 14:46:01 -0700 Date: Fri, 17 Aug 2001 14:46:01 -0700 From: Brooks Davis To: Giovanni Picoli Tirloni Cc: Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: Re: What is 'checksum offload'? Message-ID: <20010817144601.A30703@Odin.AC.HMC.Edu> References: <20010817012926.O38066@elvis.mu.org> <20010817181316.R370-100000@mink.ath.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010817181316.R370-100000@mink.ath.cx>; from tirloni@users.sourceforge.net on Fri, Aug 17, 2001 at 06:22:19PM -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 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2001 at 06:22:19PM -0300, Giovanni Picoli Tirloni wrote: >=20 > Is there a FastEthernet card that has this feature? I'm not sure if > it'd be all that useful since the throughput isn't as high as in > gigabit ethernet but perhaps it has its uses in a CPU limited device. > Just curious. Yes. The cards supported by the txp driver support checksum offloading, however, the driver currently supports it on recieve only. -- 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 --5mCyUwZo2JvN/JJP 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 iD8DBQE7fZCZXY6L6fI4GtQRAoyCAKCqUFvfQVbwG3oKuY+a80j3efD1hQCgy1mm HVblHwHN9msGSbN9IrJ5uSU= =ifJq -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 17 19:12:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from firewall.crimsonwasteland.com (cx154799-b.btnrug1.la.home.com [24.181.119.107]) by hub.freebsd.org (Postfix) with SMTP id 3E44237B410 for ; Fri, 17 Aug 2001 19:11:54 -0700 (PDT) (envelope-from lists-freebsd-stable@crimsonwasteland.com) Received: (qmail 23916 invoked from network); 18 Aug 2001 02:11:53 -0000 Received: from travis.crimsonwasteland.com (HELO travis) (172.16.69.2) by cx154799-b.btnrug1.la.home.com with SMTP; 18 Aug 2001 02:11:53 -0000 From: "Travis Leuthauser" To: Subject: IPSec VPN tunnel question Date: Fri, 17 Aug 2001 21:11:52 -0500 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.50.4522.1200 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 am trying to setup an IPSec based VPN between my FreeBSD server, which is running IPFW w/ a custom ruleset and NATD for my home network, and a Netopia R9100 Dual Ethernet router. I am attempting to use IPSec/tunnel/esp/hmac-md5 authentication/no encryption. Below is my configuration: Output from 'uname -a': FreeBSD firewall.crimsonwasteland.com 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE #0: Sat Aug 11 09:30:22 GMT 2001 root@firewall.crimsonwasteland.com:/usr/obj/usr/src/sys/FIREWALL i386 Public IP on xl0: 24.181.119.107 Private IP on xl1: 172.16.69.1 Public IP on Netopia: x.x.x.x Private IP on Netopia: 172.16.250.1 Snippet of IPFW Ruleset: 00010 allow ip from any to x.x.x.x out xmit gif0 00020 allow ip from x.x.x.x to any in recv gif0 00030 allow ip from any to 172.16.250.0/24 out xmit gif0 00040 allow ip from 172.16.250.0/24 to any in recv gif0 00050 divert 8668 ip from any to any via xl0 00100 allow ip from any to any via lo0 00200 deny log ip from any to 127.0.0.0/8 00300 deny log ip from 127.0.0.0/8 to any ... Several rules allowing specific services ... 65500 deny log ip from any to any Output from ifconfig gif0: gif0: flags=8051 mtu 1280 tunnel inet 24.181.119.107 --> x.x.x.x inet 172.16.69.1 --> 172.16.250.1 netmask 0xffffff00 inet6 fe80::204:76ff:fe6f:7136%gif0 prefixlen 64 scopeid 0x8 Output from setkey -D: x.x.x.x 24.181.119.107 esp mode=tunnel spi=2568731067(0x991bb9bb) reqid=0(0x00000000) E: null A: hmac-md5 75b916ac 534cef32 d3db8a44 cf5b62c1 replay=0 flags=0x00000040 state=mature seq=1 pid=23835 created: Aug 17 20:53:11 2001 current: Aug 17 20:53:14 2001 diff: 3(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 24.181.119.107 x.x.x.x esp mode=tunnel spi=2568731067(0x991bb9bb) reqid=0(0x00000000) E: null A: hmac-md5 75b916ac 534cef32 d3db8a44 cf5b62c1 replay=0 flags=0x00000040 state=mature seq=0 pid=23835 created: Aug 17 20:53:11 2001 current: Aug 17 20:53:14 2001 diff: 3(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 Output from setkey -DP: 172.16.250.0/24[any] 172.16.69.0/24[any] any in ipsec esp/tunnel/x.x.x.x-24.181.119.107/require spid=10 seq=1 pid=23842 refcnt=1 172.16.69.0/24[any] 172.16.250.0/24[any] any out ipsec esp/tunnel/24.181.119.107-x.x.x.x/require spid=9 seq=0 pid=23842 refcnt=1 Output from netstat -nr: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 24.181.118.1 UGSc 30 234144 xl0 24.181.118/23 link#1 UC 2 0 xl0 24.181.118.1 0:50:b:7:44:1c UHLW 28 0 xl0 1199 24.181.119.107 0:4:76:6f:71:36 UHLW 0 2 lo0 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16.69/24 link#2 UC 4 0 xl1 172.16.69.1 0:4:76:6f:71:4e UHLW 1 8107 lo0 172.16.69.2 0:10:4b:33:79:b9 UHLW 6 752816 xl1 1198 172.16.69.254 link#2 UHLW 1 9836 xl1 172.16.69.255 ff:ff:ff:ff:ff:ff UHLWb 2 1523 xl1 172.16.250.1 172.16.69.1 UH 0 25 gif0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%xl0/64 link#1 UC xl0 fe80::204:76ff:fe6f:7136%xl0 0:4:76:6f:71:36 UHL lo0 fe80::%xl1/64 link#2 UC xl1 fe80::204:76ff:fe6f:714e%xl1 0:4:76:6f:71:4e UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#4 UHL lo0 fe80::%gif0/64 link#8 UC gif0 fe80::204:76ff:fe6f:7136%gif0 link#8 UHL lo0 ff01::/32 ::1 U lo0 ff02::%xl0/32 link#1 UC xl0 ff02::%xl1/32 link#2 UC xl1 ff02::%lo0/32 ::1 UC lo0 ff02::%gif0/32 link#8 UC gif0 Snippet from dmesg: Aug 7 09:43:35 firewall /kernel: Copyright (c) 1992-2001 The FreeBSD Project. Aug 7 09:43:35 firewall /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 7 09:43:35 firewall /kernel: The Regents of the University of California. All rights reserved. Aug 7 09:43:35 firewall /kernel: FreeBSD 4.4-PRERELEASE #6: Tue Aug 7 08:18:34 GMT 2001 Aug 7 09:43:35 firewall /kernel: korak@firewall.crimsonwasteland.com:/usr/src/sys/compile/FIREWALL Aug 7 09:43:35 firewall /kernel: Timecounter "i8254" frequency 1193182 Hz Aug 7 09:43:35 firewall /kernel: CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Aug 7 09:43:35 firewall /kernel: Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Aug 7 09:43:35 firewall /kernel: Features=0x80f9ff Aug 7 09:43:35 firewall /kernel: real memory = 134217728 (131072K bytes) Aug 7 09:43:35 firewall /kernel: avail memory = 126742528 (123772K bytes) Aug 7 09:43:35 firewall /kernel: Preloaded elf kernel "kernel" at 0xc037f000. Aug 7 09:43:35 firewall /kernel: Preloaded userconfig_script "/boot/kernel.conf" at 0xc037f09c. Aug 7 09:43:35 firewall /kernel: Pentium Pro MTRR support enabled Aug 7 09:43:35 firewall /kernel: md0: Malloc disk Aug 7 09:43:35 firewall /kernel: npx0: on motherboard Aug 7 09:43:35 firewall /kernel: npx0: INT 16 interface Aug 7 09:43:35 firewall /kernel: pcib0: on motherboard Aug 7 09:43:35 firewall /kernel: pci0: on pcib0 Aug 7 09:43:35 firewall /kernel: pcib1: at device 1.0 on pci0 Aug 7 09:43:35 firewall /kernel: pci1: on pcib1 Aug 7 09:43:35 firewall /kernel: pci1: at 0.0 irq 9 Aug 7 09:43:35 firewall /kernel: isab0: at device 7.0 on pci0 Aug 7 09:43:35 firewall /kernel: isa0: on isab0 Aug 7 09:43:35 firewall /kernel: atapci0: port 0xf000-0xf00f at device 7.1 on pci0 Aug 7 09:43:35 firewall /kernel: ata0: at 0x1f0 irq 14 on atapci0 Aug 7 09:43:35 firewall /kernel: ata1: at 0x170 irq 15 on atapci0 Aug 7 09:43:35 firewall /kernel: uhci0: port 0x6400-0x641f irq 11 at device 7.2 on pci0 Aug 7 09:43:35 firewall /kernel: usb0: on uhci0 Aug 7 09:43:35 firewall /kernel: usb0: USB revision 1.0 Aug 7 09:43:35 firewall /kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Aug 7 09:43:35 firewall /kernel: uhub0: 2 ports with 2 removable, self powered Aug 7 09:43:35 firewall /kernel: chip1: port 0x5f00-0x5f0f at device 7.3 on pci0 Aug 7 09:43:35 firewall /kernel: xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0x6500-0x657f mem 0xe4000000-0xe400007f irq 9 at devi ce 9.0 on pci0 Aug 7 09:43:35 firewall /kernel: xl0: Ethernet address: 00:04:76:6f:71:36 Aug 7 09:43:35 firewall /kernel: miibus0: on xl0 Aug 7 09:43:35 firewall /kernel: xlphy0: <3Com internal media interface> on miibus0 Aug 7 09:43:35 firewall /kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Aug 7 09:43:35 firewall /kernel: xl1: <3Com 3c905B-TX Fast Etherlink XL> port 0x6600-0x667f mem 0xe4001000-0xe400107f irq 12 at dev ice 10.0 on pci0 Aug 7 09:43:35 firewall /kernel: xl1: Ethernet address: 00:04:76:6f:71:4e Aug 7 09:43:35 firewall /kernel: miibus1: on xl1 Aug 7 09:43:35 firewall /kernel: xlphy1: <3Com internal media interface> on miibus1 Aug 7 09:43:35 firewall /kernel: xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Aug 7 09:43:35 firewall /kernel: fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Aug 7 09:43:35 firewall /kernel: fdc0: FIFO enabled, 8 bytes threshold Aug 7 09:43:35 firewall /kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Aug 7 09:43:35 firewall /kernel: atkbdc0: at port 0x60,0x64 on isa0 Aug 7 09:43:35 firewall /kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Aug 7 09:43:35 firewall /kernel: sc0: at flags 0x100 on isa0 Aug 7 09:43:35 firewall /kernel: sc0: VGA <16 virtual consoles, flags=0x300> Aug 7 09:43:35 firewall /kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Aug 7 09:43:35 firewall /kernel: sio0: type 16550A Aug 7 09:43:35 firewall /kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Aug 7 09:43:35 firewall /kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Aug 7 09:43:35 firewall /kernel: ppbus0: IEEE1284 device found /NIBBLE/ECP Aug 7 09:43:35 firewall /kernel: Probing for PnP devices on ppbus0: Aug 7 09:43:35 firewall /kernel: ppbus0: MLC,PCL,PML Aug 7 09:43:35 firewall /kernel: plip0: on ppbus0 Aug 7 09:43:35 firewall /kernel: lpt0: on ppbus0 Aug 7 09:43:35 firewall /kernel: lpt0: Interrupt-driven port Aug 7 09:43:35 firewall /kernel: ppi0: on ppbus0 Aug 7 09:43:35 firewall /kernel: DUMMYNET initialized (010124) Aug 7 09:43:35 firewall /kernel: IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, unlimited logging Aug 7 09:43:35 firewall /kernel: IPsec: Initialized Security Association Processing. Commands I used to get to this point: % ifconfig gif0 create inet 172.16.69.1 172.16.250.1 netmask 255.255.255.0 up % gifconfig gif0 inet 24.181.119.107 x.x.x.x % setkey -c spdadd 172.16.69.0/24 172.16.250.0/24 any -P out ipsec esp/tunnel/24.181.119.107-x.x.x.x/require ; spdadd 172.16.250.0/24 172.16.69.0/24 any -P in ipsec esp/tunnel/x.x.x.x-24.181.119.107/require ; add 24.181.119.107 x.x.x.x esp 2568731067 -m tunnel -E simple "" -A hmac-md5 0x75b916ac534cef32d3db8a44cf5b62c1 ; add x.x.x.x 24.181.119.107 esp 2568731067 -m tunnel -E simple "" -A hmac-md5 0x75b916ac534cef32d3db8a44cf5b62c1 ; ^D If I try to ping or traceroute to 172.16.250.1 from the console of my BSD server, I get no replies. Any advice would be greatly appreciated. -Travis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 18 4:21:36 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 DD00737B407 for ; Sat, 18 Aug 2001 04:21:29 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DBA0B4B20; Sat, 18 Aug 2001 20:21:26 +0900 (JST) To: Wes Peters Cc: hal@vailsys.com (Hal Snyder), freebsd-net@FreeBSD.ORG In-reply-to: wes's message of Fri, 17 Aug 2001 10:33:37 CST. 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: What is 'checksum offload'? From: itojun@iijlab.net Date: Sat, 18 Aug 2001 20:21:26 +0900 Message-ID: <18819.998133686@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 thought it was an IPv6 packet with payload >= 2^16 bytes. >> rfc2675 > >"Jumbo Frames" are (gigabit) ethernet data frames holding up to >9 Kbytes. I am certain "jumbogram" is referring to the same thing. in IPv6, as hal mentioned, jumbogram means patckets with >= 2^16 bytes. usual terminology confusion. in this thread, it should mean GbE jumbo frames - we need to understand the meaning of the word in context dependent manner... itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 18 7: 7:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.okbmei.msk.su (ns.okbmei.msk.su [194.190.170.19]) by hub.freebsd.org (Postfix) with ESMTP id B9F7537B411 for ; Sat, 18 Aug 2001 07:07:47 -0700 (PDT) (envelope-from burba@okbmei.msk.su) Received: from okbmei.msk.su (burba.ac.orbita.ru [193.192.144.124]) by ns.okbmei.msk.su (8.11.4/8.11.4) with ESMTP id f7IE7ea14205 for ; Sat, 18 Aug 2001 18:07:40 +0400 (MSD) Message-ID: <3B7E76A7.DC37991@okbmei.msk.su> Date: Sat, 18 Aug 2001 18:07:35 +0400 From: "Alex S. Burba" X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN tunnel question References: Content-Type: text/plain; charset=koi8-r 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. > If I try to ping or traceroute to 172.16.250.1 from the console of my BSD > server, I get no replies. What does tcpdump show when you try to ping/traceroute? What ping/traceroute keys are you using? -- Bye. Alex S. Burba To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 18 17:14:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from firewall.crimsonwasteland.com (cx154799-b.btnrug1.la.home.com [24.181.119.107]) by hub.freebsd.org (Postfix) with SMTP id 45DDA37B40B for ; Sat, 18 Aug 2001 17:14:49 -0700 (PDT) (envelope-from lists-freebsd-net@crimsonwasteland.com) Received: (qmail 7152 invoked from network); 19 Aug 2001 00:14:23 -0000 Received: from travis.crimsonwasteland.com (HELO travis) (172.16.69.2) by cx154799-b.btnrug1.la.home.com with SMTP; 19 Aug 2001 00:14:23 -0000 From: "Travis Leuthauser" To: "Alex S. Burba" Cc: Subject: RE: IPSec VPN tunnel question Date: Sat, 18 Aug 2001 19:14:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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) Importance: Normal In-Reply-To: <3B7E76A7.DC37991@okbmei.msk.su> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 When I ping from my console, this is what I see pinging 172.16.250.1 % tcpdump -n | grep 24.181.119.107 19:11:53.296829 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x146) 19:11:53.405480 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x144) 19:11:54.306773 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x147) 19:11:54.379835 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x145) 19:11:55.316461 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x148) 19:11:55.394754 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x146) 19:11:56.332052 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x149) 19:11:56.419223 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x147) 19:11:57.336049 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x14a) 19:11:57.425249 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x148) 19:11:58.345854 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x14b) 19:11:58.430157 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x149) 19:11:59.355677 24.181.119.107 > 204.27.124.229: ESP(spi=0x991bb9bb,seq=0x14c) 19:11:59.441615 204.27.124.229 > 24.181.119.107: ESP(spi=0x991bb9bb,seq=0x14a) And that continues on.. What do you mean by "what ping/traceroute keys"? -Travis -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alex S. Burba Sent: Saturday, August 18, 2001 9:08 AM Cc: freebsd-net@freebsd.org Subject: Re: IPSec VPN tunnel question Hi. > If I try to ping or traceroute to 172.16.250.1 from the console of my BSD > server, I get no replies. What does tcpdump show when you try to ping/traceroute? What ping/traceroute keys are you using? -- Bye. Alex S. Burba 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