From owner-freebsd-net@FreeBSD.ORG Sun May 2 03:49:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 996BA16A4CE; Sun, 2 May 2004 03:49:18 -0700 (PDT) Received: from flash.mipk.kharkiv.edu (flash.mipk.kharkiv.edu [194.44.157.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E6643D46; Sun, 2 May 2004 03:49:15 -0700 (PDT) (envelope-from artem@mipk.kharkiv.edu) Received: from mipk.kharkiv.edu (aws.aws-net.org.ua [192.168.32.1]) i42AktT1079370; Sun, 2 May 2004 13:46:57 +0300 (EEST) (envelope-from artem@mipk.kharkiv.edu) Message-ID: <4094D189.7080305@mipk.kharkiv.edu> Date: Sun, 02 May 2004 13:46:33 +0300 From: "Artyom V. Viklenko" Organization: IIAT NTU "KhPI" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: ru, uk, en MIME-Version: 1.0 To: "Mitch (bitblock)" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-isp@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Routing and VPN troubles... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2004 10:49:18 -0000 Mitch (bitblock) wrote: > > The VPN stuff might be easy if I could figure out how to make FBSD1-3 route > through FBSD4 (regardless of the fact that they are all on the same > subnet... the traffic from FBSD1 needs to "bounce" off FBSD4 on it's way to > FBSD3 for example... either that, or maybe the gif interfaces count as > distinct interfaces for routing? May be nos-tun, mpd (PPPoE), or even native netgraph solutin can help. (There is one example for udp tunnel in /usr/share/examples/netgraph). In both cases you will got separate interface for each connection. But, in any case, if all FBSD1-3 boxes can communicate whit each other directly, you have to apply appropriate rules on these boxes to make this impossible. Hope this can help you a bit. -- Sincerely yours, Artyom V. Viklenko. ====================================================== System Administrator artem@mipk.kharkiv.edu ------------------------------------------------------ IIAT NTU "KhPI" 21, Frunze Str., Kharkov Ukraine 61002 Phone: +38 (0572) 400026 Fax: +38 (0572) 474062 ====================================================== From owner-freebsd-net@FreeBSD.ORG Mon May 3 09:45:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28C5B16A4CE for ; Mon, 3 May 2004 09:45:17 -0700 (PDT) Received: from mx04.ca.mci.com (mx04.ca.mci.com [142.77.2.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9253E43D1D for ; Mon, 3 May 2004 09:45:15 -0700 (PDT) (envelope-from kfl@xiphos.ca) Received: from xiphos.ca (unknown [216.95.199.150]) by mx04.ca.mci.com (Postfix) with ESMTP id BA4A4127D3; Mon, 3 May 2004 11:40:11 -0400 (EDT) Message-ID: <40966A47.3040708@xiphos.ca> Date: Mon, 03 May 2004 11:50:31 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Berizzi , freebsd-net@freebsd.org, chris@e-easy.com.au Content-Type: multipart/mixed; boundary="------------070201010804010203070608" Subject: IPComp Tunnel Mode Patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 16:45:17 -0000 This is a multi-part message in MIME format. --------------070201010804010203070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Here is the patch for getting IPComp to work in tunnel mode. This patch is incomplete but It is working enough (for me) to be usefull. Here is some notes I made about it: IPComp works now in tunnel mode with ipv4 only (I wanna fix the m_pulldown issue before IPv6 support). In ipcomp_input.c check before and after m_pulldown, somehting is not right (change #if 0 to #if 1 to convice you) since I get a total len (sums of m_len from the chain) != m_pkthdr.len. The kludge does it for now but should be looked into. Tested with ESP over IPcomp and IPcomp alone in tunnel mode (needs more testing). Did not try with FAST_IPSEC yet. IPv6 Should be more or less the same thing. Hopefully ipcomp_input() is already done :) To Install: stand in /usr/src/sys/netinet6/ and do "patch < /ipcomp.patch" Or use the provided text output. Kernel opt: options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) key file used: ipcomp alone: # # Here, A.B.C.D is our public ip. # W.X.Y.Z is the other host public ip. #spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; #spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd 192.168.16.2/32 192.168.15.2/32 any -P out ipsec ipcomp/tunnel/192.168.16.2-192.168.15.2/use; spdadd 192.168.15.2/32 192.168.16.2/32 any -P in ipsec ipcomp/tunnel/192.168.15.2-192.168.16.2/use; ipcomp and esp: # # Here, A.B.C.D is our public ip. # W.X.Y.Z is the other host public ip. #spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; #spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd 192.168.16.2/24 192.168.15.2/24 any -P out ipsec ipcomp/tunnel/192.168.16.2-192.168.15.2/require esp/tunnel/192.168.16.2-192.168.15.2/require; spdadd 192.168.15.2/24 192.168.16.2/24 any -P in ipsec ipcomp/tunnel/192.168.15.2-192.168.16.2/require esp/tunnel/192.168.15.2-192.168.16.2/require; You can ignore the rest of this email if you use the attachment. Let me know how it goes. Regards, Karim Fodil-Lemelin Network Eng. Xiphos Technologies Inc. The Patch code: diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp.h ./ipcomp.h *** /usr/src/sys/netinet6/ipcomp.h Sun Apr 28 01:40:27 2002 --- ./ipcomp.h Sat May 1 17:33:11 2004 *************** *** 56,61 **** --- 56,63 ---- #define IPCOMP_CPI_NEGOTIATE_MIN 256 #ifdef _KERNEL + #include + struct ipcomp_algorithm { int (*compress) __P((struct mbuf *, struct mbuf *, size_t *)); int (*decompress) __P((struct mbuf *, struct mbuf *, size_t *)); *************** *** 65,71 **** 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 */ #endif /* _NETINET6_IPCOMP_H_ */ --- 67,73 ---- 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 ipsec_output_state *, struct ipsecrequest *)); #endif /* KERNEL */ #endif /* _NETINET6_IPCOMP_H_ */ Only in .: ipcomp.patch diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp6.h ./ipcomp6.h *** /usr/src/sys/netinet6/ipcomp6.h Tue Jul 3 07:01:54 2001 --- ./ipcomp6.h Sat May 1 17:32:36 2004 *************** *** 36,45 **** #ifndef _NETINET6_IPCOMP6_H_ #define _NETINET6_IPCOMP6_H_ - #ifdef _KERNEL extern int ipcomp6_input __P((struct mbuf **, int *, int)); ! extern int ipcomp6_output __P((struct mbuf *, u_char *, struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ --- 36,47 ---- #ifndef _NETINET6_IPCOMP6_H_ #define _NETINET6_IPCOMP6_H_ #ifdef _KERNEL + + #include + extern int ipcomp6_input __P((struct mbuf **, int *, int)); ! extern int ipcomp6_output __P((struct ipsec_output_state *, u_char *, struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp_input.c ./ipcomp_input.c *** /usr/src/sys/netinet6/ipcomp_input.c Sun Apr 28 01:40:27 2002 --- ./ipcomp_input.c Sun May 2 21:00:08 2004 *************** *** 107,112 **** --- 107,113 ---- struct secasvar *sav = NULL; int off, proto; va_list ap; + int s; va_start(ap, m); off = va_arg(ap, int); *************** *** 120,125 **** --- 121,162 ---- goto fail; } + /* kfl: + * If we are dealing with a mbuf chain + * (happens when doing ESP over IPComp over a tunnel) we try to pullup + * all in one mbuf before pulling down. Since each protocol + * pulls up we end up here with a mbuf chain made of multiple + * small mbufs (about 20 to 60 bytes each). Although there is + * nothing wrong with it, m_pulldown return a chain where + * m_pkthdr.len is not equal to the sum of all m_len. By doing this + * pullup and the other hack (valid for 2 mbufs only) we get things + * working. + * + * XXX Its probably a good idea to rewrite this kludge into something + * more general. Turn the #if 0 to #if 1 and see that m_pulldown does + * something funky with the chain. + */ + if (m->m_next) { + m = m_pullup(m, m->m_pkthdr.len); + if (!m) { + ipseclog((LOG_DEBUG, "IPv4 IPComp input: too ambitious " + "(pullup failure)\n")); + goto fail; + } + } + #if 0 + { + struct mbuf *n; + int total_len = 0; + for (n=m; n; n=n->m_next) + total_len += n->m_len; + if (m->m_pkthdr.len != total_len) + /* Should never happen */ + printf("before pulldown, len mismatch! m_pkthdr.len:%d total_len:%d\n", + m->m_pkthdr.len, total_len); + } + #endif + md = m_pulldown(m, off, sizeof(*ipcomp), NULL); if (!m) { m = NULL; /* already freed */ *************** *** 128,133 **** --- 165,192 ---- ipsecstat.in_inval++; goto fail; } + #if 0 + { + struct mbuf *n; + int total_len = 0; + for (n=m; n; n=n->m_next) + total_len += n->m_len; + if (m->m_pkthdr.len != total_len) + /* Should never happen */ + printf("after pulldown, len mismatch! m_pkthdr.len:%d total_len:%d\n", + m->m_pkthdr.len, total_len); + } + #endif + /* + * kfl: I think m_pulldown has some problems with m_len, I should look + * into it but this hack (along with the previous one) does the trick for me now. + * XXX WARNING this assumes there is only two mbufs in the + * chain (which is ok for most packets because of the m_pullup and m_pulldown + * being carefull not to split mbufs easily). + */ + if (m->m_next->m_next == 0 && (m->m_pkthdr.len > m->m_len + md->m_len)) + md->m_len = m->m_pkthdr.len - m->m_len; + ipcomp = mtod(md, struct ipcomp *); ip = mtod(m, struct ip *); nxt = ipcomp->comp_nxt; *************** *** 167,173 **** #else ip->ip_len = htons(ntohs(ip->ip_len) - sizeof(struct ipcomp)); #endif - olen = m->m_pkthdr.len; newlen = m->m_pkthdr.len - off; error = (*algo->decompress)(m, m->m_next, &newlen); --- 226,231 ---- *************** *** 181,186 **** --- 239,249 ---- } ipsecstat.in_comphist[cpi]++; + if (newlen < olen) { + ipseclog((LOG_DEBUG, "IPv4 IPComp input: olen > newlen something may be wrong" + " with the mbuf chain\n")); + goto fail; + } /* * returning decompressed packet onto icmp is meaningless. * mark it decrypted to prevent icmp from attaching original packet. *************** *** 215,240 **** ip->ip_p = nxt; } ! if (sav) { ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! key_freesav(sav); ! sav = NULL; } ! if (nxt != IPPROTO_DONE) { ! if ((inetsw[ip_protox[nxt]].pr_flags & PR_LASTHDR) != 0 && ! ipsec4_in_reject(m, NULL)) { ! ipsecstat.in_polvio++; ! goto fail; ! } ! (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); ! } else ! m_freem(m); ! m = NULL; ipsecstat.in_success++; return; --- 278,356 ---- ip->ip_p = nxt; } ! /* was it transmitted over the IPsec tunnel */ ! if (ipsec4_tunnel_validate(m, off, nxt, sav)) { ! u_int8_t tos; ! ! tos = ip->ip_tos; ! ! m_adj(m, off); ! if (m->m_len < sizeof(*ip)) { ! m = m_pullup(m, sizeof(*ip)); ! if (!m) { ! ipsecstat.in_inval++; ! goto fail; } + } ! ip = mtod(m, struct ip *); ! /* ! * ECN consideration. ! * XXX Should we do this here? ! */ ! ip_ecn_egress(ip4_ipsec_ecn, &tos, &ip->ip_tos); ! if (!key_checktunnelsanity(sav, AF_INET, ! (caddr_t)&ip->ip_src, (caddr_t)&ip->ip_dst)) { ! ipseclog((LOG_ERR, "ipsec tunnel address mismatch " ! "in IPv4 IPComp input: %u %s\n", ! cpi, ipsec_logsastr(sav))); ! ipsecstat.in_inval++; ! goto fail; ! } ! ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0 || ! ipsec_addhist(m, IPPROTO_IPV4, 0) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! s = splimp(); ! if (IF_QFULL(&ipintrq)) { ! ipsecstat.in_inval++; ! splx(s); ! goto fail; ! } ! IF_ENQUEUE(&ipintrq, m); ! m = NULL; ! schednetisr(NETISR_IP); /* can be skipped but to make sure */ ! splx(s); ! nxt = IPPROTO_DONE; ! } else { ! if (sav) { ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! key_freesav(sav); ! sav = NULL; ! } ! ! if (nxt != IPPROTO_DONE) { ! if ((inetsw[ip_protox[nxt]].pr_flags & PR_LASTHDR) != 0 && ! ipsec4_in_reject(m, NULL)) { ! ipsecstat.in_polvio++; ! goto fail; ! } ! printf("nxt :%d\n", nxt); ! (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); ! } else ! m_freem(m); ! m = NULL; ! } ! ! if (sav) ! key_freesav(sav); ipsecstat.in_success++; return; diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp_output.c ./ipcomp_output.c *** /usr/src/sys/netinet6/ipcomp_output.c Sun Apr 28 01:40:27 2002 --- ./ipcomp_output.c Sun May 2 17:40:45 2004 *************** *** 81,87 **** #include ! static int ipcomp_output __P((struct mbuf *, u_char *, struct mbuf *, struct ipsecrequest *, int)); /* --- 81,87 ---- #include ! static int ipcomp_output __P((struct ipsec_output_state *, u_char *, struct mbuf *, struct ipsecrequest *, int)); /* *************** *** 103,118 **** * <-----------------> compoff */ static int ! ipcomp_output(m, nexthdrp, md, isr, af) ! struct mbuf *m; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; int af; { struct mbuf *n; ! struct mbuf *md0; ! struct mbuf *mcopy; struct mbuf *mprev; struct ipcomp *ipcomp; struct secasvar *sav = isr->sav; --- 103,119 ---- * <-----------------> compoff */ static int ! ipcomp_output(state, nexthdrp, md, isr, af) ! struct ipsec_output_state *state; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; int af; { struct mbuf *n; ! struct mbuf *m = state->m; ! struct mbuf *md0 = 0; ! struct mbuf *mcopy = 0; struct mbuf *mprev; struct ipcomp *ipcomp; struct secasvar *sav = isr->sav; *************** *** 171,186 **** * compromise two m_copym(). we will be going through every byte of * the payload during compression process anyways. */ ! mcopy = m_copym(m, 0, M_COPYALL, M_NOWAIT); ! if (mcopy == NULL) { ! error = ENOBUFS; ! return 0; ! } ! md0 = m_copym(md, 0, M_COPYALL, M_NOWAIT); ! if (md0 == NULL) { ! m_freem(mcopy); ! error = ENOBUFS; ! return 0; } plen0 = plen; --- 172,194 ---- * compromise two m_copym(). we will be going through every byte of * the payload during compression process anyways. */ ! /* kfl: ! * In tunnel mode, we already have a copy. ! * XXX We save one m_copym in tunnel mode and I ! * beleive we should be able in transport mode as well. ! */ ! if (isr->saidx.mode == IPSEC_MODE_TRANSPORT) { ! mcopy = m_copym(m, 0, M_COPYALL, M_NOWAIT); ! if (mcopy == NULL) { ! error = ENOBUFS; ! return 0; ! } ! md0 = m_copym(md, 0, M_COPYALL, M_NOWAIT); ! if (md0 == NULL) { ! m_freem(mcopy); ! error = ENOBUFS; ! return 0; ! } } plen0 = plen; *************** *** 296,302 **** m->m_pkthdr.len += complen; ipcomp = mtod(md, struct ipcomp *); } - bzero(ipcomp, sizeof(*ipcomp)); ipcomp->comp_nxt = *nexthdrp; *nexthdrp = IPPROTO_IPCOMP; --- 304,309 ---- *************** *** 304,310 **** switch (af) { #ifdef INET case AF_INET: ! if (compoff + complen + plen < IP_MAXPACKET) ip->ip_len = htons(compoff + complen + plen); else { ipseclog((LOG_ERR, --- 311,317 ---- switch (af) { #ifdef INET case AF_INET: ! if (compoff + complen + plen < IP_MAXPACKET) ip->ip_len = htons(compoff + complen + plen); else { ipseclog((LOG_ERR, *************** *** 333,341 **** stat->out_success++; /* compute byte lifetime against original packet */ ! key_sa_recordxfer(sav, mcopy); ! m_freem(mcopy); ! return 0; fail: --- 340,354 ---- stat->out_success++; /* compute byte lifetime against original packet */ ! if (isr->saidx.mode == IPSEC_MODE_TUNNEL) { ! key_sa_recordxfer(sav, state->mcopy); ! m_freem(state->mcopy); ! state->mcopy = NULL; ! } ! else { ! key_sa_recordxfer(sav, mcopy); ! m_freem(mcopy); ! } return 0; fail: *************** *** 348,357 **** #ifdef INET int ! ipcomp4_output(m, isr) ! struct mbuf *m; struct ipsecrequest *isr; { struct ip *ip; if (m->m_len < sizeof(struct ip)) { ipseclog((LOG_DEBUG, "ipcomp4_output: first mbuf too short\n")); --- 361,371 ---- #ifdef INET int ! ipcomp4_output(state, isr) ! struct ipsec_output_state *state; struct ipsecrequest *isr; { + struct mbuf *m = state->m; struct ip *ip; if (m->m_len < sizeof(struct ip)) { ipseclog((LOG_DEBUG, "ipcomp4_output: first mbuf too short\n")); *************** *** 361,384 **** } ip = mtod(m, struct ip *); /* XXX assumes that m->m_next points to payload */ ! return ipcomp_output(m, &ip->ip_p, m->m_next, isr, AF_INET); } #endif /* INET */ #ifdef INET6 int ! ipcomp6_output(m, nexthdrp, md, isr) ! struct mbuf *m; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; { if (m->m_len < sizeof(struct ip6_hdr)) { ipseclog((LOG_DEBUG, "ipcomp6_output: first mbuf too short\n")); ipsec6stat.out_inval++; m_freem(m); return 0; } ! return ipcomp_output(m, nexthdrp, md, isr, AF_INET6); } #endif /* INET6 */ --- 375,399 ---- } ip = mtod(m, struct ip *); /* XXX assumes that m->m_next points to payload */ ! return ipcomp_output(state, &ip->ip_p, m->m_next, isr, AF_INET); } #endif /* INET */ #ifdef INET6 int ! ipcomp6_output(state, nexthdrp, md, isr) ! struct ipsec_output_state *state; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; { + struct mbuf *m = state->m; if (m->m_len < sizeof(struct ip6_hdr)) { ipseclog((LOG_DEBUG, "ipcomp6_output: first mbuf too short\n")); ipsec6stat.out_inval++; m_freem(m); return 0; } ! return ipcomp_output(state, nexthdrp, md, isr, AF_INET6); } #endif /* INET6 */ diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipsec.c ./ipsec.c *** /usr/src/sys/netinet6/ipsec.c Thu Jan 23 16:06:47 2003 --- ./ipsec.c Sat May 1 17:30:28 2004 *************** *** 2575,2580 **** --- 2575,2590 ---- s = splnet(); if (isr->saidx.mode == IPSEC_MODE_TUNNEL) { + /* + * Make a copy in case we cannot compress the packet in IPComp. + */ + if (isr->saidx.proto == IPPROTO_IPCOMP) { + state->mcopy = m_copym(state->m, 0, M_COPYALL, M_NOWAIT); + if (state->mcopy == NULL) { + error = ENOBUFS; + goto bad; + } + } /* * build IPsec tunnel. */ *************** *** 2657,2665 **** } break; case IPPROTO_IPCOMP: ! if ((error = ipcomp4_output(state->m, isr)) != 0) { state->m = NULL; ! goto bad; } break; default: --- 2667,2681 ---- } break; case IPPROTO_IPCOMP: ! if ((error = ipcomp4_output(state, isr)) != 0) { ! m_freem(state->mcopy); state->m = NULL; ! goto bad; ! } ! /* If we still have a copy, use it. */ ! else if (state->mcopy) { ! m_freem(state->m); ! state->m = state->mcopy; } break; default: *************** *** 2824,2830 **** error = ah6_output(state->m, nexthdrp, mprev->m_next, isr); break; case IPPROTO_IPCOMP: ! error = ipcomp6_output(state->m, nexthdrp, mprev->m_next, isr); break; default: ipseclog((LOG_ERR, "ipsec6_output_trans: " --- 2840,2846 ---- error = ah6_output(state->m, nexthdrp, mprev->m_next, isr); break; case IPPROTO_IPCOMP: ! error = ipcomp6_output(state, nexthdrp, mprev->m_next, isr); break; default: ipseclog((LOG_ERR, "ipsec6_output_trans: " *************** *** 2986,2991 **** --- 3002,3017 ---- /* * build IPsec tunnel. */ + /* + * Make a copy in case we cannot compress the packet in IPComp. + */ + if (isr->saidx.proto == IPPROTO_IPCOMP) { + state->mcopy = m_copym(state->m, 0, M_COPYALL, M_NOWAIT); + if (state->mcopy == NULL) { + error = ENOBUFS; + goto bad; + } + } /* XXX should be processed with other familiy */ if (((struct sockaddr *)&isr->sav->sah->saidx.src)->sa_family != AF_INET6) { ipseclog((LOG_ERR, "ipsec6_output_tunnel: " diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipsec.h ./ipsec.h *** /usr/src/sys/netinet6/ipsec.h Thu Jan 23 16:06:47 2003 --- ./ipsec.h Sat May 1 17:19:12 2004 *************** *** 272,277 **** --- 272,278 ---- #ifdef _KERNEL struct ipsec_output_state { struct mbuf *m; + struct mbuf *mcopy; struct route *ro; struct sockaddr *dst; }; --------------070201010804010203070608 Content-Type: text/plain; name="ipcomp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipcomp.patch" diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp.h ./ipcomp.h *** /usr/src/sys/netinet6/ipcomp.h Sun Apr 28 01:40:27 2002 --- ./ipcomp.h Sat May 1 17:33:11 2004 *************** *** 56,61 **** --- 56,63 ---- #define IPCOMP_CPI_NEGOTIATE_MIN 256 #ifdef _KERNEL + #include + struct ipcomp_algorithm { int (*compress) __P((struct mbuf *, struct mbuf *, size_t *)); int (*decompress) __P((struct mbuf *, struct mbuf *, size_t *)); *************** *** 65,71 **** 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 */ #endif /* _NETINET6_IPCOMP_H_ */ --- 67,73 ---- 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 ipsec_output_state *, struct ipsecrequest *)); #endif /* KERNEL */ #endif /* _NETINET6_IPCOMP_H_ */ Only in .: ipcomp.patch diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp6.h ./ipcomp6.h *** /usr/src/sys/netinet6/ipcomp6.h Tue Jul 3 07:01:54 2001 --- ./ipcomp6.h Sat May 1 17:32:36 2004 *************** *** 36,45 **** #ifndef _NETINET6_IPCOMP6_H_ #define _NETINET6_IPCOMP6_H_ - #ifdef _KERNEL extern int ipcomp6_input __P((struct mbuf **, int *, int)); ! extern int ipcomp6_output __P((struct mbuf *, u_char *, struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ --- 36,47 ---- #ifndef _NETINET6_IPCOMP6_H_ #define _NETINET6_IPCOMP6_H_ #ifdef _KERNEL + + #include + extern int ipcomp6_input __P((struct mbuf **, int *, int)); ! extern int ipcomp6_output __P((struct ipsec_output_state *, u_char *, struct mbuf *, struct ipsecrequest *)); #endif /*KERNEL*/ diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp_input.c ./ipcomp_input.c *** /usr/src/sys/netinet6/ipcomp_input.c Sun Apr 28 01:40:27 2002 --- ./ipcomp_input.c Sun May 2 21:00:08 2004 *************** *** 107,112 **** --- 107,113 ---- struct secasvar *sav = NULL; int off, proto; va_list ap; + int s; va_start(ap, m); off = va_arg(ap, int); *************** *** 120,125 **** --- 121,162 ---- goto fail; } + /* kfl: + * If we are dealing with a mbuf chain + * (happens when doing ESP over IPComp over a tunnel) we try to pullup + * all in one mbuf before pulling down. Since each protocol + * pulls up we end up here with a mbuf chain made of multiple + * small mbufs (about 20 to 60 bytes each). Although there is + * nothing wrong with it, m_pulldown return a chain where + * m_pkthdr.len is not equal to the sum of all m_len. By doing this + * pullup and the other hack (valid for 2 mbufs only) we get things + * working. + * + * XXX Its probably a good idea to rewrite this kludge into something + * more general. Turn the #if 0 to #if 1 and see that m_pulldown does + * something funky with the chain. + */ + if (m->m_next) { + m = m_pullup(m, m->m_pkthdr.len); + if (!m) { + ipseclog((LOG_DEBUG, "IPv4 IPComp input: too ambitious " + "(pullup failure)\n")); + goto fail; + } + } + #if 0 + { + struct mbuf *n; + int total_len = 0; + for (n=m; n; n=n->m_next) + total_len += n->m_len; + if (m->m_pkthdr.len != total_len) + /* Should never happen */ + printf("before pulldown, len mismatch! m_pkthdr.len:%d total_len:%d\n", + m->m_pkthdr.len, total_len); + } + #endif + md = m_pulldown(m, off, sizeof(*ipcomp), NULL); if (!m) { m = NULL; /* already freed */ *************** *** 128,133 **** --- 165,192 ---- ipsecstat.in_inval++; goto fail; } + #if 0 + { + struct mbuf *n; + int total_len = 0; + for (n=m; n; n=n->m_next) + total_len += n->m_len; + if (m->m_pkthdr.len != total_len) + /* Should never happen */ + printf("after pulldown, len mismatch! m_pkthdr.len:%d total_len:%d\n", + m->m_pkthdr.len, total_len); + } + #endif + /* + * kfl: I think m_pulldown has some problems with m_len, I should look + * into it but this hack (along with the previous one) does the trick for me now. + * XXX WARNING this assumes there is only two mbufs in the + * chain (which is ok for most packets because of the m_pullup and m_pulldown + * being carefull not to split mbufs easily). + */ + if (m->m_next->m_next == 0 && (m->m_pkthdr.len > m->m_len + md->m_len)) + md->m_len = m->m_pkthdr.len - m->m_len; + ipcomp = mtod(md, struct ipcomp *); ip = mtod(m, struct ip *); nxt = ipcomp->comp_nxt; *************** *** 167,173 **** #else ip->ip_len = htons(ntohs(ip->ip_len) - sizeof(struct ipcomp)); #endif - olen = m->m_pkthdr.len; newlen = m->m_pkthdr.len - off; error = (*algo->decompress)(m, m->m_next, &newlen); --- 226,231 ---- *************** *** 181,186 **** --- 239,249 ---- } ipsecstat.in_comphist[cpi]++; + if (newlen < olen) { + ipseclog((LOG_DEBUG, "IPv4 IPComp input: olen > newlen something may be wrong" + " with the mbuf chain\n")); + goto fail; + } /* * returning decompressed packet onto icmp is meaningless. * mark it decrypted to prevent icmp from attaching original packet. *************** *** 215,240 **** ip->ip_p = nxt; } ! if (sav) { ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! key_freesav(sav); ! sav = NULL; } ! if (nxt != IPPROTO_DONE) { ! if ((inetsw[ip_protox[nxt]].pr_flags & PR_LASTHDR) != 0 && ! ipsec4_in_reject(m, NULL)) { ! ipsecstat.in_polvio++; ! goto fail; ! } ! (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); ! } else ! m_freem(m); ! m = NULL; ipsecstat.in_success++; return; --- 278,356 ---- ip->ip_p = nxt; } ! /* was it transmitted over the IPsec tunnel */ ! if (ipsec4_tunnel_validate(m, off, nxt, sav)) { ! u_int8_t tos; ! ! tos = ip->ip_tos; ! ! m_adj(m, off); ! if (m->m_len < sizeof(*ip)) { ! m = m_pullup(m, sizeof(*ip)); ! if (!m) { ! ipsecstat.in_inval++; ! goto fail; } + } ! ip = mtod(m, struct ip *); ! /* ! * ECN consideration. ! * XXX Should we do this here? ! */ ! ip_ecn_egress(ip4_ipsec_ecn, &tos, &ip->ip_tos); ! if (!key_checktunnelsanity(sav, AF_INET, ! (caddr_t)&ip->ip_src, (caddr_t)&ip->ip_dst)) { ! ipseclog((LOG_ERR, "ipsec tunnel address mismatch " ! "in IPv4 IPComp input: %u %s\n", ! cpi, ipsec_logsastr(sav))); ! ipsecstat.in_inval++; ! goto fail; ! } ! ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0 || ! ipsec_addhist(m, IPPROTO_IPV4, 0) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! s = splimp(); ! if (IF_QFULL(&ipintrq)) { ! ipsecstat.in_inval++; ! splx(s); ! goto fail; ! } ! IF_ENQUEUE(&ipintrq, m); ! m = NULL; ! schednetisr(NETISR_IP); /* can be skipped but to make sure */ ! splx(s); ! nxt = IPPROTO_DONE; ! } else { ! if (sav) { ! key_sa_recordxfer(sav, m); ! if (ipsec_addhist(m, IPPROTO_IPCOMP, (u_int32_t)cpi) != 0) { ! ipsecstat.in_nomem++; ! goto fail; ! } ! key_freesav(sav); ! sav = NULL; ! } ! ! if (nxt != IPPROTO_DONE) { ! if ((inetsw[ip_protox[nxt]].pr_flags & PR_LASTHDR) != 0 && ! ipsec4_in_reject(m, NULL)) { ! ipsecstat.in_polvio++; ! goto fail; ! } ! printf("nxt :%d\n", nxt); ! (*inetsw[ip_protox[nxt]].pr_input)(m, off, nxt); ! } else ! m_freem(m); ! m = NULL; ! } ! ! if (sav) ! key_freesav(sav); ipsecstat.in_success++; return; diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipcomp_output.c ./ipcomp_output.c *** /usr/src/sys/netinet6/ipcomp_output.c Sun Apr 28 01:40:27 2002 --- ./ipcomp_output.c Sun May 2 17:40:45 2004 *************** *** 81,87 **** #include ! static int ipcomp_output __P((struct mbuf *, u_char *, struct mbuf *, struct ipsecrequest *, int)); /* --- 81,87 ---- #include ! static int ipcomp_output __P((struct ipsec_output_state *, u_char *, struct mbuf *, struct ipsecrequest *, int)); /* *************** *** 103,118 **** * <-----------------> compoff */ static int ! ipcomp_output(m, nexthdrp, md, isr, af) ! struct mbuf *m; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; int af; { struct mbuf *n; ! struct mbuf *md0; ! struct mbuf *mcopy; struct mbuf *mprev; struct ipcomp *ipcomp; struct secasvar *sav = isr->sav; --- 103,119 ---- * <-----------------> compoff */ static int ! ipcomp_output(state, nexthdrp, md, isr, af) ! struct ipsec_output_state *state; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; int af; { struct mbuf *n; ! struct mbuf *m = state->m; ! struct mbuf *md0 = 0; ! struct mbuf *mcopy = 0; struct mbuf *mprev; struct ipcomp *ipcomp; struct secasvar *sav = isr->sav; *************** *** 171,186 **** * compromise two m_copym(). we will be going through every byte of * the payload during compression process anyways. */ ! mcopy = m_copym(m, 0, M_COPYALL, M_NOWAIT); ! if (mcopy == NULL) { ! error = ENOBUFS; ! return 0; ! } ! md0 = m_copym(md, 0, M_COPYALL, M_NOWAIT); ! if (md0 == NULL) { ! m_freem(mcopy); ! error = ENOBUFS; ! return 0; } plen0 = plen; --- 172,194 ---- * compromise two m_copym(). we will be going through every byte of * the payload during compression process anyways. */ ! /* kfl: ! * In tunnel mode, we already have a copy. ! * XXX We save one m_copym in tunnel mode and I ! * beleive we should be able in transport mode as well. ! */ ! if (isr->saidx.mode == IPSEC_MODE_TRANSPORT) { ! mcopy = m_copym(m, 0, M_COPYALL, M_NOWAIT); ! if (mcopy == NULL) { ! error = ENOBUFS; ! return 0; ! } ! md0 = m_copym(md, 0, M_COPYALL, M_NOWAIT); ! if (md0 == NULL) { ! m_freem(mcopy); ! error = ENOBUFS; ! return 0; ! } } plen0 = plen; *************** *** 296,302 **** m->m_pkthdr.len += complen; ipcomp = mtod(md, struct ipcomp *); } - bzero(ipcomp, sizeof(*ipcomp)); ipcomp->comp_nxt = *nexthdrp; *nexthdrp = IPPROTO_IPCOMP; --- 304,309 ---- *************** *** 304,310 **** switch (af) { #ifdef INET case AF_INET: ! if (compoff + complen + plen < IP_MAXPACKET) ip->ip_len = htons(compoff + complen + plen); else { ipseclog((LOG_ERR, --- 311,317 ---- switch (af) { #ifdef INET case AF_INET: ! if (compoff + complen + plen < IP_MAXPACKET) ip->ip_len = htons(compoff + complen + plen); else { ipseclog((LOG_ERR, *************** *** 333,341 **** stat->out_success++; /* compute byte lifetime against original packet */ ! key_sa_recordxfer(sav, mcopy); ! m_freem(mcopy); ! return 0; fail: --- 340,354 ---- stat->out_success++; /* compute byte lifetime against original packet */ ! if (isr->saidx.mode == IPSEC_MODE_TUNNEL) { ! key_sa_recordxfer(sav, state->mcopy); ! m_freem(state->mcopy); ! state->mcopy = NULL; ! } ! else { ! key_sa_recordxfer(sav, mcopy); ! m_freem(mcopy); ! } return 0; fail: *************** *** 348,357 **** #ifdef INET int ! ipcomp4_output(m, isr) ! struct mbuf *m; struct ipsecrequest *isr; { struct ip *ip; if (m->m_len < sizeof(struct ip)) { ipseclog((LOG_DEBUG, "ipcomp4_output: first mbuf too short\n")); --- 361,371 ---- #ifdef INET int ! ipcomp4_output(state, isr) ! struct ipsec_output_state *state; struct ipsecrequest *isr; { + struct mbuf *m = state->m; struct ip *ip; if (m->m_len < sizeof(struct ip)) { ipseclog((LOG_DEBUG, "ipcomp4_output: first mbuf too short\n")); *************** *** 361,384 **** } ip = mtod(m, struct ip *); /* XXX assumes that m->m_next points to payload */ ! return ipcomp_output(m, &ip->ip_p, m->m_next, isr, AF_INET); } #endif /* INET */ #ifdef INET6 int ! ipcomp6_output(m, nexthdrp, md, isr) ! struct mbuf *m; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; { if (m->m_len < sizeof(struct ip6_hdr)) { ipseclog((LOG_DEBUG, "ipcomp6_output: first mbuf too short\n")); ipsec6stat.out_inval++; m_freem(m); return 0; } ! return ipcomp_output(m, nexthdrp, md, isr, AF_INET6); } #endif /* INET6 */ --- 375,399 ---- } ip = mtod(m, struct ip *); /* XXX assumes that m->m_next points to payload */ ! return ipcomp_output(state, &ip->ip_p, m->m_next, isr, AF_INET); } #endif /* INET */ #ifdef INET6 int ! ipcomp6_output(state, nexthdrp, md, isr) ! struct ipsec_output_state *state; u_char *nexthdrp; struct mbuf *md; struct ipsecrequest *isr; { + struct mbuf *m = state->m; if (m->m_len < sizeof(struct ip6_hdr)) { ipseclog((LOG_DEBUG, "ipcomp6_output: first mbuf too short\n")); ipsec6stat.out_inval++; m_freem(m); return 0; } ! return ipcomp_output(state, nexthdrp, md, isr, AF_INET6); } #endif /* INET6 */ diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipsec.c ./ipsec.c *** /usr/src/sys/netinet6/ipsec.c Thu Jan 23 16:06:47 2003 --- ./ipsec.c Sat May 1 17:30:28 2004 *************** *** 2575,2580 **** --- 2575,2590 ---- s = splnet(); if (isr->saidx.mode == IPSEC_MODE_TUNNEL) { + /* + * Make a copy in case we cannot compress the packet in IPComp. + */ + if (isr->saidx.proto == IPPROTO_IPCOMP) { + state->mcopy = m_copym(state->m, 0, M_COPYALL, M_NOWAIT); + if (state->mcopy == NULL) { + error = ENOBUFS; + goto bad; + } + } /* * build IPsec tunnel. */ *************** *** 2657,2665 **** } break; case IPPROTO_IPCOMP: ! if ((error = ipcomp4_output(state->m, isr)) != 0) { state->m = NULL; ! goto bad; } break; default: --- 2667,2681 ---- } break; case IPPROTO_IPCOMP: ! if ((error = ipcomp4_output(state, isr)) != 0) { ! m_freem(state->mcopy); state->m = NULL; ! goto bad; ! } ! /* If we still have a copy, use it. */ ! else if (state->mcopy) { ! m_freem(state->m); ! state->m = state->mcopy; } break; default: *************** *** 2824,2830 **** error = ah6_output(state->m, nexthdrp, mprev->m_next, isr); break; case IPPROTO_IPCOMP: ! error = ipcomp6_output(state->m, nexthdrp, mprev->m_next, isr); break; default: ipseclog((LOG_ERR, "ipsec6_output_trans: " --- 2840,2846 ---- error = ah6_output(state->m, nexthdrp, mprev->m_next, isr); break; case IPPROTO_IPCOMP: ! error = ipcomp6_output(state, nexthdrp, mprev->m_next, isr); break; default: ipseclog((LOG_ERR, "ipsec6_output_trans: " *************** *** 2986,2991 **** --- 3002,3017 ---- /* * build IPsec tunnel. */ + /* + * Make a copy in case we cannot compress the packet in IPComp. + */ + if (isr->saidx.proto == IPPROTO_IPCOMP) { + state->mcopy = m_copym(state->m, 0, M_COPYALL, M_NOWAIT); + if (state->mcopy == NULL) { + error = ENOBUFS; + goto bad; + } + } /* XXX should be processed with other familiy */ if (((struct sockaddr *)&isr->sav->sah->saidx.src)->sa_family != AF_INET6) { ipseclog((LOG_ERR, "ipsec6_output_tunnel: " diff --exclude CVS -C 3 /usr/src/sys/netinet6/ipsec.h ./ipsec.h *** /usr/src/sys/netinet6/ipsec.h Thu Jan 23 16:06:47 2003 --- ./ipsec.h Sat May 1 17:19:12 2004 *************** *** 272,277 **** --- 272,278 ---- #ifdef _KERNEL struct ipsec_output_state { struct mbuf *m; + struct mbuf *mcopy; struct route *ro; struct sockaddr *dst; }; --------------070201010804010203070608-- From owner-freebsd-net@FreeBSD.ORG Mon May 3 10:00:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8C5116A4CF for ; Mon, 3 May 2004 10:00:14 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 876A043D1F for ; Mon, 3 May 2004 10:00:14 -0700 (PDT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i43GxmWR084143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 3 May 2004 09:59:48 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Mon, 3 May 2004 09:59:14 -0700 User-Agent: KMail/1.6.1 References: <40966A47.3040708@xiphos.ca> In-Reply-To: <40966A47.3040708@xiphos.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405030959.14622.sam@errno.com> cc: Marco Berizzi cc: chris@e-easy.com.au Subject: Re: IPComp Tunnel Mode Patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 17:00:14 -0000 On Monday 03 May 2004 08:50 am, Karim Fodil-Lemelin wrote: > Hi, > > Here is the patch for getting IPComp to work in tunnel mode. This > patch is incomplete but It is working enough (for me) to be usefull. > Here is some notes I made about it: > > IPComp works now in tunnel mode with ipv4 only (I wanna fix the m_pulldown > issue before IPv6 support). > > In ipcomp_input.c check before and after m_pulldown, somehting is not right > (change #if 0 to #if 1 to convice you) since I get a total len (sums of > m_len from the chain) != m_pkthdr.len. The kludge does it for now but > should be looked into. > > Tested with ESP over IPcomp and IPcomp alone in tunnel mode (needs more > testing). > > Did not try with FAST_IPSEC yet. FAST_IPSEC uses the crypto subsystem for ipcomp and that code has an issue with the kernel zlib code. It's been a long time since I looked at the issue but beware that any problems you hit are likely to be over in the crypto stuff and not the protocol support. If anyone is interested in working on this it'd also be good to bring over the openbsd hifn changes to support h/w ipcomp. Sam From owner-freebsd-net@FreeBSD.ORG Mon May 3 11:02:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8F6116A4E1 for ; Mon, 3 May 2004 11:02:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1E143D1D for ; Mon, 3 May 2004 11:02:00 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i43I201U028510 for ; Mon, 3 May 2004 11:02:00 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i43I20no028502 for freebsd-net@freebsd.org; Mon, 3 May 2004 11:02:00 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 May 2004 11:02:00 -0700 (PDT) Message-Id: <200405031802.i43I20no028502@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 18:02:01 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Tue May 4 04:45:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E3A16A4CE for ; Tue, 4 May 2004 04:45:03 -0700 (PDT) Received: from un.celar.fr (ssig.celar.fr [192.134.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75C4F43D5F for ; Tue, 4 May 2004 04:45:02 -0700 (PDT) (envelope-from bouvard@celar.fr) Received: from cinquantesix.celar.fr (cinquantesix.celar.fr [192.134.105.121]) by un.celar.fr (SMTP) with ESMTP id 1C9981B82AC for ; Tue, 4 May 2004 13:43:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by cinquantesix.celar.fr (Postfix) with ESMTP id 4470E105723 for ; Tue, 4 May 2004 13:43:29 +0200 (CEST) Received: from cinquantesix.celar.fr ([127.0.0.1]) by localhost (cinquantesix.celar.fr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14199-01 for ; Tue, 4 May 2004 13:43:27 +0200 (CEST) Received: from celar.fr (localhost.localdomain [127.0.0.1]) by cinquantesix.celar.fr (Postfix) with ESMTP id 8D583105722 for ; Tue, 4 May 2004 07:43:27 -0400 (EDT) Message-ID: <409781DF.6020603@celar.fr> Date: Tue, 04 May 2004 13:43:27 +0200 From: BOUVARD Bruno User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.4) Gecko/20030624 X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at cinquantesix.celar.fr Subject: MIPv6 implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 11:45:03 -0000 Hello, I try to find documents, "howto" on how to implement and configure Mobile IPv6 with Free BSD version 4.9. But I'm unsuccessfull !! May you help me. Regards Bruno Bouvard From owner-freebsd-net@FreeBSD.ORG Tue May 4 05:22:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 570B016A4CF; Tue, 4 May 2004 05:22:48 -0700 (PDT) Received: from shadow.wixb.com (shadow.wixb.com [65.43.82.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CDDB43D1D; Tue, 4 May 2004 05:22:47 -0700 (PDT) (envelope-from jbronson@wixb.com) Received: from dakota.wixb.com (shadow.wixb.com [10.43.82.173]) i44CMkdX000932; Tue, 4 May 2004 07:22:46 -0500 (CDT) Message-Id: <6.1.0.6.2.20040504071343.024331b8@localhost> Date: Tue, 04 May 2004 07:23:09 -0500 To: freebsd-net@freebsd.org From: "J.D. Bronson" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.42 cc: freebsd-questions@freebsd.org Subject: arp issues...but WHY X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 12:22:48 -0000 I have a FreeBSD 5.2.1 machine that has dual NICs. I would expect the following behavior if I placed both NICs on the same subnet (192.168.1.1 and 192.168.1.2 for example)... But in this case they are totally unique: NIC #1 - 10.10.10.1 255.255.255.0 NIC #2 - 192.168.10.1 255.255.255.0 Default gateway: 10.10.10.10 I am using a single SWITCH for all of my connections. most of my LAN is on the '10' block, but I have a few machines and 1 router that are on the '192' block. When I telnet into the freebsd machine from the '10.10.10.5' to the '10' block I see ARP comments on the console that I dont understand: arp: 10.10.10.5 is on fxp0 but got reply from 00:10:7b:80:04:40 on fxp1 How is this possible? - the laptop has NO IP on the 192 block at all. I understand how to shut up these errors using 'sysctl' - but I wanted to know why I am seeing them in the first place? -JDB From owner-freebsd-net@FreeBSD.ORG Tue May 4 05:28:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A7A516A4CE for ; Tue, 4 May 2004 05:28:47 -0700 (PDT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE5A43D48 for ; Tue, 4 May 2004 05:28:46 -0700 (PDT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-3-145.w81-53.abo.wanadoo.fr [81.53.50.145]) by www.citello.it (Postfix) with ESMTP id 780CFFEB for ; Tue, 4 May 2004 14:28:43 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id 528904150; Tue, 4 May 2004 14:22:37 +0200 (CEST) Date: Tue, 4 May 2004 14:22:36 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Message-Id: <20040504142236.2674f7a0@localhost> In-Reply-To: <409781DF.6020603@celar.fr> References: <409781DF.6020603@celar.fr> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: MIPv6 implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 12:28:47 -0000 On Tue, 04 May 2004 BOUVARD Bruno wrote: > I try to find documents, "howto" on how to implement and configure > Mobile IPv6 with Free BSD version 4.9. See http://www.kame.net/ and http://www.kame.net/newsletter/ they have also a mailing list. marco From owner-freebsd-net@FreeBSD.ORG Tue May 4 05:42:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02F6A16A4CE for ; Tue, 4 May 2004 05:42:25 -0700 (PDT) Received: from tx3.oucs.ox.ac.uk (tx3.oucs.ox.ac.uk [163.1.2.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6676F43D5A for ; Tue, 4 May 2004 05:42:24 -0700 (PDT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan3.oucs.ox.ac.uk ([163.1.2.166] helo=localhost) by tx3.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1BKzFf-00044J-Nu for freebsd-net@freebsd.org; Tue, 04 May 2004 13:42:23 +0100 Received: from rx3.oucs.ox.ac.uk ([163.1.2.165]) by localhost (scan3.oucs.ox.ac.uk [163.1.2.166]) (amavisd-new, port 25) with ESMTP id 15463-08 for ; Tue, 4 May 2004 13:42:23 +0100 (BST) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx3.oucs.ox.ac.uk with smtp (Exim 4.24) id 1BKzFf-00044B-AT for freebsd-net@freebsd.org; Tue, 04 May 2004 13:42:23 +0100 Received: (qmail 6942 invoked by uid 1004); 4 May 2004 12:42:23 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.20 (clamscan: 0.67. sweep: 2.18/3.79. Clear:RC:1(163.1.161.131):. Processed in 0.071809 secs); 04 May 2004 12:42:23 -0000 Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 4 May 2004 12:42:23 -0000 Message-Id: <6.1.0.6.1.20040504133711.03d1ce18@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 04 May 2004 13:42:20 +0100 To: freebsd-net@freebsd.org From: Colin Percival Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [patch] Verify that ifaddr_byindex(foo) != NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 12:42:25 -0000 Could someone confirm for me that this looks sensible? I don't know anything about this code, but if we're going to check that 0 < ifp->if_index <= if_index, it seems that we should also be checking that ifp->if_index corresponds to an interface which still exists (rather than a gap left behind when an interface was removed). Colin Percival Index: src/sys/netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.270 diff -u -p -r1.270 ip_input.c --- src/sys/netinet/ip_input.c 2 May 2004 15:10:16 -0000 1.270 +++ src/sys/netinet/ip_input.c 4 May 2004 12:37:02 -0000 @@ -2053,7 +2053,8 @@ ip_savecontrol(inp, mp, ip, m) struct sockaddr_dl *sdl2 = &sdlbuf.sdl; if (((ifp = m->m_pkthdr.rcvif)) - && ( ifp->if_index && (ifp->if_index <= if_index))) { + && ( ifp->if_index && (ifp->if_index <= if_index)) && + (ifaddr_byindex(ifp->if_index) != NULL)) { sdp = (struct sockaddr_dl *) (ifaddr_byindex(ifp->if_index)->ifa_addr); /* From owner-freebsd-net@FreeBSD.ORG Tue May 4 06:35:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B415216A4CF for ; Tue, 4 May 2004 06:35:01 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71CE543D5A for ; Tue, 4 May 2004 06:35:01 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i44DZ1gd038609; Tue, 4 May 2004 06:35:01 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i44DZ1Rp038608; Tue, 4 May 2004 06:35:01 -0700 (PDT) (envelope-from rizzo) Date: Tue, 4 May 2004 06:35:00 -0700 From: Luigi Rizzo To: Colin Percival Message-ID: <20040504063500.A37862@xorpc.icir.org> References: <6.1.0.6.1.20040504133711.03d1ce18@popserver.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.1.0.6.1.20040504133711.03d1ce18@popserver.sfu.ca>; from colin.percival@wadham.ox.ac.uk on Tue, May 04, 2004 at 01:42:20PM +0100 cc: freebsd-net@freebsd.org Subject: Re: [patch] Verify that ifaddr_byindex(foo) != NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 13:35:01 -0000 On Tue, May 04, 2004 at 01:42:20PM +0100, Colin Percival wrote: > Could someone confirm for me that this looks sensible? I don't > know anything about this code, but if we're going to check that > 0 < ifp->if_index <= if_index, it seems that we should also be > checking that ifp->if_index corresponds to an interface which > still exists (rather than a gap left behind when an interface was > removed). well, the problem here and elsewhere is whether we trust the rcvif field or not -- if we do, we must assume that if_index and ifadd_byindex() are all valid, because they are all set consistently in if_attach(). If the interface is gone, ifp is already bogus thus there is no point to check. So i'd vote to remove all the bogus checks here and elsewhere, rather than add newer ones. cheers luigi > Colin Percival > > Index: src/sys/netinet/ip_input.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v > retrieving revision 1.270 > diff -u -p -r1.270 ip_input.c > --- src/sys/netinet/ip_input.c 2 May 2004 15:10:16 -0000 1.270 > +++ src/sys/netinet/ip_input.c 4 May 2004 12:37:02 -0000 > @@ -2053,7 +2053,8 @@ ip_savecontrol(inp, mp, ip, m) > struct sockaddr_dl *sdl2 = &sdlbuf.sdl; > > if (((ifp = m->m_pkthdr.rcvif)) > - && ( ifp->if_index && (ifp->if_index <= if_index))) { > + && ( ifp->if_index && (ifp->if_index <= if_index)) && > + (ifaddr_byindex(ifp->if_index) != NULL)) { > sdp = (struct sockaddr_dl *) > (ifaddr_byindex(ifp->if_index)->ifa_addr); > /* > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 4 08:11:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C96E16A4CF for ; Tue, 4 May 2004 08:11:07 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7CAC43D49 for ; Tue, 4 May 2004 08:11:06 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (24-161-166-146.san.rr.com [24.161.166.146]) by smtp-relay.omnis.com (Postfix) with ESMTP id 24DF41407814; Tue, 4 May 2004 08:11:05 -0700 (PDT) From: Wes Peters Organization: Softweyr.COM To: freebsd-net@freebsd.org Date: Tue, 4 May 2004 08:11:05 -0700 User-Agent: KMail/1.6.1 References: <00c301c42dff$1fc2ff80$3200a8c0@cbcoffice> In-Reply-To: <00c301c42dff$1fc2ff80$3200a8c0@cbcoffice> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405040811.05248.wes@softweyr.com> cc: The Jetman Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 15:11:07 -0000 On Thursday 29 April 2004 08:18, The Jetman wrote: > ----- Original Message ----- > From: "Julian Elischer" > To: "Bruce M Simpson" > Cc: "FreeBSD Net" ; "The Jetman" > Sent: Wednesday, April 28, 2004 17:20 PM > Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? > > > On Wed, 28 Apr 2004, Bruce M Simpson wrote: > > > On Wed, Apr 28, 2004 at 03:29:58PM -0400, The Jetman wrote: > > > > I'm just confused as to why I lose SO much going thru my FBSD > > > > box and that's essence of my question. I can live w/ *some* > > > > overhead for the sake of using FBSD, but this is ridiculous. > > > > TIA....Jet > > > > > > Are you using user space NAT? If so, this might account for some of > > > the poor performance. Try reconfiguring your system to use IPFILTER, > > > or consider updating to 5-CURRENT and trying pf(4). > > > > I would be surprised if that were the problem.. I've saturated > > ethernets using natd.. > > > > Howver I agree that more info on the setup being used would be > > beneficial.. > > Julian: There isn't much that I can *think* to add. If knowing > which LAN cards I use will help, they're the usu stuf, a dc (forget which > chip) and a Realtek. I admit these aren't superstars, but I just slapped > NAT box together from what was a simple workstation. The IPFW firewall > script is the unmodified 'open' config, that is: None of that would have any bearing at all, unless you've horribly mis-configured something. Did you have to install any special drivers on XP? I'm wondering if they're using some sort of link compression to get the promised speed. Also, try downloading something from one of the well-connected FreeBSD mirrors and see what kind of download speeds you get. I may be the browser you're using or something equally stupid in the test you're using. After all, what really matters is the REAL performance you get, not some number off of a web page, right? -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Tue May 4 11:16:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0DF516A4CE for ; Tue, 4 May 2004 11:16:22 -0700 (PDT) Received: from 153-bem-1.acn.waw.pl (153-bem-1.acn.waw.pl [62.121.80.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 96E4343D31 for ; Tue, 4 May 2004 11:16:21 -0700 (PDT) (envelope-from lukasz.stelmach@k.telmark.waw.pl) Received: (qmail 9797 invoked by uid 1000); 4 May 2004 18:16:20 -0000 Date: Tue, 4 May 2004 20:16:20 +0200 From: Lukasz Stelmach To: freebsd-net@freebsd.org Message-ID: <20040504181620.GB9699@tygrys.k.telmark.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mail-Editor: nvi X-GPG-Fingerprint: 68B8 6D4F 0C5E 291F C4E0 BBF4 35DC D8F2 C9BD 2BDC X-GPG-Key: http://www.ee.pw.edu.pl/~stelmacl/gpg_key.txt Subject: if_stf bug/feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 18:16:22 -0000 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings. stf interface has one feature, very inconvinient for me. As far as i could read the source it returns ENETDOWN if the inet4 address of the machine's net interface (primary or the one would be used) does not match proper part of stf's address. This is ok if one has public, routable ip4 address. Since my machine is behind a firewall that forwards and nats all proto 41 ip packets I'd rather stf didn't complain about it. Now what would you suggest? I may comment out the "if" in if_stf.c:348. However this check should be done in general but there also should be some at-runtime method to overide it (maybe sysctl net.inet6.ip6.strictstfaddr?). The line number applies to 4.10-PRERELEASE (ctm src-4 1844). Best regards, PS. I've sent it to freebsd-stable but havn't got any response. --=20 |/ |_, _ .- --, Ju=BF z ka=BFdej strony pe=B3zn=B1, potworne =BF= =B1dze |__ |_|. | \ |_|. ._' /_. B=EAd=EA uprawia=B3 nierz=B1d, za pieni= =B1ze --V0207lvV8h4k8FAm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAl93zNdzY8sm9K9wRAntLAJ9qK/lth7xiuji1E82c/c3DKtBjlwCfQ6a8 ZO1LC0gT3PsjieUsIOvhELs= =k2z3 -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- From owner-freebsd-net@FreeBSD.ORG Tue May 4 11:33:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AD6916A4CF for ; Tue, 4 May 2004 11:33:02 -0700 (PDT) Received: from host130.ipowerweb.com (host130.ipowerweb.com [66.235.192.160]) by mx1.FreeBSD.org (Postfix) with SMTP id B1C2A43D4C for ; Tue, 4 May 2004 11:33:01 -0700 (PDT) (envelope-from jetman@mycbc.com) Received: (qmail 2055 invoked from network); 4 May 2004 18:36:16 -0000 Received: from unknown (HELO eagle) (162.83.214.10) by 0 with SMTP; 4 May 2004 18:36:16 -0000 Message-ID: <006f01c43206$eb5f4b20$3200a8c0@cbcoffice> From: "The Jetman" To: "FreeBSD Net" References: <00c301c42dff$1fc2ff80$3200a8c0@cbcoffice> <200405040811.05248.wes@softweyr.com> Date: Tue, 4 May 2004 14:22:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 18:33:02 -0000 ----- Original Message ----- From: "Wes Peters" To: Cc: "The Jetman" Sent: Tuesday, May 4, 2004 11:11 AM Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? > > Julian: There isn't much that I can *think* to add. If knowing > > which LAN cards I use will help, they're the usu stuf, a dc (forget which > > chip) and a Realtek. I admit these aren't superstars, but I just slapped > > NAT box together from what was a simple workstation. The IPFW firewall > > script is the unmodified 'open' config, that is: > > None of that would have any bearing at all, unless you've horribly > mis-configured something. Did you have to install any special drivers on > XP? I'm wondering if they're using some sort of link compression to get > the promised speed. Also, try downloading something from one of the > well-connected FreeBSD mirrors and see what kind of download speeds you > get. I may be the browser you're using or something equally stupid in the > test you're using. After all, what really matters is the REAL performance > you get, not some number off of a web page, right? > > -- > > Where am I, and what am I doing in this handbasket? > > Wes Peters wes@softweyr.com > Wes: I've used a couple of Internet speed tests, at different times, but always w/ the same configs. Neither config has been modified. All of the results are the same. I use ADSLGuide and DLSReports as my speed tests, which are in different continents, but both report the same speeds. I use different browsers, but Java is what does the deal. I am still clueless....Jet =============== From the desk of Jethro Wright, III ================ + If it's there, and you can see it, it's real. + + If it's not there, and you can see it, it's virtual. + + If it's there, and you can't see it, it's transparent. + + If it's not there, and you can't see it, you erased it. + === jetman516 'at' hotmail.com ========================== Anon === From owner-freebsd-net@FreeBSD.ORG Tue May 4 11:49:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B29416A4CF for ; Tue, 4 May 2004 11:49:24 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F5143D46 for ; Tue, 4 May 2004 11:49:23 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out001.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040504184922.GRPS1464.out001.verizon.net@mac.com>; Tue, 4 May 2004 13:49:22 -0500 Message-ID: <4097E60D.7090102@mac.com> Date: Tue, 04 May 2004 14:50:53 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: The Jetman References: <00c301c42dff$1fc2ff80$3200a8c0@cbcoffice> <200405040811.05248.wes@softweyr.com> <006f01c43206$eb5f4b20$3200a8c0@cbcoffice> In-Reply-To: <006f01c43206$eb5f4b20$3200a8c0@cbcoffice> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [68.160.247.127] at Tue, 4 May 2004 13:49:22 -0500 cc: FreeBSD Net Subject: Re: [4.9-R]Can I Make My DSL Connect Go Faster ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 18:49:24 -0000 The Jetman wrote: [ ... ] > Wes: I've used a couple of Internet speed tests, at different times, but > always w/ the same configs. Neither config has been modified. All of the > results are the same. I use ADSLGuide and DLSReports as my speed tests, > which are in different continents, but both report the same speeds. I use > different browsers, but Java is what does the deal. If you're using a DSL provider like Verizon which uses PPPoE, you might try adjusting your MTU down to 1490 or so, or else you will fragment large data packets and encounter quite a slowdown. Use something like this in your /etc/rc.conf file: ifconfig_fxp0="inet 192.168.1.2 netmask 255.255.255.0 mtu 1490" ...or run ifconfig directly and see whether this helps. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue May 4 13:01:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D081516A4CE for ; Tue, 4 May 2004 13:01:59 -0700 (PDT) Received: from hoster904.com (hoster904.com [66.211.137.19]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C66C43D5A for ; Tue, 4 May 2004 13:01:59 -0700 (PDT) (envelope-from tie@ankh.morp.org) Received: (qmail 1549 invoked from network); 4 May 2004 17:15:52 -0000 Received: from unknown (HELO ankh.morp.org) (213.240.240.40) by hoster904.com with SMTP; 4 May 2004 17:15:52 -0000 Message-ID: <4097CFA2.6090709@ankh.morp.org> Date: Tue, 04 May 2004 20:15:14 +0300 From: Emil Filipov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: mpd 3.17 + latest freebsd 5 current = build problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 20:01:59 -0000 I have just cvsup-ed my system (buildworld, buildkernel). I decided to also update my mpd installation from 3.15 to 3.17. However, I was rather unpleasently surpirsed when the newly downloaded mpd port refused to compile: ---------------------------------------------------------- radius.c:29: error: conflicting types for `rad_demangle' /usr/include/radlib.h:216: error: previous declaration of `rad_demangle' radius.c:30: error: conflicting types for `rad_demangle_mppe_key' /usr/include/radlib_vs.h:81: error: previous declaration of `rad_demangle_mppe_key' radius.c: In function `RadiusPAPAuthenticate': radius.c:705: warning: passing arg 5 of `RadiusPutAuth' makes integer from pointer without a cast radius.c: In function `RadiusAccount': radius.c:1158: warning: long int format, int arg (arg 4) radius.c:1164: warning: long int format, int arg (arg 4) *** Error code 1 Stop in /usr/ports/net/mpd/work/mpd-3.17/src. *** Error code 1 Stop in /usr/ports/net/mpd/work/mpd-3.17. *** Error code 1 Stop in /usr/ports/net/mpd. ------------------------------------------- Swearing didn't help, so I started the old 'vi' editor and plunged in the source code of radius.c . As the error messages imply, there were duplicate/conflicting declaration of the functions 'rad_demangle' and ' rad_demangle_mppe_key' . After replacing these with 'rad_demangle1' and 'rad_demangle_mppe_key1' all over the radius.c file, there were no further problems. Regards, Emil Filipov From owner-freebsd-net@FreeBSD.ORG Tue May 4 13:02:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D0716A4CF for ; Tue, 4 May 2004 13:02:22 -0700 (PDT) Received: from hoster904.com (hoster904.com [66.211.137.19]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C3DB43D46 for ; Tue, 4 May 2004 13:02:22 -0700 (PDT) (envelope-from tie@ankh.morp.org) Received: (qmail 29977 invoked from network); 4 May 2004 20:02:56 -0000 Received: from unknown (HELO ankh.morp.org) (213.240.240.40) by hoster904.com with SMTP; 4 May 2004 20:02:56 -0000 Message-ID: <4097F6CA.1010001@ankh.morp.org> Date: Tue, 04 May 2004 23:02:18 +0300 From: Emil Filipov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: mpd 3.17 + latest freebsd 5 current = build problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 20:02:22 -0000 Hi list, I have just cvsup-ed my system (buildworld, buildkernel). I decided to also update my mpd installation from 3.15 to 3.17. However, I was rather unpleasantly surprised when the newly downloaded mpd port refused to compile: ---------------------------------------------------------- radius.c:29: error: conflicting types for `rad_demangle' /usr/include/radlib.h:216: error: previous declaration of `rad_demangle' radius.c:30: error: conflicting types for `rad_demangle_mppe_key' /usr/include/radlib_vs.h:81: error: previous declaration of `rad_demangle_mppe_key' radius.c: In function `RadiusPAPAuthenticate': radius.c:705: warning: passing arg 5 of `RadiusPutAuth' makes integer from pointer without a cast radius.c: In function `RadiusAccount': radius.c:1158: warning: long int format, int arg (arg 4) radius.c:1164: warning: long int format, int arg (arg 4) *** Error code 1 Stop in /usr/ports/net/mpd/work/mpd-3.17/src. *** Error code 1 Stop in /usr/ports/net/mpd/work/mpd-3.17. *** Error code 1 Stop in /usr/ports/net/mpd. ------------------------------------------- Swearing didn't help, so I started the old 'vi' editor and plunged in the source code of radius.c . As the error messages imply, there were duplicate/conflicting declaration of the functions 'rad_demangle' and ' rad_demangle_mppe_key' . After replacing these with 'rad_demangle1' and 'rad_demangle_mppe_key1' all over the radius.c file, there were no further problems. Regards, Emil Filipov From owner-freebsd-net@FreeBSD.ORG Tue May 4 13:08:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A318F16A4CE for ; Tue, 4 May 2004 13:08:34 -0700 (PDT) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ACDC43D1F for ; Tue, 4 May 2004 13:08:34 -0700 (PDT) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by mail.a-quadrat.at (Postfix) with ESMTP id 689AE5D21D; Tue, 4 May 2004 22:08:32 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42815-03; Tue, 4 May 2004 22:08:31 +0200 (CEST) Received: from a-quadrat.at (files.a-quadrat.at [192.168.90.9]) by mail.a-quadrat.at (Postfix) with ESMTP id 0FF2E5C1BA; Tue, 4 May 2004 22:08:31 +0200 (CEST) Message-ID: <4097F83B.1070206@a-quadrat.at> Date: Tue, 04 May 2004 22:08:27 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6) Gecko/20040113 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: Emil Filipov References: <4097F6CA.1010001@ankh.morp.org> In-Reply-To: <4097F6CA.1010001@ankh.morp.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at a-quadrat.at cc: freebsd-net@freebsd.org Subject: Re: mpd 3.17 + latest freebsd 5 current = build problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 20:08:34 -0000 Hi, Emil Filipov schrieb: > Hi list, > > I have just cvsup-ed my system (buildworld, buildkernel). > > I decided to also update my mpd installation from 3.15 to 3.17. However, > I was rather unpleasantly surprised when the newly downloaded mpd port > please cvsup your ports and install Mpd-3.18 thanx, bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Tue May 4 23:02:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A98716A4CE for ; Tue, 4 May 2004 23:02:42 -0700 (PDT) Received: from tx1.oucs.ox.ac.uk (tx1.oucs.ox.ac.uk [129.67.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0444843D3F for ; Tue, 4 May 2004 23:02:40 -0700 (PDT) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan1.oucs.ox.ac.uk ([129.67.1.166] helo=localhost) by tx1.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1BLFUM-0004Gh-JI for freebsd-net@freebsd.org; Wed, 05 May 2004 07:02:39 +0100 Received: from rx1.oucs.ox.ac.uk ([129.67.1.165]) by localhost (scan1.oucs.ox.ac.uk [129.67.1.166]) (amavisd-new, port 25) with ESMTP id 15791-10 for ; Wed, 5 May 2004 07:02:38 +0100 (BST) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx1.oucs.ox.ac.uk with smtp (Exim 4.24) id 1BLFUM-0004Ge-5s for freebsd-net@freebsd.org; Wed, 05 May 2004 07:02:38 +0100 Received: (qmail 4549 invoked by uid 1004); 5 May 2004 06:02:38 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.20 (clamscan: 0.67. sweep: 2.18/3.79. Clear:RC:1(163.1.161.131):. Processed in 0.442141 secs); 05 May 2004 06:02:38 -0000 Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 5 May 2004 06:02:38 -0000 Message-Id: <6.1.0.6.1.20040505065826.03e1d510@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 05 May 2004 07:02:33 +0100 To: Luigi Rizzo From: Colin Percival In-Reply-To: <20040504063500.A37862@xorpc.icir.org> References: <6.1.0.6.1.20040504133711.03d1ce18@popserver.sfu.ca> <20040504063500.A37862@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org cc: Colin Percival Subject: Re: [patch] Verify that ifaddr_byindex(foo) != NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 06:02:42 -0000 At 14:35 04/05/2004, Luigi Rizzo wrote: >On Tue, May 04, 2004 at 01:42:20PM +0100, Colin Percival wrote: >> if we're going to check that >> 0 < ifp->if_index <= if_index, it seems that we should also be >> checking that ifp->if_index corresponds to an interface which >> still exists (rather than a gap left behind when an interface was >> removed). > >well, the problem here and elsewhere is whether we trust the rcvif >field or not Right; I wasn't sure if we did trust it. In particular, I wonder about packets received immediately before an interface is removed. >So i'd vote to remove all the bogus checks here and elsewhere, rather >than add newer ones. If the check is unnecessary, by all means remove it; but the current situation, where a check is half-performed, is certainly not correct. :-) Colin Percival From owner-freebsd-net@FreeBSD.ORG Tue May 4 23:36:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE68A16A4CE for ; Tue, 4 May 2004 23:36:51 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9AB243D31 for ; Tue, 4 May 2004 23:36:51 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i456aogd004817; Tue, 4 May 2004 23:36:50 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i456aoXU004816; Tue, 4 May 2004 23:36:50 -0700 (PDT) (envelope-from rizzo) Date: Tue, 4 May 2004 23:36:50 -0700 From: Luigi Rizzo To: Colin Percival Message-ID: <20040504233650.B2575@xorpc.icir.org> References: <6.1.0.6.1.20040504133711.03d1ce18@popserver.sfu.ca> <20040504063500.A37862@xorpc.icir.org> <6.1.0.6.1.20040505065826.03e1d510@popserver.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.1.0.6.1.20040505065826.03e1d510@popserver.sfu.ca>; from colin.percival@wadham.ox.ac.uk on Wed, May 05, 2004 at 07:02:33AM +0100 cc: freebsd-net@freebsd.org Subject: Re: [patch] Verify that ifaddr_byindex(foo) != NULL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 06:36:52 -0000 On Wed, May 05, 2004 at 07:02:33AM +0100, Colin Percival wrote: ... > >On Tue, May 04, 2004 at 01:42:20PM +0100, Colin Percival wrote: > >> if we're going to check that > >> 0 < ifp->if_index <= if_index, it seems that we should also be > >> checking that ifp->if_index corresponds to an interface which > >> still exists (rather than a gap left behind when an interface was > >> removed). > > > >well, the problem here and elsewhere is whether we trust the rcvif > >field or not > > Right; I wasn't sure if we did trust it. In particular, I wonder > about packets received immediately before an interface is removed. if the interface teardown code does not go through queued packets to invalidate the stale rcvif pointer (and it doesn't right now) we are certainly in trouble and no check is going to save us. If people are going to scrutinize the code, I suggest the following course of actions: + in if_attach() add a comment indicating that once the function is complete, if_index and ifaddr_byindex() are valid; + in the various if_output routines, when the rcvif field is not to be used anymore, set it to NULL to reduce the chance of trouble; + replace the useless checks as the one you found with assertions, comments, or remove them altogether; + in the interface teardown code, bzero() the struct ifnet before freeing, and add an XXX comment noting that at this point one should go and remove packets queued (ipintrq, arpintrq, reassembly queue, divert socket, maybe bpf, possibly dummynet pipes -- you see, the list easily becomes a long one; if we are smart, perhaps we can force places where packets accumulate to register a callback to be used at interface teardown to invalidate stale info in the mbuf metadata); Now part of the work in the last bullet might be saved if we replace rcvif with an if_index of some kind taken from a large, non-recycled namespace. On the other hand, considering that interface deletion is relatively rare and I am pretty sure it requires some kind of heavy housekeeping anyways, maybe the best approach is still to leave rcvif mostly unchanged (or use an if_index from a recycled namespace) and be more judicious when passing around pointers to interfaces. At least, when i wrote dummynet (which had similar issues as stored packets might held a reference to a firewall rule) i followed this approach, and it wasn't too hard. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed May 5 03:42:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7017B16A4CE; Wed, 5 May 2004 03:42:50 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id F19BF43D58; Wed, 5 May 2004 03:42:49 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id BEA49ACAF4; Wed, 5 May 2004 12:42:48 +0200 (CEST) Date: Wed, 5 May 2004 12:42:48 +0200 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org Message-ID: <20040505104248.GM24376@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xuy7d2Tq97A7mj7l" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-net@freebsd.org Subject: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 10:42:50 -0000 --Xuy7d2Tq97A7mj7l Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM netperf test. While running netperf tests between two FreeBSD machines directly connected em0 goes down once every few minutes and I've no idea why. Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it also works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). client# ifconfig em0 em0: flags=3D8843 mtu 1500 options=3D3 inet 192.168.50.2 netmask 0xffff0000 broadcast 192.168.255.255 ether 00:04:23:88:63:10 media: Ethernet autoselect (1000baseTX ) status: active client# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs = Coll em0 0 00:04:23:88:63:10 0 4852203 0 = 0 342995372 em0 0 192.168.0/16 192.168.50.2 8166424 - 4852201 - = - server# ifconfig em0 em0: flags=3D8843 mtu 1500 options=3D3 inet 192.168.0.1 netmask 0xffff0000 broadcast 192.168.255.255 ether 00:0c:76:20:b9:bb media: Ethernet autoselect (1000baseTX ) status: active server# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs = Coll em0 0 00:0c:76:20:b9:bb 0 2722131 0 = 0 2880618854 em0 0 192.168.0/16 192.168.0.1 14556076 - 2722142 - = - Any ideas? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --Xuy7d2Tq97A7mj7l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAmMUoForvXbEpPzQRAn4oAKDfIdYR4YMBzGkB6WJ3MwJ1DBfACwCcDPnn B+iB6Hsx/M0GeKBiVSV5msE= =2KTn -----END PGP SIGNATURE----- --Xuy7d2Tq97A7mj7l-- From owner-freebsd-net@FreeBSD.ORG Wed May 5 03:50:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03CE216A4CE; Wed, 5 May 2004 03:50:36 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27CD743D41; Wed, 5 May 2004 03:50:35 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 5BFB2ACADB; Wed, 5 May 2004 12:50:34 +0200 (CEST) Date: Wed, 5 May 2004 12:50:34 +0200 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org Message-ID: <20040505105034.GN24376@darkness.comp.waw.pl> References: <20040505104248.GM24376@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="op1wyikMGa8+7dN1" Content-Disposition: inline In-Reply-To: <20040505104248.GM24376@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-net@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 10:50:36 -0000 --op1wyikMGa8+7dN1 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote: +> Hi. +>=20 +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM netperf tes= t. +> While running netperf tests between two FreeBSD machines directly connec= ted +> em0 goes down once every few minutes and I've no idea why. +> Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it also +> works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). +>=20 +> client# ifconfig em0 +> em0: flags=3D8843 mtu 1500 +> options=3D3 +> inet 192.168.50.2 netmask 0xffff0000 broadcast 192.168.255.255 +> ether 00:04:23:88:63:10 +> media: Ethernet autoselect (1000baseTX ) +> status: active +> client# netstat -in +> Name Mtu Network Address Ipkts Ierrs Opkts Oer= rs Coll +> em0 0 00:04:23:88:63:10 0 4852203 0 = 0 342995372 +> em0 0 192.168.0/16 192.168.50.2 8166424 - 4852201 = - - +>=20 +> server# ifconfig em0 +> em0: flags=3D8843 mtu 1500 +> options=3D3 +> inet 192.168.0.1 netmask 0xffff0000 broadcast 192.168.255.255 +> ether 00:0c:76:20:b9:bb +> media: Ethernet autoselect (1000baseTX ) +> status: active +> server# netstat -in +> Name Mtu Network Address Ipkts Ierrs Opkts Oer= rs Coll +> em0 0 00:0c:76:20:b9:bb 0 2722131 0 = 0 2880618854 +> em0 0 192.168.0/16 192.168.0.1 14556076 - 2722142 = - - +>=20 +> Any ideas? This could be also helpful: client# sysctl hw.em0.stats=3D1 hw.em0.stats: -1em0: Excessive collisions =3D 0 em0: Symbol errors =3D 0 em0: Sequence errors =3D 0 em0: Defer count =3D 0 em0: Missed Packets =3D 0 em0: Receive No Buffers =3D 0 em0: Receive length errors =3D 0 em0: Receive errors =3D 0 em0: Crc errors =3D 0 em0: Alignment errors =3D 0 em0: Carrier extension errors =3D 0 em0: XON Rcvd =3D 0 em0: XON Xmtd =3D 0 em0: XOFF Rcvd =3D 0 em0: XOFF Xmtd =3D 0 em0: Good Packets Rcvd =3D 4852197 em0: Good Packets Xmtd =3D 2722144 -> -1 server# sysctl hw.em0.stats=3D1 hw.em0.stats: -1em0: Excessive collisions =3D 0 em0: Symbol errors =3D 0 em0: Sequence errors =3D 0 em0: Defer count =3D 0 em0: Missed Packets =3D 0 em0: Receive No Buffers =3D 0 em0: Receive length errors =3D 0 em0: Receive errors =3D 0 em0: Crc errors =3D 0 em0: Alignment errors =3D 0 em0: Carrier extension errors =3D 0 em0: XON Rcvd =3D 0 em0: XON Xmtd =3D 0 em0: XOFF Rcvd =3D 0 em0: XOFF Xmtd =3D 0 em0: Good Packets Rcvd =3D 2722143 em0: Good Packets Xmtd =3D 4852203 -> -1 --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --op1wyikMGa8+7dN1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAmMb6ForvXbEpPzQRAuzDAJ4uvGg/PVstWOZ/r532L3Fz2cC/bwCgmVTC tiZTtlEnzP5H+NAMnFz7iRw= =Y/3y -----END PGP SIGNATURE----- --op1wyikMGa8+7dN1-- From owner-freebsd-net@FreeBSD.ORG Wed May 5 04:31:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 013A516A4CE; Wed, 5 May 2004 04:31:44 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80E4743D54; Wed, 5 May 2004 04:31:42 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i45BVYOw046258; Wed, 5 May 2004 13:31:39 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4098D091.5020507@DeepCore.dk> Date: Wed, 05 May 2004 13:31:29 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20040505104248.GM24376@darkness.comp.waw.pl> <20040505105034.GN24376@darkness.comp.waw.pl> In-Reply-To: <20040505105034.GN24376@darkness.comp.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 11:31:44 -0000 Pawel Jakub Dawidek wrote: > On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote: > +> Hi. > +> > +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM netperf test. > +> While running netperf tests between two FreeBSD machines directly connected > +> em0 goes down once every few minutes and I've no idea why. > +> Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it also > +> works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). For what its worth I have problems with one em based interface as well, it locks the machine solid when used: em0: port 0xb000-0xb01f mem 0xfb100000-0xfb11ffff irq 10 at device 1.0 on pci1 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb100000 em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xb000 em0: [GIANT-LOCKED] em0: Ethernet address: 00:30:48:80:9f:b6 where this one works just fine: em1: port 0xa800-0xa83f mem 0xfa000000-0xfa01ffff irq 19 at device 10.0 on pci3 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfa000000 em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 em1: [GIANT-LOCKED] em1: Ethernet address: 00:30:48:80:9f:b7 The chips are these em0@pci1:1:0: class=0x020000 card=0x10758086 chip=0x10758086 rev=0x00 hdr=0x00 em1@pci3:10:0: class=0x020000 card=0x10768086 chip=0x10768086 rev=0x00 hdr=0x00 -- -Søren From owner-freebsd-net@FreeBSD.ORG Wed May 5 04:34:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C6B816A4CE for ; Wed, 5 May 2004 04:34:56 -0700 (PDT) Received: from hotmail.com (bay13-dav46.bay13.hotmail.com [64.4.31.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED18E43D4C for ; Wed, 5 May 2004 04:34:55 -0700 (PDT) (envelope-from abahnihy@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 May 2004 04:34:55 -0700 Received: from 80.75.183.94 by bay13-dav46.bay13.hotmail.com with DAV; Wed, 05 May 2004 11:34:55 +0000 X-Originating-IP: [80.75.183.94] X-Originating-Email: [abahnihy@hotmail.com] X-Sender: abahnihy@hotmail.com From: "Ahmed Hamada" To: Date: Wed, 5 May 2004 14:34:43 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 05 May 2004 11:34:55.0805 (UTC) FILETIME=[FD37AED0:01C43294] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: AODV RFC is now ratified X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 11:34:56 -0000 I would like to know how can I make the simulation for DSR and AODV in = OPNET. I have the IT Guru Academic edition (9.1). I make some simulations on the Ad Hoc protocols (e.g AODV) using this = free version and NIST models for AODV and DSR but I can't use it, some = errors appeare to me. When I make the simulation, the following errors apeare: Repository missing process model (aodv_app_sink) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_app_manager) =20 Warning reported by Simulation Kernel Repository missing process model (billiard_mobility) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_routing) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_wlan_mac) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_wlan_mac_interface) =20 Program Abort reported by Simulation Kernel The set of models necessary for running the simulation is incomplete. Check that all the 'repositories' attributes are complete. Please can any one help me to avoid these problems. Thanks alot=20 From owner-freebsd-net@FreeBSD.ORG Wed May 5 04:46:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD0DE16A4CE for ; Wed, 5 May 2004 04:46:21 -0700 (PDT) Received: from hotmail.com (bay13-dav39.bay13.hotmail.com [64.4.31.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7477943D53 for ; Wed, 5 May 2004 04:46:21 -0700 (PDT) (envelope-from abahnihy@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 May 2004 04:46:21 -0700 Received: from 80.75.183.94 by bay13-dav39.bay13.hotmail.com with DAV; Wed, 05 May 2004 11:46:21 +0000 X-Originating-IP: [80.75.183.94] X-Originating-Email: [abahnihy@hotmail.com] X-Sender: abahnihy@hotmail.com From: "Ahmed Hamada" To: Date: Wed, 5 May 2004 14:46:17 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 05 May 2004 11:46:21.0298 (UTC) FILETIME=[95CD9D20:01C43296] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Ask about aodv model in OPNET???? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 11:46:21 -0000 I would like to know how can I make the simulation for DSR and AODV in = OPNET. I have the IT Guru Academic edition (9.1). I make some simulations on the Ad Hoc protocols (e.g AODV) using this = free version and NIST models for AODV and DSR but I can't use it, some = errors appeare to me. When I make the simulation, the following errors apeare: Repository missing process model (aodv_app_sink) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_app_manager) =20 Warning reported by Simulation Kernel Repository missing process model (billiard_mobility) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_routing) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_wlan_mac) =20 Warning reported by Simulation Kernel Repository missing process model (aodv_wlan_mac_interface) =20 Program Abort reported by Simulation Kernel The set of models necessary for running the simulation is incomplete. Check that all the 'repositories' attributes are complete. Please can any one help me to avoid these problems. Thanks alot=20 blease send to me on abahnihy@hotmail.com=20 From owner-freebsd-net@FreeBSD.ORG Wed May 5 11:21:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A6A816A4CE for ; Wed, 5 May 2004 11:21:16 -0700 (PDT) Received: from mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6EB043D4C for ; Wed, 5 May 2004 11:21:15 -0700 (PDT) (envelope-from der_julian@web.de) Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLR18-0003Cd-ED; Wed, 05 May 2004 20:21:14 +0200 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12258-02; Wed, 5 May 2004 20:21:13 +0200 (MET DST) Received: from [141.30.207.25] (helo=jmmr) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLR17-0003CO-Gc; Wed, 05 May 2004 20:21:13 +0200 To: freebsd-net@freebsd.org From: Julian Stecklina Date: Wed, 05 May 2004 20:21:12 +0200 Message-ID: <86oep2spk7.fsf@web.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celery, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 cc: der_julian@web.de Subject: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 18:21:16 -0000 Hello, I have a problem with pppoed: It does not accept connections: My system is FreeBSD-current as of some days ago running on x86. ath0 is a DLINK WLAN card, if that matters. If I watch ethernet traffic via tcpdump, I see the connection attempt from the client but no answer from pppoed. Anyone knows whats going on? jmmr# /usr/libexec/pppoed -Fd -n 5 -p "*" ath0 pppoed: SENDING MESSAGE: pppoed: SOCKADDR: { fam=32 len=4 addr="." } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 0 pppoed: flags 0 pppoed: token 1 pppoed: cookie GENERIC (977674408) pppoed: cmd 268435462 pppoed: args (0 bytes) pppoed: RECEIVED RESPONSE: pppoed: SOCKADDR: { fam=32 len=8 addr="[39]:" } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 72 pppoed: flags 1 pppoed: token 1 pppoed: cookie GENERIC (977674408) pppoed: cmd nodeinfo (268435462) pppoed: args { type="socket" id=0x39 } Sending NGM_LISTHOOKS to ath0: pppoed: SENDING MESSAGE: pppoed: SOCKADDR: { fam=32 len=8 addr="ath0:" } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 0 pppoed: flags 0 pppoed: token 3 pppoed: cookie GENERIC (977674408) pppoed: cmd listhooks (268435463) pppoed: args pppoed: RECEIVED RESPONSE: pppoed: SOCKADDR: { fam=32 len=7 addr="[1]:" } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 208 pppoed: flags 1 pppoed: token 3 pppoed: cookie GENERIC (977674408) pppoed: cmd listhooks (268435463) pppoed: args { nodeinfo={ name="ath0" type="ether" id=0x1 hooks=1 } linkinfo=[ { ourhook="orphans" peerhook="ethernet" nodeinfo={ type="pppoe" id=0x4 hooks=1 } } ] } Got reply from id [1]: Type ether with 1 hooks Got [1]:orphans -> [4]:ethernet pppoed: SENDING MESSAGE: pppoed: SOCKADDR: { fam=32 len=5 addr=".:" } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 576 pppoed: flags 0 pppoed: token 6 pppoed: cookie GENERIC (977674408) pppoed: cmd connect (3) pppoed: args { path="ath0:orphans" ourhook="pppoe-52307" peerhook="pppoe-52307" } Sending PPPOE_LISTEN to .:pppoe-52307, provider pppoe pppoed: SENDING MESSAGE: pppoed: SOCKADDR: { fam=32 len=16 addr=".:pppoe-52307" } pppoed: NG_MESG : pppoed: vers 6 pppoed: arglen 39 pppoed: flags 0 pppoed: token 8 pppoed: cookie PPPOE (939032003) pppoed: sendto(.:pppoe-52307): No such file or directory pppoed: [error decoding message: No such file or directory] pppoed: cmd 3 pppoed: args (39 bytes) pppoed: 0000: 70 70 70 6f 65 2d 35 32 33 30 37 00 2b 92 04 08 pppoe-52307.+... pppoed: 0010: 03 00 00 00 22 ab 04 08 a8 20 46 3a 03 00 00 00 ....".... F:.... pppoed: 0020: 05 00 70 70 70 6f 65 ..pppoe pppoed[52307]: Listening as provider pppoe [pppoed is running, but I cannot find it via RASPPPOE from Windoze] The error message looks suspicious A search in the mailing lists showed someone with a similar problem a year ago, but his question was not answered on the list: http://lists.freebsd.org/pipermail/freebsd-stable/2003-July/002115.html Please keep me in CC, as I am not subscribed to this group. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming From owner-freebsd-net@FreeBSD.ORG Wed May 5 11:54:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6241E16A4CE; Wed, 5 May 2004 11:54:18 -0700 (PDT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69BF143D41; Wed, 5 May 2004 11:54:16 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i45Is4w6004655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2004 11:54:05 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i45Is4Q4074607; Wed, 5 May 2004 11:54:04 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4098D091.5020507@DeepCore.dk> Date: Wed, 05 May 2004 11:54:03 -0700 (PDT) From: John Polstra To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Bogosity: No, tests=bogofilter, spamicity=0.088833, version=0.14.5 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 18:54:18 -0000 On 05-May-2004 Søren Schmidt wrote: > For what its worth I have problems with one em based interface as well, > it locks the machine solid when used: > > em0: port > 0xb000-0xb01f mem 0xfb100000-0xfb11ffff irq 10 at device 1.0 on pci1 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb100000 > em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xb000 > em0: [GIANT-LOCKED] > em0: Ethernet address: 00:30:48:80:9f:b6 > > where this one works just fine: > > em1: port > 0xa800-0xa83f mem 0xfa000000-0xfa01ffff irq 19 at device 10.0 on pci3 > em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfa000000 > em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 > em1: [GIANT-LOCKED] > em1: Ethernet address: 00:30:48:80:9f:b7 > > > The chips are these > em0@pci1:1:0: class=0x020000 card=0x10758086 chip=0x10758086 rev=0x00 > hdr=0x00 > em1@pci3:10:0: class=0x020000 card=0x10768086 chip=0x10768086 rev=0x00 > hdr=0x00 Are either of the IRQs (10 and 19) shared with other devices? John From owner-freebsd-net@FreeBSD.ORG Wed May 5 11:57:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 013AA16A4CE; Wed, 5 May 2004 11:57:05 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17AA643D54; Wed, 5 May 2004 11:57:03 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i45Iutw6049977; Wed, 5 May 2004 20:57:00 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <409938F7.2090603@DeepCore.dk> Date: Wed, 05 May 2004 20:56:55 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Polstra References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 18:57:05 -0000 John Polstra wrote: > On 05-May-2004 Søren Schmidt wrote: > >>For what its worth I have problems with one em based interface as well, >>it locks the machine solid when used: >> >>em0: port >>0xb000-0xb01f mem 0xfb100000-0xfb11ffff irq 10 at device 1.0 on pci1 >>em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb100000 >>em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xb000 >>em0: [GIANT-LOCKED] >>em0: Ethernet address: 00:30:48:80:9f:b6 >> >>where this one works just fine: >> >>em1: port >>0xa800-0xa83f mem 0xfa000000-0xfa01ffff irq 19 at device 10.0 on pci3 >>em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfa000000 >>em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 >>em1: [GIANT-LOCKED] >>em1: Ethernet address: 00:30:48:80:9f:b7 >> >> >>The chips are these >>em0@pci1:1:0: class=0x020000 card=0x10758086 chip=0x10758086 rev=0x00 >>hdr=0x00 >>em1@pci3:10:0: class=0x020000 card=0x10768086 chip=0x10768086 rev=0x00 >>hdr=0x00 > > > Are either of the IRQs (10 and 19) shared with other devices? Yes, the working one is shared with an (unused) USB port -- -Søren From owner-freebsd-net@FreeBSD.ORG Wed May 5 12:04:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C01C16A4CE; Wed, 5 May 2004 12:04:42 -0700 (PDT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8137243D45; Wed, 5 May 2004 12:04:41 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i45J4W2n004734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 May 2004 12:04:32 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i45J4WAl074644; Wed, 5 May 2004 12:04:32 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <409938F7.2090603@DeepCore.dk> Date: Wed, 05 May 2004 12:04:31 -0700 (PDT) From: John Polstra To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Bogosity: No, tests=bogofilter, spamicity=0.112366, version=0.14.5 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 19:04:42 -0000 On 05-May-2004 Søren Schmidt wrote: > John Polstra wrote: >> Are either of the IRQs (10 and 19) shared with other devices? > > Yes, the working one is shared with an (unused) USB port I was hoping the failing IRQ would be shared. So much for that idea. :-) John From owner-freebsd-net@FreeBSD.ORG Wed May 5 13:21:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F96416A4CE for ; Wed, 5 May 2004 13:21:33 -0700 (PDT) Received: from hotmail.com (bay13-dav10.bay13.hotmail.com [64.4.31.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id D667643D31 for ; Wed, 5 May 2004 13:21:32 -0700 (PDT) (envelope-from abahnihy@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 May 2004 13:21:32 -0700 Received: from 80.75.183.84 by bay13-dav10.bay13.hotmail.com with DAV; Wed, 05 May 2004 20:21:31 +0000 X-Originating-IP: [80.75.183.84] X-Originating-Email: [abahnihy@hotmail.com] X-Sender: abahnihy@hotmail.com From: "Ahmed Hamada" To: Date: Wed, 5 May 2004 22:16:32 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 05 May 2004 20:21:32.0725 (UTC) FILETIME=[8E730E50:01C432DE] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Ask about AODV model in OPNET ????????? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 20:21:33 -0000 Hi I am student in facaulty of engineering. My undergraduate project is = "Mobile Ad Hoc Network". I read alot about it and now I want to make = some simulations to verify some points. I want to use the OPNET in my = simulations so I download the academic edition 9.1 (the free version) = but I found it (the academic edition) doesn't support the ad hoc = protocols. "" The other editions support it"" . I am searching on any one to help me. I ask god that you be this one. If you have any complete version or version supports the ad hoc protocol = (e.g AODV or DSR), please help me. I have the NIST models for AODV and DSR for version 7 and I think it = operates at any new version. I rely on you generousity and hope you would give me the program. Regards, Ahmed Hamada. abahnihy@hotmail.com=20 Ain Shams University. Egypt, Cairo. From owner-freebsd-net@FreeBSD.ORG Wed May 5 14:09:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A409316A4CF for ; Wed, 5 May 2004 14:09:13 -0700 (PDT) Received: from mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A4C43D31 for ; Wed, 5 May 2004 14:09:13 -0700 (PDT) (envelope-from der_julian@web.de) Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLTdg-0000Wb-D9; Wed, 05 May 2004 23:09:12 +0200 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01985-01; Wed, 5 May 2004 23:09:11 +0200 (MET DST) Received: from [141.30.207.25] (helo=jmmr) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLTdf-0000WX-Cf; Wed, 05 May 2004 23:09:11 +0200 To: "Artemis Clide Frog" References: <86oep2spk7.fsf@web.de> From: Julian Stecklina Date: Wed, 05 May 2004 23:09:10 +0200 In-Reply-To: (Artemis Clide Frog's message of "Wed, 5 May 2004 19:44:38 +0100") Message-ID: <86ekpyshs9.fsf@web.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celery, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 cc: freebsd-net@freebsd.org Subject: Re: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 21:09:13 -0000 "Artemis Clide Frog" writes: > Have you configured PPP in Daemon mode correctly? Take a look at this > whitepaper - it may render some assistance. It was insightful and I played with pppoed a second time, but got not further. I also tried to use mpd as PPPoE server (this was a bit challenging as documentation is scarce), it also says that it's listening on ath0 for PPPoE connections, but connection attempts remain unanswered. Thanks for the pointer anyway. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming From owner-freebsd-net@FreeBSD.ORG Wed May 5 15:10:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58C8F16A4E2 for ; Wed, 5 May 2004 15:10:27 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F3B043D53 for ; Wed, 5 May 2004 15:10:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004050522102301100d6aefe>; Wed, 5 May 2004 22:10:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA71692; Wed, 5 May 2004 15:10:21 -0700 (PDT) Date: Wed, 5 May 2004 15:10:19 -0700 (PDT) From: Julian Elischer To: Julian Stecklina In-Reply-To: <86ekpyshs9.fsf@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Artemis Clide Frog cc: freebsd-net@freebsd.org Subject: Re: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 22:10:27 -0000 use tcpdump to watch teh packets coming and going.. tcpdump can interpret PPPOE packets. On Wed, 5 May 2004, Julian Stecklina wrote: > "Artemis Clide Frog" writes: > > > Have you configured PPP in Daemon mode correctly? Take a look at this > > whitepaper - it may render some assistance. > > It was insightful and I played with pppoed a second time, but got not > further. I also tried to use mpd as PPPoE server (this was a bit > challenging as documentation is scarce), it also says that it's > listening on ath0 for PPPoE connections, but connection attempts > remain unanswered. > > Thanks for the pointer anyway. > > Regards, > -- > Julian Stecklina > > Signed and encrypted mail welcome. > Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 > FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 > > Any sufficiently complicated C or Fortran program > contains an ad hoc informally-specified bug-ridden > slow implementation of half of Common Lisp. > - Greenspun's Tenth Rule of Programming > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed May 5 15:38:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A667F16A4CE for ; Wed, 5 May 2004 15:38:18 -0700 (PDT) Received: from mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C6743D5E for ; Wed, 5 May 2004 15:38:18 -0700 (PDT) (envelope-from der_julian@web.de) Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLV1s-0000ME-9D; Thu, 06 May 2004 00:38:16 +0200 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01342-01; Thu, 6 May 2004 00:38:15 +0200 (MET DST) Received: from [141.30.207.25] (helo=jmmr) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BLV1r-0000M3-9m; Thu, 06 May 2004 00:38:15 +0200 To: Julian Elischer References: From: Julian Stecklina Date: Thu, 06 May 2004 00:38:14 +0200 In-Reply-To: (Julian Elischer's message of "Wed, 5 May 2004 15:10:19 -0700 (PDT)") Message-ID: <868yg6sdnt.fsf@web.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celery, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 cc: Artemis Clide Frog cc: freebsd-net@freebsd.org Subject: Re: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 22:38:18 -0000 Julian Elischer writes: > use tcpdump to watch teh packets coming and going.. > tcpdump can interpret PPPOE packets. I already did. The only packets coming over the link are some request packets from RASPPPOE on the windoze client jmmr# tcpdump -ev -i ath0 tcpdump: listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes 00:32:17.972907 00:0a:e9:02:56:bf > Broadcast, ethertype PPPoE D (0x8863), length 44: PPPoE PADI [Service-Name] [Host-Uniq 0x5253504500000000D06F2038BA33C401] [repeated 6 times] 00:0a:e9:02:56:bf is the MAC address of the client. There is no response whatsoever from the PPPoE server. I hope this means I can rule out configuration errors? Btw, pppoed loads ng_pppoe the first time it is started, and refuses to load the second time because of "kldload: ng_pppoe: File exists". So I unload it and try again... strange. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming From owner-freebsd-net@FreeBSD.ORG Thu May 6 00:01:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2266A16A4CE for ; Thu, 6 May 2004 00:01:05 -0700 (PDT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 998FD43D1D for ; Thu, 6 May 2004 00:01:03 -0700 (PDT) (envelope-from suz@crl.hitachi.co.jp) Received: from s30.uki-uki.net (galilei.ebina.hitachi.co.jp [158.214.184.6]) by v6.hitachi.co.jp (8.12.11/8.11.6) with ESMTP id i46710iX090447; Thu, 6 May 2004 16:01:01 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Thu, 06 May 2004 16:00:42 +0900 Message-ID: From: SUZUKI Shinsuke To: Lukasz.Stelmach@telmark.waw.pl X-cite: xcite 1.33 In-Reply-To: <20040504181620.GB9699@tygrys.k.telmark.waw.pl> References: <20040504181620.GB9699@tygrys.k.telmark.waw.pl> User-Agent: User-Agent: Wanderlust/2.11.26 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: if_stf bug/feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 07:01:05 -0000 Hello, and Sorry for a delayed answer. >>>>> On Tue, 4 May 2004 20:16:20 +0200 >>>>> Lukasz.Stelmach@telmark.waw.pl(Lukasz Stelmach) said: > stf interface has one feature, very inconvinient for me. As far as i could > read the source it returns ENETDOWN if the inet4 address of the machine's > net interface (primary or the one would be used) does not match proper > part of stf's address. This is ok if one has public, routable ip4 address. > Since my machine is behind a firewall that forwards and nats all proto > 41 ip packets I'd rather stf didn't complain about it. > > Now what would you suggest? I may comment out the "if" in if_stf.c:348. > However this check should be done in general but there also should be > some at-runtime method to overide it (maybe sysctl > net.inet6.ip6.strictstfaddr?). 6to4 is not designed for a node with private IPv4 address, as is hexplicitly stated in section 2 of RFC3056. Suppose that a subscriber site has at least one valid, globally unique 32-bit IPv4 address, referred to in this document as V4ADDR. This address MUST be duly allocated to the site by an address registry (possibly via a service provider) and it MUST NOT be a private address [RFC 1918]. So my suggestion to tackle such situation in FreeBSD-4.x is either of the following two. - configure a static gif tunnel toward a site. Although it's a "static" tunnel, some site provides a tool to automatically configure gif tunnel even behind NAT (e.g. ports/net/freenet6) - enable 6to4 on your NAT-box and let it advertise an IPv6 prefix (if not possible, please ask the vendor to support such feature! :-)) Thanks, ---- SUZUKI, Shinsuke @ Hitachi / KAME Project From owner-freebsd-net@FreeBSD.ORG Thu May 6 00:40:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04F7516A4CE for ; Thu, 6 May 2004 00:40:54 -0700 (PDT) Received: from mail.kras.ru (ns.kras.ru [62.213.32.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E6743D54 for ; Thu, 6 May 2004 00:40:52 -0700 (PDT) (envelope-from chmax@kras.ru) Received: by mail.kras.ru (Postfix, from userid 426) id 3E713668A8D; Thu, 6 May 2004 15:42:05 +0800 (KRAST) Received: from localhost (unknown [192.168.1.250]) by mail.kras.ru (Postfix) with ESMTP id 51E7E668A60 for ; Thu, 6 May 2004 15:42:01 +0800 (KRAST) Date: Thu, 6 May 2004 15:43:19 +0800 From: =?Windows-1251?B?zODq8ejsINfl8/Hu4g==?= X-Priority: 3 (Normal) Message-ID: <910014759.20040506154320@kras.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Subject: "No buffer space available" problem. FreeBSD 4.7, mpd 3.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?Windows-1251?B?zODq8ejsINfl8/Hu4g==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 07:40:54 -0000 Hello all! A couple days ago i've got next problem with my ISP (before everything were ok). When connection to the VPN server is established then I can't ping anything through the tunel even VPN server (192.168.10.1): 64 bytes from 192.168.10.1: icmp_seq=503 ttl=64 time=0.634 ms 64 bytes from 192.168.10.1: icmp_seq=504 ttl=64 time=0.689 ms 64 bytes from 192.168.10.1: icmp_seq=505 ttl=64 time=0.645 ms 64 bytes from 192.168.10.1: icmp_seq=506 ttl=64 time=0.664 ms ping: sendto: Resource deadlock avoided ping: sendto: Resource deadlock avoided ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available In moment when mdp connetction established ping response is over. There is tcpdump -i ng0: tcpdump: listening on ng0 12:23:40.489990 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:41.499975 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:42.509985 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:43.519997 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:44.530011 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:45.540022 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:46.550046 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:47.560053 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:48.570068 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:49.580084 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:50.590127 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:51.600118 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:52.610151 192.168.100.102 > 192.168.10.1: icmp: echo request 12:23:53.620149 192.168.100.102 > 192.168.10.1: icmp: echo request Seems like nothing can get through the tunnel. netstat -m: 196/1328/3328 mbufs in use (current/peak/max): 193 mbufs allocated to data 3 mbufs allocated to packet headers 192/236/832 mbuf clusters in use (current/peak/max) 1304 Kbytes allocated to network (52% of mb_map in use) 652 requests for memory denied 15 requests for memory delayed 29 calls to protocol drain routines Looks like no any problem here. I'v red someting similar about Cisco VPN servers, but solution that were given did'n help me. ifconfig: xl0: flags=8843 mtu 1500 options=3 inet 192.168.10.12 netmask 0xffffff00 broadcast 192.168.10.255 ether 00:01:02:ca:0c:24 media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=8843 mtu 1500 inet 192.168.0.10 netmask 0xffffffc0 broadcast 192.168.0.63 ether 00:a0:c9:69:91:8a media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 faith0: flags=8002 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 ng0: flags=88d1 mtu 1500 inet 192.168.100.102 --> 192.168.10.1 netmask 0xffffffff >mpd.comf: default: load vpn vpn: new -i ng0 ciscovpn pptp192 set bundle authname "*******" set ipcp ranges 192.168.100.102 192.168.10.1 set iface up-script /usr/local/etc/mpd/iface-up.sh load vpnpptp open vpnpptp: set bundle disable compression # set bundle no crypt-reqd set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-stateless set iface idle 0 set ipcp disable vjcomp set ipcp enable req-pri-dns req-sec-dns set link max-redial 1 set link keep-alive 0 0 set link disable pap chap set link disable acfcomp protocomp > end >mpd.links pptp192: set link type pptp set pptp peer 192.168.10.1 set pptp enable originate outcall > end >iface-up.sh #!/bin/sh iface=$1 proto=$2 localip=$3 remoteip=$4 vpn_private_ip=192.168.10.1 ifconfig $iface $proto $localip $vpn_private_ip netmask 0xffffffff ifconfig $iface mtu 1500 route flush route add default -interface $iface > end And there is nothing strange in mpd.log also As far as I know on the ISP side is mdp-3.17 and FreeBSD too. And there is no any problems whith XP box. From owner-freebsd-net@FreeBSD.ORG Thu May 6 01:21:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2833816A4CE for ; Thu, 6 May 2004 01:21:17 -0700 (PDT) Received: from 153-bem-1.acn.waw.pl (153-bem-1.acn.waw.pl [62.121.80.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 5253043D2D for ; Thu, 6 May 2004 01:21:15 -0700 (PDT) (envelope-from lukasz.stelmach@k.telmark.waw.pl) Received: (qmail 15400 invoked by uid 1000); 6 May 2004 08:21:13 -0000 Date: Thu, 6 May 2004 10:21:13 +0200 From: Lukasz Stelmach To: SUZUKI Shinsuke Message-ID: <20040506082113.GA15255@tygrys.k.telmark.waw.pl> References: <20040504181620.GB9699@tygrys.k.telmark.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Mail-Editor: nvi X-GPG-Fingerprint: 68B8 6D4F 0C5E 291F C4E0 BBF4 35DC D8F2 C9BD 2BDC X-GPG-Key: http://www.ee.pw.edu.pl/~stelmacl/gpg_key.txt cc: freebsd-net@freebsd.org Subject: Re: if_stf bug/feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 08:21:17 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Byla godzina 16:00:42 w Thursday 06 May, gdy do autobusu wsiadl kanar i wrzasnal:"SUZUKI Shinsuke!!! Bilecik do kontroli!!!" A on(a) na to: >>>>>> On Tue, 4 May 2004 20:16:20 +0200 >>>>>> Lukasz.Stelmach@telmark.waw.pl(Lukasz Stelmach) said: >=20 > > stf interface has one feature, very inconvinient for me. As far as i co= uld > > read the source it returns ENETDOWN if the inet4 address of the machine= 's > > net interface (primary or the one would be used) does not match proper > > part of stf's address. This is ok if one has public, routable ip4 addre= ss. [...] > 6to4 is not designed for a node with private IPv4 address, as is > hexplicitly stated in section 2 of RFC3056. >=20 > Suppose that a subscriber site has at least one valid, globally > unique 32-bit IPv4 address, referred to in this document as V4ADDR. > This address MUST be duly allocated to the site by an address > registry (possibly via a service provider) and it MUST NOT be a > private address [RFC 1918]. Well i *have*got* one v4ADDR that is assigned to my nat/router-box. I have also configured that it should pass all packets that are not part of some known connections (from M1 M2 .. Mn) (including but not limited to proto 41) to one specified machine (name it TIGGER) that acts as the end of 6to4 tunnel for all other computers in the LAN. Now, for i controll both the nat and TIGGER i can do such manglig without any harm. Let's say taht to the rest of the world the nat+TIGGER act like a single machine. Here is a quick schetch: [M1]+ | [M2]+ | 10.1.1.254 [Mn]+---------[nat]-------{THE NET} | 1.2.3.4 [TIGGER]+ 10.1.1.2 IP packet with proto 41 comes to the nat with dstaddr of 1.2.3.4 it gets mangled to 10.1.1.2 and goes to TIGGER. When tiger sends simmilar packet with srcaddr of 10.1.1.2 it gets mangled to 1.2.3.4 before it leavs the nat. But nat doesn't know anything about IPv6 or 6to4 it works only on IPv4 packets. > So my suggestion to tackle such situation in FreeBSD-4.x is either of > the following two. >=20 > - configure a static gif tunnel toward a site. >=20 > Although it's a "static" tunnel, some site provides a tool > to automatically configure gif tunnel even behind NAT > (e.g. ports/net/freenet6) 6to4 seems to me to be better since it takes probably the shortest path. Besides it is not a problem of tools for "behind NAT" situation since my nat passes tunnel packets. > - enable 6to4 on your NAT-box and let it advertise an IPv6 > prefix (if not possible, please ask the vendor to support > such feature! :-)) Yeah, of course, naturlich... ;-) Especially it is a d-link di804-hv cheap and crude device and support@dlink.com seems to be redirected to /dev/null. Czym sie cieplo SUZUKI... --=20 |/ |_, _ .- --, Ju=BF z ka=BFdej strony pe=B3zn=B1, potworne =BF= =B1dze |__ |_|. | \ |_|. ._' /_. B=EAd=EA uprawia=B3 nierz=B1d, za pieni= =B1ze --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmfV5NdzY8sm9K9wRAv6kAJ9iIq4x4Du+KMiTFtGR0Vuql7Q7KgCbB/bQ fFTivn2UPO89gcXULK/b890= =LLdR -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-net@FreeBSD.ORG Thu May 6 02:33:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B22C16A4CE for ; Thu, 6 May 2004 02:33:22 -0700 (PDT) Received: from mail.kras.ru (ns.kras.ru [62.213.32.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A430043D45 for ; Thu, 6 May 2004 02:33:20 -0700 (PDT) (envelope-from chmax@kras.ru) Received: by mail.kras.ru (Postfix, from userid 426) id 4EF6A668AFF; Thu, 6 May 2004 17:34:33 +0800 (KRAST) Received: from localhost (unknown [192.168.1.250]) by mail.kras.ru (Postfix) with ESMTP id 454BA668AE4 for ; Thu, 6 May 2004 17:34:29 +0800 (KRAST) Date: Thu, 6 May 2004 17:35:48 +0800 From: =?Windows-1251?B?zODq8ejsINfl8/Hu4g==?= X-Priority: 3 (Normal) Message-ID: <1123918863.20040506173548@kras.ru> To: freebsd-net@freebsd.org In-Reply-To: <20040506082937.1FEB3668B29@mail.kras.ru> References: <910014759.20040506154320@kras.ru> <20040506082937.1FEB3668B29@mail.kras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit Subject: Re[2]: "No buffer space available" problem. FreeBSD 4.7, mpd 3.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: =?Windows-1251?B?zODq8ejsINfl8/Hu4g==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 09:33:22 -0000 Thursday, May 6, 2004, 4:28:29 PM, you wrote: I tryed increase NMBCLUSTER, it didn't help. How can i check if my connection work properly? VEL> CMIIW, I once had the same problem, but in my other console the system said VEL> about increasing my NMBCLUSTER value. So I did two things, perhaps you can VEL> do the same. Do `arp -d -a' to clean up ARP cache, and Try increasing your VEL> nmbcluster, if its value is not big enough. Try `sysctl -a | grep VEL> nmbcluster' and look at its value. I use `65535'. This value cannot be VEL> change interactively from shell, you must edit /boot/loader.conf and add VEL> kern.ipc.nmbclusters=. BUT other there's a possibility that the VEL> connection was currently unstable, or down, or got network outage. VEL> A couple days ago i've got next problem with my ISP (before everything VEL> were ok). When connection to the VPN server is established then I can't VEL> ping anything through the tunel even VPN server (192.168.10.1): VEL> 64 bytes from 192.168.10.1: icmp_seq=503 ttl=64 time=0.634 ms VEL> 64 bytes from 192.168.10.1: icmp_seq=504 ttl=64 time=0.689 ms VEL> 64 bytes from 192.168.10.1: icmp_seq=505 ttl=64 time=0.645 ms VEL> 64 bytes from 192.168.10.1: icmp_seq=506 ttl=64 time=0.664 ms VEL> ping: sendto: Resource deadlock avoided VEL> ping: sendto: Resource deadlock avoided VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> ping: sendto: No buffer space available VEL> In moment when mdp connetction established ping response is over. VEL> There is tcpdump -i ng0: VEL> tcpdump: listening on ng0 VEL> 12:23:40.489990 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:41.499975 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:42.509985 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:43.519997 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:44.530011 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:45.540022 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:46.550046 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:47.560053 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:48.570068 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:49.580084 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:50.590127 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:51.600118 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:52.610151 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> 12:23:53.620149 192.168.100.102 > 192.168.10.1: icmp: echo request VEL> Seems like nothing can get through the tunnel. VEL> netstat -m: VEL> 196/1328/3328 mbufs in use (current/peak/max): VEL> 193 mbufs allocated to data VEL> 3 mbufs allocated to packet headers VEL> 192/236/832 mbuf clusters in use (current/peak/max) VEL> 1304 Kbytes allocated to network (52% of mb_map in use) VEL> 652 requests for memory denied VEL> 15 requests for memory delayed VEL> 29 calls to protocol drain routines VEL> Looks like no any problem here. VEL> I'v red someting similar about Cisco VPN servers, but solution that VEL> were given did'n help me. VEL> ifconfig: VEL> xl0: flags=8843 mtu 1500 VEL> options=3 VEL> inet 192.168.10.12 netmask 0xffffff00 broadcast 192.168.10.255 VEL> ether 00:01:02:ca:0c:24 VEL> media: Ethernet autoselect (100baseTX ) VEL> status: active VEL> fxp0: flags=8843 mtu 1500 VEL> inet 192.168.0.10 netmask 0xffffffc0 broadcast 192.168.0.63 VEL> ether 00:a0:c9:69:91:8a VEL> media: Ethernet autoselect (100baseTX ) VEL> status: active VEL> lp0: flags=8810 mtu 1500 VEL> faith0: flags=8002 mtu 1500 VEL> lo0: flags=8049 mtu 16384 VEL> inet 127.0.0.1 netmask 0xff000000 VEL> ppp0: flags=8010 mtu 1500 VEL> sl0: flags=c010 mtu 552 VEL> ng0: VEL> flags=88d1 mtu VEL> 1500 VEL> inet 192.168.100.102 --> 192.168.10.1 netmask 0xffffffff >>mpd.comf: VEL> default: VEL> load vpn VEL> vpn: VEL> new -i ng0 ciscovpn pptp192 VEL> set bundle authname "*******" VEL> set ipcp ranges 192.168.100.102 192.168.10.1 VEL> set iface up-script /usr/local/etc/mpd/iface-up.sh VEL> load vpnpptp VEL> open VEL> vpnpptp: VEL> set bundle disable compression VEL> # set bundle no crypt-reqd VEL> set bundle enable compression VEL> set ccp yes mppc VEL> set ccp yes mpp-e40 VEL> set ccp yes mpp-e128 VEL> set bundle enable crypt-reqd VEL> set ccp yes mpp-stateless VEL> set iface idle 0 VEL> set ipcp disable vjcomp VEL> set ipcp enable req-pri-dns req-sec-dns VEL> set link max-redial 1 VEL> set link keep-alive 0 0 VEL> set link disable pap chap VEL> set link disable acfcomp protocomp >> end >>mpd.links VEL> pptp192: VEL> set link type pptp VEL> set pptp peer 192.168.10.1 VEL> set pptp enable originate outcall >> end >>iface-up.sh VEL> #!/bin/sh VEL> iface=$1 VEL> proto=$2 VEL> localip=$3 VEL> remoteip=$4 VEL> vpn_private_ip=192.168.10.1 VEL> ifconfig $iface $proto $localip $vpn_private_ip netmask 0xffffffff VEL> ifconfig $iface mtu 1500 VEL> route flush VEL> route add default -interface $iface >> end VEL> And there is nothing strange in mpd.log also VEL> As far as I know on the ISP side is mdp-3.17 and FreeBSD too. VEL> And there is no any problems whith XP box. From owner-freebsd-net@FreeBSD.ORG Thu May 6 04:42:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 789DC16A4CF for ; Thu, 6 May 2004 04:42:44 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED72C43D5A for ; Thu, 6 May 2004 04:42:43 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9E51D37825 for ; Thu, 6 May 2004 13:42:42 +0200 (CEST) Received: from [163.117.139.95] (cimborrio.it.uc3m.es [163.117.139.95]) by smtp01.uc3m.es (Postfix) with ESMTP id 8C48D3782D for ; Thu, 6 May 2004 13:42:42 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Thu, 6 May 2004 13:42:32 +0200 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200405061342.33101.jrh@it.uc3m.es> Subject: wireless support of roaming between subnets ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 11:42:44 -0000 Hello, I'd like to try on some changes that I've made in our VoIP testbed for mobility support at the application layer. If the user requires support for seamless voice communication during active call sessions on the mobile UA, it is imperative that the wireless LAN setup should support roaming across subnets, i.e. the mobile host should obtain a different IP address if it reassociates itself with an Access Point (AP) in a different subnet. I'm quite newbie to the wireless support of FreeBSD. I've got in my hands a wireless card with a Prims2 chipset, that's the only card I can use at this moment.. I've searched a little bit in Google and I've found out a guy that have made a patch for the linux wlan driver (www.linux-wlan.org), in order to support "roaming across subnets". I've got a lot of questions :-) Where is it coded the wireless support on FreeBSD ? I'd like to use FreeBSD-4.9 if that is possible....Besides, do I need to try to apply the previous patch to support roaming ? Any pointer or suggestion will be useful, of course. The guy that has made the patch seems to hack the part that starts with: "case HFA384x_LINK_AP_CHANGE:", I've made a "grep -r LINK_AP_CHANGE" in "/usr/src" but I found nothing :-( Thanks you very much ! -- ****** JFRH ****** Prof: So the American government went to IBM to come up with a data encryption standard and they came up with ... Student: EBCDIC! From owner-freebsd-net@FreeBSD.ORG Thu May 6 06:07:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AE7816A4CE for ; Thu, 6 May 2004 06:07:47 -0700 (PDT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A62E43D1F for ; Thu, 6 May 2004 06:07:46 -0700 (PDT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-14-98.w81-249.abo.wanadoo.fr [81.249.10.98]) by www.citello.it (Postfix) with ESMTP id A4DD9D39 for ; Thu, 6 May 2004 15:07:43 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id CB6B9412F; Thu, 6 May 2004 15:01:33 +0200 (CEST) Date: Thu, 6 May 2004 15:01:32 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Message-Id: <20040506150132.2d545eda@localhost> In-Reply-To: <200405061342.33101.jrh@it.uc3m.es> References: <200405061342.33101.jrh@it.uc3m.es> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: wireless support of roaming between subnets ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 13:07:47 -0000 Hi Juan, On Thu, 6 May 2004 Juan Rodriguez Hervella wrote: > Hello, > > I'd like to try on some changes that I've made in our VoIP > testbed for mobility support at the application layer. > > If the user requires support for seamless voice communication during > active call sessions on the mobile UA, it is imperative that the > wireless LAN setup should support roaming across subnets, i.e. the > mobile host should obtain a different IP address if it reassociates > itself with an Access Point (AP) in a different subnet. I don't understand... If you want to keep your session at a layer above IP, you must *not* change IP address when you roam. You can achieve this with Mobile IP. I don't know about MIPv4, but MIPv6 is supported by KAME (http://www.kame.net/) I would suggest trying the KAME mailing list. Regarding seamless handover and similar stuff, you should check the various IETF working groups, like MIPv6 Signaling and Handoff Optimization (mipshop) http://www.ietf.org/html.charters/mipshop-charter.html Otherwise, if you really want to do what you stated: > the mobile host should obtain a different IP address you are already all set for this: when the 802.11 card associates, you trigger a DHCP request to get a new address. Have also a look at the following thread: http://docs.FreeBSD.org/cgi/mid.cgi?39FE23FA-7F75-11D8-8F99-000A95CDA38A [..] > Where is it coded the wireless support on FreeBSD ? I'd like > to use FreeBSD-4.9 if that is possible....Besides, do I need to > try to apply the previous patch to support roaming ? Any > pointer or suggestion will be useful, of course. the patch you are referring to is for linux, so you cannot apply it to fbsd ;-) wireless support in fbsd uses a new unified framework called "wlan", start with "man wlan" on a freebsd-current machine, or look at http://www.freebsd.org/cgi/man.cgi source is at /usr/src/sys/net80211/ Don't know about 4-stable. marco From owner-freebsd-net@FreeBSD.ORG Thu May 6 07:22:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68A6516A4CE for ; Thu, 6 May 2004 07:22:55 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25D9D43D6A for ; Thu, 6 May 2004 07:22:54 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B179278AD; Thu, 6 May 2004 16:22:52 +0200 (CEST) Received: from [163.117.139.95] (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 85EDB2789F; Thu, 6 May 2004 16:22:52 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Thu, 6 May 2004 16:22:43 +0200 User-Agent: KMail/1.6 References: <200405061342.33101.jrh@it.uc3m.es> <20040506150132.2d545eda@localhost> In-Reply-To: <20040506150132.2d545eda@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061622.43343.jrh@it.uc3m.es> Subject: Re: wireless support of roaming between subnets ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 14:22:55 -0000 Thank you very much for your reply....see below On Thursday 06 May 2004 15:01, Marco Molteni wrote: > Hi Juan, > > On Thu, 6 May 2004 Juan Rodriguez Hervella wrote: > > Hello, > > > > I'd like to try on some changes that I've made in our VoIP > > testbed for mobility support at the application layer. > > > > If the user requires support for seamless voice communication during > > active call sessions on the mobile UA, it is imperative that the > > wireless LAN setup should support roaming across subnets, i.e. the > > mobile host should obtain a different IP address if it reassociates > > itself with an Access Point (AP) in a different subnet. > > I don't understand... > > If you want to keep your session at a layer above IP, you must > *not* change IP address when you roam. You can achieve this with > Mobile IP. I don't know about MIPv4, but MIPv6 is supported by > KAME (http://www.kame.net/) I don't wanna use MIP, what Im trying to test is a simple modification to the UA to re-register when his IP address changes. The soft hand-off implementation has been based on the call flow for sending Re-INVITE in case of IP address change, as you can read here: http://www.iptel.org/info/players/ietf/callflows/draft-ietf-sipping-basic-call-flows-01.txt (look for "Session with re-INVITE (IP Address Change)................62") I haven't tested it yet, I have the bad habit of asking before trying it I will read your references, thank you again ! > > I would suggest trying the KAME mailing list. > > Regarding seamless handover and similar stuff, you should check the > various IETF working groups, like > MIPv6 Signaling and Handoff Optimization (mipshop) > http://www.ietf.org/html.charters/mipshop-charter.html > > Otherwise, if you really want to do what you stated: > > the mobile host should obtain a different IP address > > you are already all set for this: when the 802.11 card associates, > you trigger a DHCP request to get a new address. > > Have also a look at the following thread: > http://docs.FreeBSD.org/cgi/mid.cgi?39FE23FA-7F75-11D8-8F99-000A95CDA38A > > [..] > > > Where is it coded the wireless support on FreeBSD ? I'd like > > to use FreeBSD-4.9 if that is possible....Besides, do I need to > > try to apply the previous patch to support roaming ? Any > > pointer or suggestion will be useful, of course. > > the patch you are referring to is for linux, so you cannot apply it > to fbsd ;-) > > wireless support in fbsd uses a new unified framework called "wlan", start > with "man wlan" on a freebsd-current machine, or look at > http://www.freebsd.org/cgi/man.cgi > > source is at > /usr/src/sys/net80211/ > > Don't know about 4-stable. > > marco > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- ****** JFRH ****** We are all worms. But I do believe I am a glowworm. -- Winston Churchill From owner-freebsd-net@FreeBSD.ORG Thu May 6 07:46:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D41516A4CE for ; Thu, 6 May 2004 07:46:50 -0700 (PDT) Received: from FreeBSD.csie.NCTU.edu.tw (freebsd.csie.nctu.edu.tw [140.113.17.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E80F43D45 for ; Thu, 6 May 2004 07:46:50 -0700 (PDT) (envelope-from jwwang@FreeBSD.csie.NCTU.edu.tw) Received: from localhost (localhost.csie.nctu.edu.tw [127.0.0.1]) by FreeBSD.csie.NCTU.edu.tw (Postfix) with ESMTP id 82D0E106C1B; Thu, 6 May 2004 22:46:21 +0800 (CST) Received: from FreeBSD.csie.NCTU.edu.tw ([127.0.0.1]) by localhost (FreeBSD.csie.NCTU.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43432-05; Thu, 6 May 2004 22:46:17 +0800 (CST) Received: by FreeBSD.csie.NCTU.edu.tw (Postfix, from userid 1005) id 070AD106C07; Thu, 6 May 2004 22:46:17 +0800 (CST) Date: Thu, 6 May 2004 22:46:16 +0800 From: Jian-Wei Wang To: freebsd-net@freebsd.org Message-ID: <20040506144616.GA43633@FreeBSD.csie.NCTU.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=big5 Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Problem with ng_ether packet flow.. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 14:46:50 -0000 Hi, I spent times to figure out the packet flow with ng_ether, like this: upper layer | ^ [ether_demux] ^ | +---<---[ng_ether_rcvdata]--<-- 'upper' --<--, ^ \ <--[bdg_forward]--<--+ ng_tee | / +--->---[ng_ether_input]---->-- 'lower' -->--` ^ [ether_input] ^ | device Why the [ng_ether_rcvdata] won't check if packets should travel to the [bdg_forward] when they are bridged packets? i.e. Should the packet flow be changed to this one? upper layer | ^ [ether_demux] ^ <--[bdg_forward]--<--+ | +---<---[ng_ether_rcvdata]--<-- 'upper' --<--, ^ \ | ng_tee | / +--->---[ng_ether_input]---->-- 'lower' -->--` ^ [ether_input] ^ | device Sincerely Yours, Jian-Wei Wang From owner-freebsd-net@FreeBSD.ORG Thu May 6 09:27:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0F3016A4CE; Thu, 6 May 2004 09:27:04 -0700 (PDT) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id C131243D1D; Thu, 6 May 2004 09:27:03 -0700 (PDT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.12.10/8.11.1) with ESMTP id i46GQp7D088671; Thu, 6 May 2004 18:26:52 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <4098D091.5020507@DeepCore.dk> References: <20040505104248.GM24376@darkness.comp.waw.pl> <20040505105034.GN24376@darkness.comp.waw.pl> <4098D091.5020507@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2DC58280-9F7A-11D8-A0EE-000A95C893E4@lassitu.de> Content-Transfer-Encoding: quoted-printable From: Stefan Bethke Date: Thu, 6 May 2004 18:26:51 +0200 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org X-Mailer: Apple Mail (2.613) cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 16:27:05 -0000 Am 05.05.2004 um 13:31 schrieb S=F8ren Schmidt: > Pawel Jakub Dawidek wrote: >> On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote: >> +> Hi. >> +> +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM=20 >> netperf test. >> +> While running netperf tests between two FreeBSD machines directly=20= >> connected >> +> em0 goes down once every few minutes and I've no idea why. >> +> Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it=20= >> also >> +> works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). > > For what its worth I have problems with one em based interface as=20 > well, it locks the machine solid when used: me too: FreeBSD 5.2-CURRENT #0: Tue Apr 13 18:50:30 GMT 2004 root@vergissnix:/usr/obj/usr/src/sys/VERGISSNIX em0: port=20 0xc000-0xc01f mem 0xf2000000-0xf201ffff irq 12 at device 1.0 on pci2 em0: Bus reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2000000 em0: Bus reserved 0x20 bytes for rid 0x18 type 4 at 0xc000 em0: [GIANT-LOCKED] em0: Ethernet address: 00:e0:81:27:b6:12 em0: Speed:N/A Duplex:N/A em1: port=20 0xd300-0xd33f mem 0xf1020000-0xf103ffff,0xf1000000-0xf101ffff irq 23 at device 2.0=20= on pci3 em1: Bus reserved 0x20000 bytes for rid 0x10 type 3 at 0xf1000000 em1: Bus reserved 0x40 bytes for rid 0x18 type 4 at 0xd300 em1: [GIANT-LOCKED] em1: Ethernet address: 00:e0:81:27:b6:13 em1: Speed:N/A Duplex:N/A em0@pci2:1:0: class=3D0x020000 card=3D0x10198086 chip=3D0x10198086 = rev=3D0x00=20 hdr=3D0x00 em1@pci3:2:0: class=3D0x020000 card=3D0x10138086 chip=3D0x10138086 = rev=3D0x00=20 hdr=3D0x00 # vmstat -ia irq12: em0 0 0 stray irq12 0 0 irq23: em1 3916723 3 stray irq23 0 0 em1 works; after bringing em0 up, machine locks solid after 2 to 5=20 minutes. --=20 Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Thu May 6 10:58:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 768B716A4D2; Thu, 6 May 2004 10:58:05 -0700 (PDT) Received: from mail.ticino.com (mx.ticino.com [195.190.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC8143D45; Thu, 6 May 2004 10:57:59 -0700 (PDT) (envelope-from roberto.nunnari@supsi.ch) Received: from supsi.ch (unverified [62.48.103.172]) by ticino.com (Rockliffe SMTPRA 6.0.6) with ESMTP id ; Thu, 6 May 2004 20:02:03 +0200 Message-ID: <409A7CA4.7080908@supsi.ch> Date: Thu, 06 May 2004 19:57:56 +0200 From: Roberto Nunnari User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Bethke References: <20040505104248.GM24376@darkness.comp.waw.pl> <20040505105034.GN24376@darkness.comp.waw.pl> <4098D091.5020507@DeepCore.dk> <2DC58280-9F7A-11D8-A0EE-000A95C893E4@lassitu.de> In-Reply-To: <2DC58280-9F7A-11D8-A0EE-000A95C893E4@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 17:58:05 -0000 I cannot boot the system with em0 after FreeBSD 5.2.1-RELEASE-p3.. it did work with 5.2-RELEASE-p1, though. See: http://www.freebsd.org/cgi/query-pr.cgi?pr=65282 One month is over since I submitted the pr, but nobody has looked at it yet. Stefan Bethke wrote: > > Am 05.05.2004 um 13:31 schrieb Søren Schmidt: > >> Pawel Jakub Dawidek wrote: >> >>> On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote: >>> +> Hi. >>> +> +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM >>> netperf test. >>> +> While running netperf tests between two FreeBSD machines directly >>> connected >>> +> em0 goes down once every few minutes and I've no idea why. >>> +> Without IPSEC everything works just fine, with IPSEC/FAST_IPSEC it >>> also >>> +> works fine but for other tests (UDP_STREAM, TCP_RR, UDP_RR). >> >> >> For what its worth I have problems with one em based interface as >> well, it locks the machine solid when used: > > > me too: > FreeBSD 5.2-CURRENT #0: Tue Apr 13 18:50:30 GMT 2004 > root@vergissnix:/usr/obj/usr/src/sys/VERGISSNIX > em0: port > 0xc000-0xc01f > mem 0xf2000000-0xf201ffff irq 12 at device 1.0 on pci2 > em0: Bus reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2000000 > em0: Bus reserved 0x20 bytes for rid 0x18 type 4 at 0xc000 > em0: [GIANT-LOCKED] > em0: Ethernet address: 00:e0:81:27:b6:12 > em0: Speed:N/A Duplex:N/A > em1: port > 0xd300-0xd33f > mem 0xf1020000-0xf103ffff,0xf1000000-0xf101ffff irq 23 at device 2.0 on > pci3 > em1: Bus reserved 0x20000 bytes for rid 0x10 type 3 at 0xf1000000 > em1: Bus reserved 0x40 bytes for rid 0x18 type 4 at 0xd300 > em1: [GIANT-LOCKED] > em1: Ethernet address: 00:e0:81:27:b6:13 > em1: Speed:N/A Duplex:N/A > > em0@pci2:1:0: class=0x020000 card=0x10198086 chip=0x10198086 rev=0x00 > hdr=0x00 > em1@pci3:2:0: class=0x020000 card=0x10138086 chip=0x10138086 rev=0x00 > hdr=0x00 > > # vmstat -ia > irq12: em0 0 0 > stray irq12 0 0 > irq23: em1 3916723 3 > stray irq23 0 0 > > em1 works; after bringing em0 up, machine locks solid after 2 to 5 minutes. > > -- Roberto Nunnari -software engineer- mailto:roberto.nunnari@supsi.ch Scuola Universitaria Professionale della Svizzera Italiana Dipartimento Tecnologie Innovative http://www.dti.supsi.ch SUPSI-DTI Via Cantonale tel: +41-91-6108561 6928 Manno """ fax: +41-91-6108570 Switzerland (o o) =======================oOO==(_)==OOo======================== From owner-freebsd-net@FreeBSD.ORG Thu May 6 11:00:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B0F916A4CE for ; Thu, 6 May 2004 11:00:07 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id F13F843D3F for ; Thu, 6 May 2004 11:00:06 -0700 (PDT) (envelope-from bmah@freebsd.org) Received: from [192.168.0.95] (dns.packetdesign.com [65.192.41.10]) (authenticated bits=0) by b.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i46I061J012131 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 May 2004 11:00:06 -0700 From: "Bruce A. Mah" To: Ahmed Hamada In-Reply-To: References: Content-Type: text/plain Message-Id: <1083866333.857.7.camel@localhost.kitchenlab.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 06 May 2004 10:58:54 -0700 Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Ask about AODV model in OPNET ????????? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 18:00:07 -0000 On Wed, 2004-05-05 at 13:16, Ahmed Hamada wrote: [lines wrapped for readability] > I am student in facaulty of engineering. My undergraduate project > is "Mobile Ad Hoc Network". I read alot about it and now I want > to make some simulations to verify some points. I want to use > the OPNET in my simulations so I download the academic edition 9.1 > (the free version) but I found it (the academic edition) doesn't > support the ad hoc protocols. "" The other editions support it"" . This has nothing to do with FreeBSD networking, you'll have to ask elsewhere. Bruce. From owner-freebsd-net@FreeBSD.ORG Thu May 6 11:40:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EA7D16A4CE; Thu, 6 May 2004 11:40:05 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3305743D49; Thu, 6 May 2004 11:40:04 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i46Idqmo043698; Thu, 6 May 2004 21:39:52 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <409A8675.3080102@he.iki.fi> Date: Thu, 06 May 2004 21:39:49 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <409938F7.2090603@DeepCore.dk> In-Reply-To: <409938F7.2090603@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 18:40:05 -0000 I´m highly confident that this is a case of integrated "CSA" ethernet with broken BIOS. I suspect you get an message about that when booting. Pete Søren Schmidt wrote: > John Polstra wrote: > >> On 05-May-2004 Søren Schmidt wrote: >> >>> For what its worth I have problems with one em based interface as >>> well, it locks the machine solid when used: >>> >>> em0: port >>> 0xb000-0xb01f mem 0xfb100000-0xfb11ffff irq 10 at device 1.0 on pci1 >>> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb100000 >>> em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xb000 >>> em0: [GIANT-LOCKED] >>> em0: Ethernet address: 00:30:48:80:9f:b6 >>> >>> where this one works just fine: >>> >>> em1: port >>> 0xa800-0xa83f mem 0xfa000000-0xfa01ffff irq 19 at device 10.0 on pci3 >>> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfa000000 >>> em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 >>> em1: [GIANT-LOCKED] >>> em1: Ethernet address: 00:30:48:80:9f:b7 >>> >>> >>> The chips are these >>> em0@pci1:1:0: class=0x020000 card=0x10758086 chip=0x10758086 >>> rev=0x00 hdr=0x00 >>> em1@pci3:10:0: class=0x020000 card=0x10768086 chip=0x10768086 >>> rev=0x00 hdr=0x00 >> >> >> >> Are either of the IRQs (10 and 19) shared with other devices? > > > Yes, the working one is shared with an (unused) USB port > From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:06:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2D4B16A4CE for ; Thu, 6 May 2004 12:06:22 -0700 (PDT) Received: from mail.redcorp.be (12.251-200-80.adsl-fix.skynet.be [80.200.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B181C43D3F for ; Thu, 6 May 2004 12:06:20 -0700 (PDT) (envelope-from "") Received: from mail.redcorp.be (localhost [127.0.0.1])i46I140l017876 for ; Thu, 6 May 2004 20:01:04 +0200 Received: (from root@localhost) by mail.redcorp.be (8.12.3/8.12.3/Submit) id i46I1420017875; Thu, 6 May 2004 20:01:04 +0200 Date: Thu, 6 May 2004 20:01:04 +0200 Message-Id: <200405061801.i46I1420017875@mail.redcorp.be> From: "Redcorp AntiSpammer" To: freebsd-net@freebsd.org X-MailScanner: generated, Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-275, required 3.5, AWL, SPAM_PHRASE_05_08, SUPERLONG_LINE, USER_IN_WHITELIST, WHITELISTSYS2, WHITELISTSYS4) Subject: Warning: Message not delivered! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:06:22 -0000 Our spam detector has just been triggered by a message you sent:- Subject: Re: excuse me Date: Thu May 6 20:01:04 2004 Version Français ci-dessous / Nederlandse text zie beneden Madam, Sir Due to the multitude of unsolicited emails, we are forced to use an 'anti-spam' system. This system marks email as spam by using several rules. You have sent us an email that has been marked as spam. Your email has not reached its recipient. Since this is an automated procedure, some real mails may be marked a spam. If this is the case for your mail, resend your mail with the word 'OK3045' added to the subject. Then your mail will reach its recipient. Thank you for your understanding. The Redcorp Team. ----------------------------------------------------------------------------------------------------------------------- Madame , Monsieur Suite à la multiplication des courriers non sollicités nous avons mis en place une politique 'anti-spam'. Cette politique nous a conduit à considérer comme spam les mails remplissant un certain nombres de critères. Vous nous avez envoyé un mail auquel le statut de spam a été attribué. Votre email n'a pas été reçu par son destinataire. La procédure étant automatique certains vrais mails pourraient avoir reçu le statut de spam, si tel était le cas de votre mail veuillez nous le renvoyer avec la mention 'OK3045' dans le sujet du mail. Votre mail atteindra alors son destinataire. Merci de votre compréhension. The Redcorp Team. ----------------------------------------------------------------------------------------------------------------------- Mevrouw, Mijnheer Tengevolge de grote hoeveelheid ongevraagde emails, zijn we gewongen een .anti-spam. systeem te gebruiken. Dit systeem markeert een email als spam aan de hand van een veelvoud aan regels. U heeft ons een email gezonden die als spam werd gemarkeerd. Uw mail heeft dus zijn bestemmeling niet bereikt. Aangezien dit een geautomatiseerd proces is, kunnen sommige echte mails als spam worden gemarkeerd. Indien dit het geval is voor uw mail, gelieve het ons te laten weten door uw mail opnieuw te sturen met 'OK3045' in het subject. Uw mail zal dan pas zijn bestemmeling bereiken. Dank u voor uw begrip. The Redcorp Team. From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:16:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 193DB16A4CE for ; Thu, 6 May 2004 12:16:07 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9354643D2D for ; Thu, 6 May 2004 12:16:05 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 75296 invoked from network); 6 May 2004 19:16:04 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 19:16:04 -0000 Message-ID: <409A8EF3.5825EF0C@freebsd.org> Date: Thu, 06 May 2004 21:16:03 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:16:07 -0000 I have just committed the attached change to ip_input() to control the behaviour of IP Options processing. The default is the unchanged current behaviour. However I want to propose to change the default from processing options to ignoring options (or even stronger to reject them). The rationale is as follows. IP Options do not have any legitimate use in todays Internet at all. For a long time now we have disabled source routing. The remaining IP Options are RR (record route) and TS (time stamp) which are both useless. For finding out which path a packet takes we use traceroute instead of RR. Besides that RR is limited to the space in the IP Options field and can possibly record only a few hops (9 IIRC). Time stamp is useless for the same reason and since it doesn't have a fixed and synchronized timebase it is even more so useless. Opinions? Discussion? Yes/Nay? -- Andre > andre 2004/05/06 11:46:03 PDT > > FreeBSD src repository > > Modified files: > sys/netinet ip_fastfwd.c ip_input.c ip_var.h > Log: > Provide the sysctl net.inet.ip.process_options to control the processing > of IP options. > > net.inet.ip.process_options=0 Ignore IP options and pass packets unmodified. > net.inet.ip.process_options=1 Process all IP options (default). > net.inet.ip.process_options=2 Reject all packets with IP options with ICMP > filter prohibited message. > > This sysctl affects packets destined for the local host as well as those > only transiting through the host (routing). > > IP options do not have any legitimate purpose anymore and are only used > to circumvent firewalls or to exploit certain behaviours or bugs in TCP/IP > stacks. > > Reviewed by: sam (mentor) > > Revision Changes Path > 1.11 +10 -2 src/sys/netinet/ip_fastfwd.c > 1.271 +13 -0 src/sys/netinet/ip_input.c > 1.87 +1 -0 src/sys/netinet/ip_var.h From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:22:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6AF016A4DD; Thu, 6 May 2004 12:22:10 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08EAB43D31; Thu, 6 May 2004 12:22:10 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 97F0C54840; Thu, 6 May 2004 14:22:09 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 3DAD66FF36; Thu, 6 May 2004 14:22:09 -0500 (CDT) Date: Thu, 6 May 2004 14:22:09 -0500 From: "Jacques A. Vidrine" To: Andre Oppermann Message-ID: <20040506192209.GC1939@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:22:10 -0000 On Thu, May 06, 2004 at 09:16:03PM +0200, Andre Oppermann wrote: > I have just committed the attached change to ip_input() to control the > behaviour of IP Options processing. The default is the unchanged > current behaviour. > > However I want to propose to change the default from processing options > to ignoring options (or even stronger to reject them). > > The rationale is as follows. IP Options do not have any legitimate use > in todays Internet at all. For a long time now we have disabled source > routing. The remaining IP Options are RR (record route) and TS (time > stamp) which are both useless. For finding out which path a packet takes > we use traceroute instead of RR. Besides that RR is limited to the space > in the IP Options field and can possibly record only a few hops (9 IIRC). > Time stamp is useless for the same reason and since it doesn't have a > fixed and synchronized timebase it is even more so useless. > > Opinions? Discussion? Yes/Nay? Maybe you've already seen my reply to your commit, but: I would very much like to see the default be 1-ignore or 2-reject, preferably the latter. I believe your analysis is correct. I haven't been able to use record route for anything useful since around 1996--- this partially because networks became larger and partly because many systems started dropping packets with options :-) Timestamp is also somewhat esoteric. But the point is that enabling these options should require a concious decision by users. Those who want them can turn them on ... most users probably don't know these options even exist, and for them I think it is better to have them default off. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:22:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CBBA16A504; Thu, 6 May 2004 12:22:31 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC1A43D2D; Thu, 6 May 2004 12:22:31 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004050619223001400jti7ce>; Thu, 6 May 2004 19:22:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA83570; Thu, 6 May 2004 12:22:30 -0700 (PDT) Date: Thu, 6 May 2004 12:22:28 -0700 (PDT) From: Julian Elischer To: Andre Oppermann In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:22:31 -0000 On Thu, 6 May 2004, Andre Oppermann wrote: > I have just committed the attached change to ip_input() to control the > behaviour of IP Options processing. The default is the unchanged > current behaviour. [...] > routing. The remaining IP Options are RR (record route) and TS (time > stamp) which are both useless. For finding out which path a packet takes > we use traceroute instead of RR. Besides that RR is limited to the space > in the IP Options field and can possibly record only a few hops (9 IIRC). > Time stamp is useless for the same reason and since it doesn't have a > fixed and synchronized timebase it is even more so useless. > > Opinions? Discussion? Yes/Nay? I use RR all the time. it allows you to record the reverse path, (up to the size limitation). what about inet6 ? do you plan on doing things there? There are more options defined there.. From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:29:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7815916A4CE; Thu, 6 May 2004 12:29:28 -0700 (PDT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08FF543D46; Thu, 6 May 2004 12:29:28 -0700 (PDT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) i46JTRb0007102; Thu, 6 May 2004 12:29:27 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.11/8.12.11/Submit) id i46JTRgi007101; Thu, 6 May 2004 12:29:27 -0700 (PDT) (envelope-from david) Date: Thu, 6 May 2004 12:29:27 -0700 (PDT) From: David Wolfskill Message-Id: <200405061929.i46JTRgi007101@bunrab.catwhisker.org> To: freebsd-current@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:29:28 -0000 >Date: Thu, 06 May 2004 21:16:03 +0200 >From: Andre Oppermann >To: freebsd-current@freebsd.org, freebsd-net@freebsd.org >Subject: Default behaviour of IP Options processing >Sender: owner-freebsd-current@freebsd.org >However I want to propose to change the default from processing options >to ignoring options (or even stronger to reject them). >.... >Opinions? Discussion? Yes/Nay? >From "ipfw show" on my home gateway/NAT/packet fileter box: ... 02000 0 0 deny log ip from any to any ipopt rr 02010 0 0 deny log ip from any to any ipopt ts 02020 0 0 deny log ip from any to any ipopt ssrr 02030 0 0 deny log ip from any to any ipopt lsrr I implemented those rules back around August, 1999, when I first set the box up; I don't recall that they have ever been triggered. (Uptime on the box is nowhere near 4+ years, as it's been tracking -STABLE about every couple of weeks: janus# uname -a FreeBSD janus.catwhisker.org 4.10-PRERELEASE FreeBSD 4.10-PRERELEASE #66: Sun May 2 06:05:10 PDT 2004 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/JANUS i386 janus# So the counters from "show ipfw" only show traffic since janus# uptime 12:27PM up 4 days, 5:53, 1 user, load averages: 0.04, 0.03, 0.06 janus# -- not really enough to be significant.) My point was that there are some of us who, quite deliberately, decline to accept options-laden traffic anyhow. So I have no known reason to object to the proposal. Peace, david -- David H. Wolfskill david@catwhisker.org I do not "unsubscribe" from email "services" to which I have not explicitly subscribed. Rather, I block spammers' access to SMTP servers I control, and encourage others who are in a position to do so to do likewise. From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:33:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6A6F16A4CE; Thu, 6 May 2004 12:33:24 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68F1743D41; Thu, 6 May 2004 12:33:23 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i46JXEUj063771; Thu, 6 May 2004 21:33:19 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <409A92FA.6080104@DeepCore.dk> Date: Thu, 06 May 2004 21:33:14 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Helenius References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> In-Reply-To: <409A8675.3080102@he.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:33:24 -0000 Petri Helenius wrote: > I´m highly confident that this is a case of integrated "CSA" ethernet > with broken BIOS. I suspect you get an message about that when booting. Nope. no messages to that effect, oh and it works in windows(tm)... The last thing I see if I try to use em0 is: em0: Link is up 100 Mbps Full Duplex and then the system locks up hard. > Søren Schmidt wrote: > >> John Polstra wrote: >> >>> On 05-May-2004 Søren Schmidt wrote: >>> >>>> For what its worth I have problems with one em based interface as >>>> well, it locks the machine solid when used: >>>> >>>> em0: port >>>> 0xb000-0xb01f mem 0xfb100000-0xfb11ffff irq 10 at device 1.0 on pci1 >>>> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfb100000 >>>> em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xb000 >>>> em0: [GIANT-LOCKED] >>>> em0: Ethernet address: 00:30:48:80:9f:b6 >>>> >>>> where this one works just fine: >>>> >>>> em1: port >>>> 0xa800-0xa83f mem 0xfa000000-0xfa01ffff irq 19 at device 10.0 on pci3 >>>> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfa000000 >>>> em1: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 >>>> em1: [GIANT-LOCKED] >>>> em1: Ethernet address: 00:30:48:80:9f:b7 >>>> >>>> >>>> The chips are these >>>> em0@pci1:1:0: class=0x020000 card=0x10758086 chip=0x10758086 >>>> rev=0x00 hdr=0x00 >>>> em1@pci3:10:0: class=0x020000 card=0x10768086 chip=0x10768086 >>>> rev=0x00 hdr=0x00 >>> >>> >>> >>> >>> Are either of the IRQs (10 and 19) shared with other devices? >> >> >> >> Yes, the working one is shared with an (unused) USB port >> > > > . > -- -Søren From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:35:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DAA116A4D0 for ; Thu, 6 May 2004 12:35:44 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6034A43D58 for ; Thu, 6 May 2004 12:35:43 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 76739 invoked from network); 6 May 2004 19:35:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 19:35:42 -0000 Message-ID: <409A938D.AAEF25C@freebsd.org> Date: Thu, 06 May 2004 21:35:41 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Wolfskill References: <200405061929.i46JTRgi007101@bunrab.catwhisker.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:35:44 -0000 David Wolfskill wrote: > >However I want to propose to change the default from processing options > >to ignoring options (or even stronger to reject them). > > >.... > > >Opinions? Discussion? Yes/Nay? > > >From "ipfw show" on my home gateway/NAT/packet fileter box: > > ... > 02000 0 0 deny log ip from any to any ipopt rr > 02010 0 0 deny log ip from any to any ipopt ts > 02020 0 0 deny log ip from any to any ipopt ssrr > 02030 0 0 deny log ip from any to any ipopt lsrr > > I implemented those rules back around August, 1999, when I first set the > box up; I don't recall that they have ever been triggered. (Uptime on > the box is nowhere near 4+ years, as it's been tracking -STABLE about > every couple of weeks: I have done the same counters on my ISPs core routers with about 40Mbit/s of junky unfiltered public Internet traffic for many hours now. No hits so far. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:39:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C8E216A4CE for ; Thu, 6 May 2004 12:39:07 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7388843D49 for ; Thu, 6 May 2004 12:39:06 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 77016 invoked from network); 6 May 2004 19:39:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 19:39:05 -0000 Message-ID: <409A9458.D73EBB18@freebsd.org> Date: Thu, 06 May 2004 21:39:04 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?S=F8ren?= Schmidt References: <409A92FA.6080104@DeepCore.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:39:07 -0000 Søren Schmidt wrote: > > Petri Helenius wrote: > > I´m highly confident that this is a case of integrated "CSA" ethernet > > with broken BIOS. I suspect you get an message about that when booting. > > Nope. no messages to that effect, oh and it works in windows(tm)... > > The last thing I see if I try to use em0 is: > em0: Link is up 100 Mbps Full Duplex > and then the system locks up hard. What MIIPHY does the card have? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:47:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF5FD16A4CF for ; Thu, 6 May 2004 12:47:28 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC2FC43D2F for ; Thu, 6 May 2004 12:47:27 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 77458 invoked from network); 6 May 2004 19:47:27 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 19:47:27 -0000 Message-ID: <409A964E.2FE5F40E@freebsd.org> Date: Thu, 06 May 2004 21:47:26 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:47:29 -0000 Julian Elischer wrote: > > On Thu, 6 May 2004, Andre Oppermann wrote: > > > I have just committed the attached change to ip_input() to control the > > behaviour of IP Options processing. The default is the unchanged > > current behaviour. > [...] > > routing. The remaining IP Options are RR (record route) and TS (time > > stamp) which are both useless. For finding out which path a packet takes > > we use traceroute instead of RR. Besides that RR is limited to the space > > in the IP Options field and can possibly record only a few hops (9 IIRC). > > Time stamp is useless for the same reason and since it doesn't have a > > fixed and synchronized timebase it is even more so useless. > > > > Opinions? Discussion? Yes/Nay? > > I use RR all the time. > it allows you to record the reverse path, (up to the size limitation). Which won't get you far these days... ;-) > what about inet6 ? do you plan on doing things there? > There are more options defined there.. As far as I am aware IPv6 packets do not have any option space in the packet header. You have header stacking there though which has its own evil implications... -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:50:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52A8416A4CF; Thu, 6 May 2004 12:50:08 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C32843D1D; Thu, 6 May 2004 12:50:07 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i46Jnx1g063916; Thu, 6 May 2004 21:50:04 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <409A96E7.7020601@DeepCore.dk> Date: Thu, 06 May 2004 21:49:59 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> <409A9458.D73EBB18@freebsd.org> In-Reply-To: <409A9458.D73EBB18@freebsd.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:50:08 -0000 Andre Oppermann wrote: > Søren Schmidt wrote: > >>Petri Helenius wrote: >> >>>I´m highly confident that this is a case of integrated "CSA" ethernet >>>with broken BIOS. I suspect you get an message about that when booting. >> >>Nope. no messages to that effect, oh and it works in windows(tm)... >> >>The last thing I see if I try to use em0 is: >>em0: Link is up 100 Mbps Full Duplex >>and then the system locks up hard. > > What MIIPHY does the card have? No idea, builtin of sorts, there is no mention of it in the probe, and no HW to see on the boards. I have two different boards with these on them both show the problem... -- -Søren From owner-freebsd-net@FreeBSD.ORG Thu May 6 12:59:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2416316A4CF for ; Thu, 6 May 2004 12:59:53 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266AB43D53 for ; Thu, 6 May 2004 12:59:52 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 78098 invoked from network); 6 May 2004 19:59:51 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 19:59:51 -0000 Message-ID: <409A9936.78CC31A0@freebsd.org> Date: Thu, 06 May 2004 21:59:50 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?S=F8ren?= Schmidt References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> <409A9458.D73EBB18@freebsd.org> <409A96E7.7020601@DeepCore.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:59:53 -0000 Søren Schmidt wrote: > > Andre Oppermann wrote: > > Søren Schmidt wrote: > > > >>Petri Helenius wrote: > >> > >>>I´m highly confident that this is a case of integrated "CSA" ethernet > >>>with broken BIOS. I suspect you get an message about that when booting. > >> > >>Nope. no messages to that effect, oh and it works in windows(tm)... > >> > >>The last thing I see if I try to use em0 is: > >>em0: Link is up 100 Mbps Full Duplex > >>and then the system locks up hard. > > > > What MIIPHY does the card have? > > No idea, builtin of sorts, there is no mention of it in the probe, and > no HW to see on the boards. I have two different boards with these on > them both show the problem... There must be some sort of MII message in dmesg. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 13:07:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8335616A4CF; Thu, 6 May 2004 13:07:14 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC3143D49; Thu, 6 May 2004 13:07:14 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) by pooker.samsco.org (8.12.10/8.12.10) with ESMTP id i46KBIu6034699; Thu, 6 May 2004 14:11:19 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <409A9ACC.4080107@freebsd.org> Date: Thu, 06 May 2004 14:06:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> In-Reply-To: <409A92FA.6080104@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 20:07:14 -0000 Søren Schmidt wrote: > Petri Helenius wrote: > >> I´m highly confident that this is a case of integrated "CSA" ethernet >> with broken BIOS. I suspect you get an message about that when booting. > > > Nope. no messages to that effect, oh and it works in windows(tm)... > > The last thing I see if I try to use em0 is: > em0: Link is up 100 Mbps Full Duplex > and then the system locks up hard. > Have you tried turning off ACPI? Scott From owner-freebsd-net@FreeBSD.ORG Thu May 6 13:16:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B98EF16A4CE; Thu, 6 May 2004 13:16:17 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9582443D39; Thu, 6 May 2004 13:16:16 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i46KG2mo043976; Thu, 6 May 2004 23:16:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <409A9CFF.6080407@he.iki.fi> Date: Thu, 06 May 2004 23:15:59 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> In-Reply-To: <409A92FA.6080104@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 20:16:17 -0000 Søren Schmidt wrote: > > Nope. no messages to that effect, oh and it works in windows(tm)... > > The last thing I see if I try to use em0 is: > em0: Link is up 100 Mbps Full Duplex > and then the system locks up hard. > > Would you mind posting full dmesg output? Pete From owner-freebsd-net@FreeBSD.ORG Thu May 6 13:23:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5BD816A4CE for ; Thu, 6 May 2004 13:23:22 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C793543D2F for ; Thu, 6 May 2004 13:23:21 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 79334 invoked from network); 6 May 2004 20:23:21 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 6 May 2004 20:23:21 -0000 Message-ID: <409A9EB7.D0D2AC4A@freebsd.org> Date: Thu, 06 May 2004 22:23:19 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?S=F8ren?= Schmidt , freebsd-net@freebsd.org, freebsd-current@freebsd.org, John Polstra References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> <409A9458.D73EBB18@freebsd.org> <409A96E7.7020601@DeepCore.dk> <409A9936.78CC31A0@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 20:23:23 -0000 Andre Oppermann wrote: > > Søren Schmidt wrote: > > > > Andre Oppermann wrote: > > > Søren Schmidt wrote: > > > > > >>Petri Helenius wrote: > > >> > > >>>I´m highly confident that this is a case of integrated "CSA" ethernet > > >>>with broken BIOS. I suspect you get an message about that when booting. > > >> > > >>Nope. no messages to that effect, oh and it works in windows(tm)... > > >> > > >>The last thing I see if I try to use em0 is: > > >>em0: Link is up 100 Mbps Full Duplex > > >>and then the system locks up hard. > > > > > > What MIIPHY does the card have? > > > > No idea, builtin of sorts, there is no mention of it in the probe, and > > no HW to see on the boards. I have two different boards with these on > > them both show the problem... > > There must be some sort of MII message in dmesg. I'm wrong. em uses built in PHYs indeed. Which also means link_state doesn't work there... Check out the function em_local_timer() in sys/dev/em/if_em.c and maybe you get some more insight by enabling if debugging or putting some printf's in there. What makes me a little bit wondering is the direct use of printf() instead of dev_printf(). I don't know what the locking implications are if any. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 13:28:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A74316A4CE; Thu, 6 May 2004 13:28:47 -0700 (PDT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDE8943D54; Thu, 6 May 2004 13:28:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.12.11/8.12.11) with ESMTP id i46KSiBU015763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 May 2004 13:28:44 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.11/8.12.11/Submit) id i46KSiIk076688; Thu, 6 May 2004 13:28:44 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <409A9936.78CC31A0@freebsd.org> Date: Thu, 06 May 2004 13:28:44 -0700 (PDT) From: John Polstra To: Andre Oppermann X-Bogosity: No, tests=bogofilter, spamicity=0.001372, version=0.14.5 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 20:28:47 -0000 On 06-May-2004 Andre Oppermann wrote: > Søren Schmidt wrote: >> >> Andre Oppermann wrote: >> > What MIIPHY does the card have? >> >> No idea, builtin of sorts, there is no mention of it in the probe, and >> no HW to see on the boards. I have two different boards with these on >> them both show the problem... > > There must be some sort of MII message in dmesg. No, the em driver does not use the FreeBSD MII code. The PHY driver is built into the em driver. John From owner-freebsd-net@FreeBSD.ORG Thu May 6 13:48:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B743816A4CE; Thu, 6 May 2004 13:48:04 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2486543D41; Thu, 6 May 2004 13:47:59 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) by pooker.samsco.org (8.12.10/8.12.10) with ESMTP id i46Kpnu6034902; Thu, 6 May 2004 14:52:00 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <409AA44B.9010404@freebsd.org> Date: Thu, 06 May 2004 14:47:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> In-Reply-To: <409A92FA.6080104@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 20:48:04 -0000 Søren Schmidt wrote: > Petri Helenius wrote: > >> I´m highly confident that this is a case of integrated "CSA" ethernet >> with broken BIOS. I suspect you get an message about that when booting. > > > Nope. no messages to that effect, oh and it works in windows(tm)... > > The last thing I see if I try to use em0 is: > em0: Link is up 100 Mbps Full Duplex > and then the system locks up hard. > I'm looking a t a similar system right now and it definitely looks like an interrupt routing problem, not a driver problem. The interesting thing is that (with 5.2-current as of two days ago) disabling neither ACPI nor APIC helps. I guess that we might want to get John Baldwin involved. Scott From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:29:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 404E916A4D0; Thu, 6 May 2004 15:29:12 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2017E43D49; Thu, 6 May 2004 15:29:10 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from mp3 (x4neikl8@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i46MT8u513534973; Fri, 7 May 2004 02:29:08 +0400 (MSD) Date: Fri, 7 May 2004 02:29:08 +0400 (MSD) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> Message-ID: <20040507020422.D94207@mp3files.int.ru> References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:29:12 -0000 On Thu, 6 May 2004, 21:16+0200, Andre Oppermann wrote: > I have just committed the attached change to ip_input() to control the > behaviour of IP Options processing. The default is the unchanged > current behaviour. > > However I want to propose to change the default from processing options > to ignoring options (or even stronger to reject them). > > The rationale is as follows. IP Options do not have any legitimate use > in todays Internet at all. For a long time now we have disabled source > routing. The remaining IP Options are RR (record route) and TS (time > stamp) which are both useless. For finding out which path a packet takes > we use traceroute instead of RR. Besides that RR is limited to the space > in the IP Options field and can possibly record only a few hops (9 IIRC). > Time stamp is useless for the same reason and since it doesn't have a > fixed and synchronized timebase it is even more so useless. > > Opinions? Discussion? Yes/Nay? We are using RR option all the time to track down routing asymmetry and traceroute is not an option, ping -R is very useful in that cases. We all know that ipfw (and I am sure all other *pf*) is able to process ip opts quite well and personally see no point in this sysctls. I fail to see a documentation update (inet.4 ?) as well. It is not clear for me why you ever ask for opinions after commit not before. Strick "nay" if you care :-) -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:35:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7379916A4CF; Thu, 6 May 2004 15:35:56 -0700 (PDT) Received: from leviathan.inethouston.com (leviathan.inethouston.com [209.198.171.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA52443D64; Thu, 6 May 2004 15:35:55 -0700 (PDT) (envelope-from dwcjr@inethouston.net) Received: by leviathan.inethouston.com (Postfix, from userid 1001) id 28B4B2C910E; Thu, 6 May 2004 17:35:45 -0500 (CDT) Date: Thu, 6 May 2004 17:35:45 -0500 From: "David W. Chapman Jr." To: Maxim Konovalov Message-ID: <20040506223545.GA61873@minubian.inethouston.net> Mail-Followup-To: Maxim Konovalov , Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> <20040507020422.D94207@mp3files.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040507020422.D94207@mp3files.int.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.2.1-RELEASE-p5 i386 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "David W. Chapman Jr." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:35:56 -0000 > We are using RR option all the time to track down routing asymmetry > and traceroute is not an option, ping -R is very useful in that cases. > We all know that ipfw (and I am sure all other *pf*) is able to > process ip opts quite well and personally see no point in this > sysctls. I fail to see a documentation update (inet.4 ?) as well. > > It is not clear for me why you ever ask for opinions after commit not > before. Strick "nay" if you care :-) He hasn't changed the default yet. But I think for the select few who actually use such tcp options, they can enable it. Most of the users however will not need this. I think the point that is trying to be made is that they want the default installation to be more secure and those who need these features can simply turn them on. -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:42:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C27E16A4CF; Thu, 6 May 2004 15:42:47 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B578143D49; Thu, 6 May 2004 15:42:46 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <20040506224245015007ndl1e>; Thu, 6 May 2004 22:42:46 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA85900; Thu, 6 May 2004 15:42:44 -0700 (PDT) Date: Thu, 6 May 2004 15:42:43 -0700 (PDT) From: Julian Elischer To: "David W. Chapman Jr." In-Reply-To: <20040506223545.GA61873@minubian.inethouston.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:42:47 -0000 On Thu, 6 May 2004, David W. Chapman Jr. wrote: > > We are using RR option all the time to track down routing asymmetry > > and traceroute is not an option, ping -R is very useful in that cases. > > We all know that ipfw (and I am sure all other *pf*) is able to > > process ip opts quite well and personally see no point in this > > sysctls. I fail to see a documentation update (inet.4 ?) as well. > > > > It is not clear for me why you ever ask for opinions after commit not > > before. Strick "nay" if you care :-) > > He hasn't changed the default yet. But I think for the select few > who actually use such tcp options, they can enable it. Most of the > users however will not need this. I think the point that is trying > to be made is that they want the default installation to be more > secure and those who need these features can simply turn them on. what security problem are you expecting? > > -- > David W. Chapman Jr. > dwcjr@inethouston.net Raintree Network Services, Inc. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:50:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72F9116A4CE; Thu, 6 May 2004 15:50:03 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9477843D31; Thu, 6 May 2004 15:50:02 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from mp3 (y86xlgh7@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i46Mnwu513359038; Fri, 7 May 2004 02:49:58 +0400 (MSD) Date: Fri, 7 May 2004 02:49:58 +0400 (MSD) From: Maxim Konovalov To: "David W. Chapman Jr." In-Reply-To: <20040506223545.GA61873@minubian.inethouston.net> Message-ID: <20040507023844.B96754@mp3files.int.ru> References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> <20040507020422.D94207@mp3files.int.ru> <20040506223545.GA61873@minubian.inethouston.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:50:03 -0000 On Thu, 6 May 2004, 17:35-0500, David W. Chapman Jr. wrote: > > We are using RR option all the time to track down routing asymmetry > > and traceroute is not an option, ping -R is very useful in that cases. > > We all know that ipfw (and I am sure all other *pf*) is able to > > process ip opts quite well and personally see no point in this > > sysctls. I fail to see a documentation update (inet.4 ?) as well. > > > > It is not clear for me why you ever ask for opinions after commit not > > before. Strick "nay" if you care :-) > > He hasn't changed the default yet. But I think for the select few > who actually use such tcp options, they can enable it. Most of the You mean ip options not tcp, right? I do not understant why we invent a new mechanism if we already have one. Put an example in /etc/rc.firewall. > users however will not need this. I think the point that is trying > to be made is that they want the default installation to be more > secure and those who need these features can simply turn them on. You mean "more obscure", right? Where net.inet.ip.process_options documented? How does it operate with f.e. IPSTEALTH? -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:52:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55BFD16A4CE; Thu, 6 May 2004 15:52:02 -0700 (PDT) Received: from leviathan.inethouston.com (leviathan.inethouston.com [209.198.171.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CB1743D39; Thu, 6 May 2004 15:52:02 -0700 (PDT) (envelope-from dwcjr@inethouston.net) Received: by leviathan.inethouston.com (Postfix, from userid 1001) id 59A272C9112; Thu, 6 May 2004 17:51:51 -0500 (CDT) Date: Thu, 6 May 2004 17:51:51 -0500 From: "David W. Chapman Jr." To: Julian Elischer Message-ID: <20040506225151.GA62194@minubian.inethouston.net> Mail-Followup-To: Julian Elischer , "David W. Chapman Jr." , Maxim Konovalov , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann References: <20040506223545.GA61873@minubian.inethouston.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.2.1-RELEASE-p5 i386 cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "David W. Chapman Jr." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:52:02 -0000 On Thu, May 06, 2004 at 03:42:43PM -0700, Julian Elischer wrote: > > what security problem are you expecting? > I personally am not expecting any problems because I'm not in a knowledgeable enough to state my opinion on such matters, but it seems Mr. Vidrine and Mr. Oppermann were in the opinion that it could be a security problem and everyone seems to be ignoring that and that the few people who actually do need these options should be able to turn them on. -- David W. Chapman Jr. dwcjr@inethouston.net Raintree Network Services, Inc. From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:55:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FD3016A4CE; Thu, 6 May 2004 15:55:12 -0700 (PDT) Received: from leviathan.inethouston.com (leviathan.inethouston.com [209.198.171.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F32743D1D; Thu, 6 May 2004 15:55:12 -0700 (PDT) (envelope-from dwcjr@inethouston.net) Received: from dwcjr (unknown [192.168.1.253]) by leviathan.inethouston.com (Postfix) with SMTP id 61D7C2C908C; Thu, 6 May 2004 17:55:01 -0500 (CDT) Message-ID: <04f001c433bd$cdc100f0$fd01a8c0@dwcjr> From: "David W. Chapman Jr." To: "Maxim Konovalov" References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> <20040507020422.D94207@mp3files.int.ru> <20040506223545.GA61873@minubian.inethouston.net> <20040507023844.B96754@mp3files.int.ru> Date: Thu, 6 May 2004 17:59:36 -0500 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 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:55:12 -0000 > You mean ip options not tcp, right? I do not understant why we > invent a new mechanism if we already have one. Put an example in > /etc/rc.firewall. Yes, I stand corrected, ip option it is :) > You mean "more obscure", right? Where net.inet.ip.process_options > documented? How does it operate with f.e. IPSTEALTH? I definitely agree it should be documented, but that's just a minor detail which can be easily taken care of. From owner-freebsd-net@FreeBSD.ORG Thu May 6 16:06:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D25516A4CE; Thu, 6 May 2004 16:06:22 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBCAD43D53; Thu, 6 May 2004 16:06:21 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004050623062001400k35d8e>; Thu, 6 May 2004 23:06:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA86227; Thu, 6 May 2004 16:06:20 -0700 (PDT) Date: Thu, 6 May 2004 16:06:19 -0700 (PDT) From: Julian Elischer To: "David W. Chapman Jr." In-Reply-To: <04f001c433bd$cdc100f0$fd01a8c0@dwcjr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 23:06:22 -0000 On Thu, 6 May 2004, David W. Chapman Jr. wrote: > > You mean ip options not tcp, right? I do not understant why we > > invent a new mechanism if we already have one. Put an example in > > /etc/rc.firewall. > > Yes, I stand corrected, ip option it is :) > > > You mean "more obscure", right? Where net.inet.ip.process_options > > documented? How does it operate with f.e. IPSTEALTH? > > I definitely agree it should be documented, but that's just a minor detail > which can be easily taken care of. I know these are "options" but what does the standards say about not supporting them.. ? (I have seen non optional options before :-) also I dislike the all-or-nothing mechanism I would rather see: net.inet.ip.options.RR: 1 net.inet.ip.options.TS: 0 net.inet.ip.options.SECURITY 0 net.inet.ip.options.LSRR: 0 net.inet.ip.options.SATID: 0 net.inet.ip.options.SSRR: 0 net.inet.ip.options.RA: 0 where options we DON'T support exist and are stuck at 0. or maybe even: net.inet.ip.options.RecordRoute: 1 net.inet.ip.options.TimeStamp: 0 etc. if they are usually turned off then the test would only be done if that option exists and it would still be faster that actually doing the option. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 6 16:51:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CAF16A4CE for ; Thu, 6 May 2004 16:51:27 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id A647F43D1D for ; Thu, 6 May 2004 16:51:24 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004050623512201600t1ob3e>; Thu, 6 May 2004 23:51:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA86634; Thu, 6 May 2004 16:51:22 -0700 (PDT) Date: Thu, 6 May 2004 16:51:21 -0700 (PDT) From: Julian Elischer To: Julian Stecklina In-Reply-To: <86oep2spk7.fsf@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 23:51:27 -0000 My comments in [] below.. On Wed, 5 May 2004, Julian Stecklina wrote: > Hello, > > I have a problem with pppoed: It does not accept connections: > > My system is FreeBSD-current as of some days ago running on x86. ath0 > is a DLINK WLAN card, if that matters. If I watch ethernet traffic via > tcpdump, I see the connection attempt from the client but no answer > from pppoed. Anyone knows whats going on? > > jmmr# /usr/libexec/pppoed -Fd -n 5 -p "*" ath0 [find our name/ID] > pppoed: SENDING MESSAGE: > pppoed: SOCKADDR: { fam=32 len=4 addr="." } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 0 > pppoed: flags 0 > pppoed: token 1 > pppoed: cookie GENERIC (977674408) > pppoed: cmd 268435462 > pppoed: args (0 bytes) > pppoed: RECEIVED RESPONSE: > pppoed: SOCKADDR: { fam=32 len=8 addr="[39]:" } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 72 > pppoed: flags 1 > pppoed: token 1 > pppoed: cookie GENERIC (977674408) > pppoed: cmd nodeinfo (268435462) > pppoed: args { type="socket" id=0x39 } [See if there is already a PPPOE node on the ether net..] > Sending NGM_LISTHOOKS to ath0: > pppoed: SENDING MESSAGE: > pppoed: SOCKADDR: { fam=32 len=8 addr="ath0:" } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 0 > pppoed: flags 0 > pppoed: token 3 > pppoed: cookie GENERIC (977674408) > pppoed: cmd listhooks (268435463) > pppoed: args > pppoed: RECEIVED RESPONSE: > pppoed: SOCKADDR: { fam=32 len=7 addr="[1]:" } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 208 > pppoed: flags 1 > pppoed: token 3 > pppoed: cookie GENERIC (977674408) > pppoed: cmd listhooks (268435463) > pppoed: args { nodeinfo={ name="ath0" type="ether" id=0x1 hooks=1 } linkinfo=[ { ourhook="orphans" peerhook="ethernet" nodeinfo={ type="pppoe" id=0x4 hooks=1 } } ] } [yes there is.. use it] [Attach us to the pppoe node] > Got reply from id [1]: Type ether with 1 hooks > Got [1]:orphans -> [4]:ethernet > pppoed: SENDING MESSAGE: > pppoed: SOCKADDR: { fam=32 len=5 addr=".:" } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 576 > pppoed: flags 0 > pppoed: token 6 > pppoed: cookie GENERIC (977674408) > pppoed: cmd connect (3) > pppoed: args { path="ath0:orphans" ourhook="pppoe-52307" peerhook="pppoe-52307" } [I suspect that the above may have failed.. doing 'ngctl list', 'ngctl show ath0:orphans' and 'ngctl show .:' would be constructive..] > Sending PPPOE_LISTEN to .:pppoe-52307, provider pppoe > pppoed: SENDING MESSAGE: > pppoed: SOCKADDR: { fam=32 len=16 addr=".:pppoe-52307" } > pppoed: NG_MESG : > pppoed: vers 6 > pppoed: arglen 39 > pppoed: flags 0 > pppoed: token 8 > pppoed: cookie PPPOE (939032003) > pppoed: sendto(.:pppoe-52307): No such file or directory > pppoed: [error decoding message: No such file or directory] > pppoed: cmd 3 > pppoed: args (39 bytes) > pppoed: 0000: 70 70 70 6f 65 2d 35 32 33 30 37 00 2b 92 04 08 pppoe-52307.+... > pppoed: 0010: 03 00 00 00 22 ab 04 08 a8 20 46 3a 03 00 00 00 ....".... F:.... > pppoed: 0020: 05 00 70 70 70 6f 65 ..pppoe > pppoed[52307]: Listening as provider pppoe > > [pppoed is running, but I cannot find it via RASPPPOE from Windoze] > > The error message looks suspicious > A search in the mailing lists showed someone with a similar problem a > year ago, but his question was not answered on the list: > Are the kernel and pppoed compiled at the same time from the same sources? (/usr/include/netgraph/) > http://lists.freebsd.org/pipermail/freebsd-stable/2003-July/002115.html > > Please keep me in CC, as I am not subscribed to this group. > > Regards, > -- > Julian Stecklina > > Signed and encrypted mail welcome. > Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 > FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 > > Any sufficiently complicated C or Fortran program > contains an ad hoc informally-specified bug-ridden > slow implementation of half of Common Lisp. > - Greenspun's Tenth Rule of Programming > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 6 16:54:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FBAE16A4CE; Thu, 6 May 2004 16:54:46 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B45C43D1D; Thu, 6 May 2004 16:54:46 -0700 (PDT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i46NsWWR001140 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 6 May 2004 16:54:32 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Thu, 6 May 2004 16:53:36 -0700 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405061653.36981.sam@errno.com> cc: "David W. Chapman Jr." cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: Julian Elischer Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 23:54:46 -0000 On Thursday 06 May 2004 04:06 pm, Julian Elischer wrote: > On Thu, 6 May 2004, David W. Chapman Jr. wrote: > > > You mean ip options not tcp, right? I do not understant why we > > > invent a new mechanism if we already have one. Put an example in > > > /etc/rc.firewall. > > > > Yes, I stand corrected, ip option it is :) > > > > > You mean "more obscure", right? Where net.inet.ip.process_options > > > documented? How does it operate with f.e. IPSTEALTH? > > > > I definitely agree it should be documented, but that's just a minor > > detail which can be easily taken care of. > > I know these are "options" but what does the standards say about not > supporting them.. ? (I have seen non optional options before :-) > > also I dislike the all-or-nothing mechanism > I would rather see: > net.inet.ip.options.RR: 1 > net.inet.ip.options.TS: 0 > net.inet.ip.options.SECURITY 0 > net.inet.ip.options.LSRR: 0 > net.inet.ip.options.SATID: 0 > net.inet.ip.options.SSRR: 0 > net.inet.ip.options.RA: 0 > > where options we DON'T support exist and are stuck at 0. > > or maybe even: > net.inet.ip.options.RecordRoute: 1 > net.inet.ip.options.TimeStamp: 0 > etc. > > if they are usually turned off then the test would only be done if that > option exists and it would still be faster that actually doing the > option. For fine-grained selection packet filtering is the better solution. This is a simple, much lighterweight, mechanism that doesn't require touching every packet. Sam From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:03:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA3116A4CF; Thu, 6 May 2004 17:03:39 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40BFF43D3F; Thu, 6 May 2004 17:03:39 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <20040507000338015007kct4e>; Fri, 7 May 2004 00:03:38 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA86779; Thu, 6 May 2004 17:03:37 -0700 (PDT) Date: Thu, 6 May 2004 17:03:35 -0700 (PDT) From: Julian Elischer To: Sam Leffler In-Reply-To: <200405061653.36981.sam@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:03:39 -0000 On Thu, 6 May 2004, Sam Leffler wrote: > > For fine-grained selection packet filtering is the better solution. This is a > simple, much lighterweight, mechanism that doesn't require touching every > packet. I would only do the tests if the packet HAD an ip option.. either way I'm not going to scream about it.. just my thoughts on the matter.. From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:09:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C3516A4CF for ; Thu, 6 May 2004 17:09:56 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB78443D1D for ; Thu, 6 May 2004 17:09:54 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 91698 invoked from network); 7 May 2004 00:09:53 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 May 2004 00:09:53 -0000 Message-ID: <409AD3D0.DF5114F@freebsd.org> Date: Fri, 07 May 2004 02:09:52 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:09:56 -0000 Let me take this email from Julian to summarize and answer all the previous questions of this thread that has spawned... > I know these are "options" but what does the standards say about not > supporting them.. ? (I have seen non optional options before :-) RFC791 (IP specification) requires them to be implemented for IP packets. However this can be interpreted to say that it must be able to deal with them (like ignoring them) and not fall over if it gets some. RFC1812 (router requirements) differentiates between the options. Security option should be implemented but is not and has never been used. Stream identifier option must be ignored and has never been used. Source route options must be implemented but is considered evil and disabled by default. Record route may be implemented. Timestamp option may be supported. > also I dislike the all-or-nothing mechanism > I would rather see: > net.inet.ip.options.RR: 1 > net.inet.ip.options.TS: 0 > net.inet.ip.options.SECURITY 0 > net.inet.ip.options.LSRR: 0 > net.inet.ip.options.SATID: 0 > net.inet.ip.options.SSRR: 0 > net.inet.ip.options.RA: 0 > > where options we DON'T support exist and are stuck at 0. This goes far to much into the detail and is beside the point, see next. > Rationale. The sysctl is supposed to provide an option to disable IP options processing on the local host without having to set up firewall rules. Some settings of the sysctl prevent the IP options code from being run at all. Thus it can't be exploited in any way. I agree after the explanation by Julian and Maxim that the RR together with ping has its good uses. On the other hand the IP Options processing can be quite nasty for a machine if you send it enough normal packets with options that have to be processed. Doing the IP options requires a packet copy in many cases. Additionaly there are the security concerns in which the seldomly used IP options are likely to contain bugs or other nasty properties either in our implementation or some other down the stream. Jaques as one of our Security Officers had likely this in mind when he voted for a strict default. My goal was/is to take out a potentially complex processing path of ip_input() without much current purpose except for ping with RR. Ping packets are small and few. Empirical evidence (as on my core routers) suggests that the use of IP options is extremely rare and few in between. May I propose an default setting for IP options which allows for RR but restricts the packet size that will be acted upon and is rate limited like many of our ICMP replies to certain other events like closed ports etc? This would satisfy the RR tracers and make Jaques and me more happy than we are with the current situation. > Documentation. I have agreed with Ruslan to go through all ip and tcp related man pages and sync/update them with reality. There are many things that have changed in the past year that need to be correctly reflected in the man pages. He will do the mdoc markup. This will be done before 5.3R. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:17:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E426316A4CE; Thu, 6 May 2004 17:17:28 -0700 (PDT) Received: from VARK.homeunix.com (adsl-68-124-137-57.dsl.pltn13.pacbell.net [68.124.137.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A3A43D2F; Thu, 6 May 2004 17:17:28 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i470HOAd077092; Thu, 6 May 2004 17:17:24 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i470HOsR077091; Thu, 6 May 2004 17:17:24 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 6 May 2004 17:17:24 -0700 From: David Schultz To: Andre Oppermann Message-ID: <20040507001724.GA76965@VARK.homeunix.com> Mail-Followup-To: Andre Oppermann , freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> cc: freebsd-net@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:17:29 -0000 On Thu, May 06, 2004, Andre Oppermann wrote: > I have just committed the attached change to ip_input() to control the > behaviour of IP Options processing. The default is the unchanged > current behaviour. > > However I want to propose to change the default from processing options > to ignoring options (or even stronger to reject them). I think ignoring IP options by default is a great idea. However, I have reservations about rejecting packets with options outright, for two reasons: - If the options are ignored anyway, it isn't clear that rejecting packets would buy us additional security. Firewalls are an exception, but in that case it is more appropriate to block the packets with a firewall rule. - Blocking packets could create interoperability issues with other hosts. For instance, researchers have proposed DOS defenses that involve placing a nonce in the IP timestamp field. If we're going to make the Internet a PITA for them to use, there had better be a good reason for it. From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:18:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F3916A4CE for ; Thu, 6 May 2004 17:18:50 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 712EC43D53 for ; Thu, 6 May 2004 17:18:49 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 92198 invoked from network); 7 May 2004 00:18:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 May 2004 00:18:47 -0000 Message-ID: <409AD5E6.34E3D191@freebsd.org> Date: Fri, 07 May 2004 02:18:46 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "David W. Chapman Jr." cc: Sam Leffler cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:18:50 -0000 Julian Elischer wrote: > > On Thu, 6 May 2004, Sam Leffler wrote: > > > > > For fine-grained selection packet filtering is the better solution. This is a > > simple, much lighterweight, mechanism that doesn't require touching every > > packet. > > I would only do the tests if the packet HAD an ip option.. > > either way I'm not going to scream about it.. > just my thoughts on the matter.. On a side note: Setting this sysctl to ignore does not prevent the host from generating or receiving packets with IP options on sockets. Only from adding to them when they come by. Rejecting such packets does not prevent you from sending them but certainly does from receiving them. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:29:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F276B16A4CE; Thu, 6 May 2004 17:29:58 -0700 (PDT) Received: from invasion.mail.pas.earthlink.net (invasion.mail.pas.earthlink.net [207.217.120.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 931C543D1F; Thu, 6 May 2004 17:29:58 -0700 (PDT) (envelope-from richardcoleman@mindspring.com) Received: from c-24-99-11-212.atl.client2.attbi.com ([24.99.11.212] helo=mindspring.com) by invasion.mail.pas.earthlink.net with asmtp (Exim 3.36 #4) id 1BLtEu-000566-00; Thu, 06 May 2004 17:29:20 -0700 Message-ID: <409AD868.1020101@mindspring.com> Date: Thu, 06 May 2004 20:29:28 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 1ee258965991efcb0865379cdb43356e5e89bb4777695beb702e37df12b9c9ef4d0ab969575989afdfbd2e6457174044350badd9bab72f9c350badd9bab72f9c cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richardcoleman@mindspring.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:29:59 -0000 Julian Elischer wrote: > On Thu, 6 May 2004, David W. Chapman Jr. wrote: > >>> We are using RR option all the time to track down routing >>> asymmetry and traceroute is not an option, ping -R is very useful >>> in that cases. We all know that ipfw (and I am sure all other >>> *pf*) is able to process ip opts quite well and personally see no >>> point in this sysctls. I fail to see a documentation update >>> (inet.4 ?) as well. >>> >>> It is not clear for me why you ever ask for opinions after commit >>> not before. Strick "nay" if you care :-) >> >> He hasn't changed the default yet. But I think for the select few >> who actually use such tcp options, they can enable it. Most of >> the users however will not need this. I think the point that is >> trying to be made is that they want the default installation to be >> more secure and those who need these features can simply turn them >> on. > > what security problem are you expecting? Isn't that irrelevant? If 99.99% of the FreeBSD users don't need ip options, why should they be honored by default? Just because we can't think of a security issue at the moment doesn't mean one won't show up in the future. But in the interest of POLA, I would vote for the default to be 0 (just ignore the option and pass packet unmodified). And regardless of the outcome, please mention this somewhere in the networking section of the FreeBSD handbook. Richard Coleman richardcoleman@mindspring.com From owner-freebsd-net@FreeBSD.ORG Thu May 6 18:07:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE92916A4CE; Thu, 6 May 2004 18:07:58 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B25BE43D2D; Thu, 6 May 2004 18:07:57 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from mp3 (b5pou3w9@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i4717ru513545684; Fri, 7 May 2004 05:07:53 +0400 (MSD) Date: Fri, 7 May 2004 05:07:53 +0400 (MSD) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <409AD3D0.DF5114F@freebsd.org> Message-ID: <20040507050215.F5417@mp3files.int.ru> References: <409AD3D0.DF5114F@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 01:07:58 -0000 [...] > May I propose an default setting for IP options which allows for RR but > restricts the packet size that will be acted upon and is rate limited like > many of our ICMP replies to certain other events like closed ports etc? > This would satisfy the RR tracers and make Jaques and me more happy than > we are with the current situation. Rate limit is OK. Probably the packet size restrictions is OK too. Do not think we need a special case for RR. I hope you are not going to turn off ip fragmentation/reassembling by default to make SO happy, aren't you? -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Thu May 6 21:19:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62A6F16A4CE; Thu, 6 May 2004 21:19:00 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4529943D39; Thu, 6 May 2004 21:18:59 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h91.vuokselantie10.fi [193.64.42.145]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i474Inmo045701; Fri, 7 May 2004 07:18:49 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <409B0E27.5010203@he.iki.fi> Date: Fri, 07 May 2004 07:18:47 +0300 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <409938F7.2090603@DeepCore.dk> <409A8675.3080102@he.iki.fi> <409A92FA.6080104@DeepCore.dk> <409AA44B.9010404@freebsd.org> In-Reply-To: <409AA44B.9010404@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 04:19:00 -0000 Scott Long wrote: > > I'm looking a t a similar system right now and it definitely looks > like an interrupt routing problem, not a driver problem. The > interesting thing is that (with 5.2-current as of two days ago) > disabling neither > ACPI nor APIC helps. I guess that we might want to get John Baldwin > involved. > I´ve also seen BIOS images which contain different information for interrupt routings for mptable and ACPI. Thankfully the vendor was quick to rectify that. Disabling APIC and HTT in the BIOS worked around the issues in my case but did not produce the performance I was looking for. Pete From owner-freebsd-net@FreeBSD.ORG Fri May 7 00:37:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8163016A4CE for ; Fri, 7 May 2004 00:37:13 -0700 (PDT) Received: from mail.butovo-online.ru (mail.b-o.ru [212.5.78.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7210A43D64 for ; Fri, 7 May 2004 00:37:12 -0700 (PDT) (envelope-from resident@b-o.ru) Received: from [192.168.91.89] (helo=priv-91-89.butovo-online.ru) by mail.butovo-online.ru with esmtp (Exim 4.24) id 1BLzzM-000HsM-6M for freebsd-net@freebsd.org; Fri, 07 May 2004 11:41:44 +0400 Date: Fri, 7 May 2004 11:39:06 +0400 From: Andrew Riabtsev X-Mailer: The Bat! (v1.62i) Business X-Priority: 3 (Normal) Message-ID: <832830880.20040507113906@b-o.ru> To: freebsd-net@freebsd.org In-Reply-To: <20040506144616.GA43633@FreeBSD.csie.NCTU.edu.tw> References: <20040506144616.GA43633@FreeBSD.csie.NCTU.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Problem with ng_ether packet flow.. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew Riabtsev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 07:37:13 -0000 Hi Jian-Wei, Thursday, May 6, 2004, 6:46:16 PM, you wrote: JWW> Hi, I spent times to figure out the packet flow with ng_ether, like this: JWW> upper layer JWW> | JWW> ^ JWW> [ether_demux] JWW> ^ JWW> | JWW> +---<---[ng_ether_rcvdata]--<-- 'upper' --<--, JWW> ^ \ JWW> <--[bdg_forward]--<--+ ng_tee JWW> | / JWW> +--->---[ng_ether_input]---->-- 'lower' -->--` JWW> ^ JWW> [ether_input] JWW> ^ JWW> | JWW> device JWW> Why the [ng_ether_rcvdata] won't check if packets should travel to JWW> the [bdg_forward] when they are bridged packets? This is how it should work, you get entrance to low level network (lower hook) and upper level (upper). To bridge or not to bridge figuring out with ng_bridge or other ng_* modules is up to you to decide. And what is a strange direct link between [ether_demux] and [ether_input]? When connecting anything to upper or lower hooks of ng_ether this link no longer exists. Or you have changed code of ng_ether and/or if_ethersubr.c then probably you should ask yourself why it's not working, is it? :) JWW> i.e. Should the packet flow be changed to this one? JWW> upper layer JWW> | JWW> ^ JWW> [ether_demux] JWW> ^ JWW> <--[bdg_forward]--<--+ JWW> | JWW> +---<---[ng_ether_rcvdata]--<-- 'upper' --<--, JWW> ^ \ JWW> | ng_tee JWW> | / JWW> +--->---[ng_ether_input]---->-- 'lower' -->--` JWW> ^ JWW> [ether_input] JWW> ^ JWW> | JWW> device JWW> Sincerely Yours, JWW> Jian-Wei Wang JWW> _______________________________________________ JWW> freebsd-net@freebsd.org mailing list JWW> http://lists.freebsd.org/mailman/listinfo/freebsd-net JWW> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Andrew mailto:resident@b-o.ru From owner-freebsd-net@FreeBSD.ORG Fri May 7 00:50:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F65116A4CE for ; Fri, 7 May 2004 00:50:11 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CFC843D53 for ; Fri, 7 May 2004 00:50:10 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i477moQE095188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 11:48:50 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i477mnul095187; Fri, 7 May 2004 11:48:49 +0400 (MSD) Date: Fri, 7 May 2004 11:48:49 +0400 From: Gleb Smirnoff To: Andrew Riabtsev Message-ID: <20040507074849.GA95043@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andrew Riabtsev , freebsd-net@freebsd.org References: <20040506144616.GA43633@FreeBSD.csie.NCTU.edu.tw> <832830880.20040507113906@b-o.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <832830880.20040507113906@b-o.ru> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: Problem with ng_ether packet flow.. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 07:50:11 -0000 On Fri, May 07, 2004 at 11:39:06AM +0400, Andrew Riabtsev wrote: A> JWW> Why the [ng_ether_rcvdata] won't check if packets should travel to A> JWW> the [bdg_forward] when they are bridged packets? A> A> This is how it should work, you get entrance to low level network A> (lower hook) and upper level (upper). To bridge or not to bridge A> figuring out with ng_bridge or other ng_* modules is up to you to A> decide. Jian-Wei says a reasonable thing. If he described situation right way, then it means that using ng_tee on top of ng_ether is incompatible with bridge(4). Someone should look into it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri May 7 00:51:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2388416A4CF; Fri, 7 May 2004 00:51:17 -0700 (PDT) Received: from ftp.ccrle.nec.de (ftp.netlab.nec.de [195.37.70.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DC0543D53; Fri, 7 May 2004 00:51:15 -0700 (PDT) (envelope-from stiemerling@netlab.nec.de) Received: from [10.1.1.109] (scout.netlab.nec.de [195.37.70.100]) by ftp.ccrle.nec.de (Postfix) with ESMTP id 0ED44F674; Fri, 7 May 2004 09:56:16 +0200 (CEST) Date: Fri, 07 May 2004 09:51:00 +0200 From: Martin Stiemerling To: Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <2147483647.1083923460@[10.1.1.109]> In-Reply-To: <409A8EF3.5825EF0C@freebsd.org> References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 07:51:17 -0000 Hi, I vote for choice "Ignore IP options and pass packets unmodified." since this is fail safe for the node receiving the packet and does not break end to end traffic. Anyway, setting the default to reject packets is IMHO not a good idea, since packets are probably dropped by your router somewhere in the Internet without any obvious reason to other people or hosts. Setting the default behaviour to reject will even block the deployment of new protocols. There is currently a new signalling protocol under development, called NSIS (Next Steps in Signalling, IETF stuff, intended to be a RSVP successor), that will use router alert options to find NSIS nodes along the data path. Regards, Martin --On Donnerstag, 6. Mai 2004 21:16 Uhr +0200 Andre Oppermann wrote: | I have just committed the attached change to ip_input() to control the | behaviour of IP Options processing. The default is the unchanged | current behaviour. | | However I want to propose to change the default from processing options | to ignoring options (or even stronger to reject them). | | The rationale is as follows. IP Options do not have any legitimate use | in todays Internet at all. For a long time now we have disabled source | routing. The remaining IP Options are RR (record route) and TS (time | stamp) which are both useless. For finding out which path a packet takes | we use traceroute instead of RR. Besides that RR is limited to the space | in the IP Options field and can possibly record only a few hops (9 IIRC). | Time stamp is useless for the same reason and since it doesn't have a | fixed and synchronized timebase it is even more so useless. | | Opinions? Discussion? Yes/Nay? | | -- | Andre | | |> andre 2004/05/06 11:46:03 PDT |> |> FreeBSD src repository |> |> Modified files: |> sys/netinet ip_fastfwd.c ip_input.c ip_var.h |> Log: |> Provide the sysctl net.inet.ip.process_options to control the |> processing of IP options. |> |> net.inet.ip.process_options=0 Ignore IP options and pass packets |> unmodified. net.inet.ip.process_options=1 Process all IP options |> (default). net.inet.ip.process_options=2 Reject all packets with IP |> options with ICMP filter prohibited message. |> |> This sysctl affects packets destined for the local host as well as |> those only transiting through the host (routing). |> |> IP options do not have any legitimate purpose anymore and are only used |> to circumvent firewalls or to exploit certain behaviours or bugs in |> TCP/IP stacks. |> |> Reviewed by: sam (mentor) |> |> Revision Changes Path |> 1.11 +10 -2 src/sys/netinet/ip_fastfwd.c |> 1.271 +13 -0 src/sys/netinet/ip_input.c |> 1.87 +1 -0 src/sys/netinet/ip_var.h | _______________________________________________ | freebsd-net@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-net | To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri May 7 01:32:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 671C216A4CF for ; Fri, 7 May 2004 01:32:32 -0700 (PDT) Received: from mailgate.urz.tu-dresden.de (mailgate.urz.tu-dresden.de [141.30.66.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id E096F43D2F for ; Fri, 7 May 2004 01:32:31 -0700 (PDT) (envelope-from der_julian@web.de) Received: from [127.0.0.1] (helo=localhost) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BM0mT-00052X-Tm; Fri, 07 May 2004 10:32:30 +0200 Received: from mailgate.urz.tu-dresden.de ([127.0.0.1]) by localhost (rks24 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19030-10; Fri, 7 May 2004 10:32:29 +0200 (MET DST) Received: from [141.30.207.25] (helo=jmmr) by mailgate.urz.tu-dresden.de with esmtp (exim-4.22) id 1BM0mT-00052T-9d; Fri, 07 May 2004 10:32:29 +0200 To: Julian Elischer References: From: Julian Stecklina Date: Fri, 07 May 2004 10:32:29 +0200 In-Reply-To: (Julian Elischer's message of "Thu, 6 May 2004 16:51:21 -0700 (PDT)") Message-ID: <86n04k3aea.fsf@web.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (celery, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-TUD-Virus-Scanned: by amavisd-new at rks24.urz.tu-dresden.de X-TUD-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on rks24 cc: freebsd-net@freebsd.org Subject: Re: PPPoE problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 08:32:32 -0000 Julian Elischer writes: > [I suspect that the above may have failed.. doing > 'ngctl list', 'ngctl show ath0:orphans' and 'ngctl show .:' > would be constructive..] This is with pppoed running: jmmr# ngctl list There are 5 total nodes: Name: ngctl949 Type: socket ID: 00000005 Num hooks: 0 Name: Type: pppoe ID: 00000004 Num hooks: 2 Name: Type: socket ID: 00000003 Num hooks: 1 Name: fxp0 Type: ether ID: 00000002 Num hooks: 0 Name: ath0 Type: ether ID: 00000001 Num hooks: 1 jmmr# ngctl show ath0: Name: ath0 Type: ether ID: 00000001 Num hooks: 1 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- orphans pppoe 00000004 ethernet jmmr# ngctl show ath0:orphans Name: Type: pppoe ID: 00000004 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- pppoe-402 socket 00000003 pppoe-402 ethernet ath0 ether 00000001 orphans jmmr# ngctl show .: Name: ngctl951 Type: socket ID: 00000007 Num hooks: 0 > Are the kernel and pppoed compiled at the same time from the same > sources? (/usr/include/netgraph/) I made world yesterday. Everything should be in perfect sync. Regards, -- Julian Stecklina Signed and encrypted mail welcome. Key-Server: pgp.mit.edu Key-ID: 0xD65B2AB5 FA38 DCD3 00EC 97B8 6DD8 D7CC 35D8 8D0E D65B 2AB5 Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. - Greenspun's Tenth Rule of Programming From owner-freebsd-net@FreeBSD.ORG Fri May 7 02:21:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5562316A4CE; Fri, 7 May 2004 02:21:40 -0700 (PDT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id C74D543D60; Fri, 7 May 2004 02:21:39 -0700 (PDT) (envelope-from dean@dragon.stack.nl) Received: from dragon.stack.nl (dragon.stack.nl [IPv6:2001:610:1108:5011:207:e9ff:fe09:230]) by mailhost.stack.nl (Postfix) with ESMTP id 005021F007; Fri, 7 May 2004 11:21:38 +0200 (CEST) Received: by dragon.stack.nl (Postfix, from userid 1600) id EE8F25F208; Fri, 7 May 2004 11:21:38 +0200 (CEST) Date: Fri, 7 May 2004 11:21:38 +0200 From: Dean Strik To: Andre Oppermann Message-ID: <20040507092138.GC34166@dragon.stack.nl> References: <409A964E.2FE5F40E@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409A964E.2FE5F40E@freebsd.org> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Julian Elischer Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 09:21:40 -0000 Andre Oppermann wrote: > Julian Elischer wrote: > > I use RR all the time. > > it allows you to record the reverse path, (up to the size limitation). > > Which won't get you far these days... ;-) I use it occasionally, on our highly asymmetric site. The length restriction is not a problem there :) -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli From owner-freebsd-net@FreeBSD.ORG Fri May 7 02:59:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F4216A4CE; Fri, 7 May 2004 02:59:50 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58F2E43D39; Fri, 7 May 2004 02:59:50 -0700 (PDT) (envelope-from fanf@chiark.greenend.org.uk) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local id 1BM28z-0007ke-00; Fri, 07 May 2004 10:59:49 +0100 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org From: Tony Finch In-Reply-To: References: <409A8EF3.5825EF0C@freebsd.org> Message-Id: Sender: Tony Finch Date: Fri, 07 May 2004 10:59:49 +0100 Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 09:59:50 -0000 Julian Elischer wrote: > >I use RR all the time. >it allows you to record the reverse path, (up to the size limitation). When I worked at an ISP that used BSD routers everywhere on which I had root, I wrote an evil little script for that purpose... http://dotat.at/prog/scripts/sshtrace Tony. -- f.a.n.finch http://dotat.at/ MALIN: VARIABLE BECOMING NORTHWEST 4, OCCASIONALLY 5 LATER. SHOWERS THEN RAIN. MODERATE OR GOOD. From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:08:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 478E316A4CE for ; Fri, 7 May 2004 05:08:55 -0700 (PDT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DE6F43D5A for ; Fri, 7 May 2004 05:08:54 -0700 (PDT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.11/8.12.11) with ESMTP id i47C8qdB094349 for ; Fri, 7 May 2004 16:08:53 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 7 May 2004 16:08:52 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-net@freebsd.org Message-ID: <20040507160253.B61288@woozle.rinet.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:08:55 -0000 Dear colleagues, we're using Cronyx adapters, some of them in FremaRelay mode, which has been supported by cronyx-made drivers available from vendor site for most of FreeBSD versions. FR support involves modifications to sppp kernel routines. Main driver maintainer is now FreeBSD committer (rik@). However, during merging cx/ctau into the tree, FR suppport has not been incorporated. Roman told me there are some objections to these modifications. Can I ask for more complete cx/ctau support including FR? Please keep me CC'd, as I'm not subscribed to -net. Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:17:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 838A916A4CE for ; Fri, 7 May 2004 05:17:41 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85F1143D41 for ; Fri, 7 May 2004 05:17:40 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i47CHcQE097401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 16:17:39 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i47CHc9T097400; Fri, 7 May 2004 16:17:38 +0400 (MSD) Date: Fri, 7 May 2004 16:17:38 +0400 From: Gleb Smirnoff To: Dmitry Morozovsky Message-ID: <20040507121738.GA97302@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Dmitry Morozovsky , freebsd-net@freebsd.org References: <20040507160253.B61288@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040507160253.B61288@woozle.rinet.ru> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:17:41 -0000 On Fri, May 07, 2004 at 04:08:52PM +0400, Dmitry Morozovsky wrote: D> we're using Cronyx adapters, some of them in FremaRelay mode, which has been D> supported by cronyx-made drivers available from vendor site for most of FreeBSD D> versions. FR support involves modifications to sppp kernel routines. D> D> Main driver maintainer is now FreeBSD committer (rik@). D> However, during merging cx/ctau into the tree, FR suppport has not been D> incorporated. Roman told me there are some objections to these modifications. D> D> Can I ask for more complete cx/ctau support including FR? D> D> Please keep me CC'd, as I'm not subscribed to -net. FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This support is hardware independent. And it works perfectly with cronyx adapters. What is a reason for merging hardware specific support from old cronyx driver into base system? P.S. I'll try to translate cronyx docs into english this weekend, and submit them as a manpage. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:31:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71C5E16A4CF for ; Fri, 7 May 2004 05:31:10 -0700 (PDT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8684243D48 for ; Fri, 7 May 2004 05:31:09 -0700 (PDT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.11/8.12.11) with ESMTP id i47CV8Ms094645; Fri, 7 May 2004 16:31:08 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 7 May 2004 16:31:08 +0400 (MSD) From: Dmitry Morozovsky To: Gleb Smirnoff In-Reply-To: <20040507121738.GA97302@cell.sick.ru> Message-ID: <20040507162633.G61288@woozle.rinet.ru> References: <20040507160253.B61288@woozle.rinet.ru> <20040507121738.GA97302@cell.sick.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:31:10 -0000 On Fri, 7 May 2004, Gleb Smirnoff wrote: GS> D> we're using Cronyx adapters, some of them in FremaRelay mode, which has been GS> D> supported by cronyx-made drivers available from vendor site for most of FreeBSD GS> D> versions. FR support involves modifications to sppp kernel routines. GS> D> GS> D> Main driver maintainer is now FreeBSD committer (rik@). GS> D> However, during merging cx/ctau into the tree, FR suppport has not been GS> D> incorporated. Roman told me there are some objections to these modifications. GS> D> GS> D> Can I ask for more complete cx/ctau support including FR? GS> D> GS> D> Please keep me CC'd, as I'm not subscribed to -net. GS> GS> FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This GS> support is hardware independent. And it works perfectly with cronyx adapters. GS> What is a reason for merging hardware specific support from old cronyx driver into GS> base system? Short answer: keep POLA. Longer answer: to keep 4.x systems with _existing_ fr setup up to date, non-intuitive and non-atomic patches are now required. BTW: we have more than one perfectly (for particular meaning of 'perfect', os course ;-) working firewall systems, more than on (3) ppp inplementations, and more than one software raid implementation. I do not see any harm in existing another (working!) implementation for fr then, especially when it does so little bloat to the code base. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:39:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF76D16A4CE for ; Fri, 7 May 2004 05:39:51 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D43C743D48 for ; Fri, 7 May 2004 05:39:50 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i47CdmQE097649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 May 2004 16:39:49 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i47Cdmek097648; Fri, 7 May 2004 16:39:48 +0400 (MSD) Date: Fri, 7 May 2004 16:39:47 +0400 From: Gleb Smirnoff To: Dmitry Morozovsky Message-ID: <20040507123947.GA97635@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Dmitry Morozovsky , freebsd-net@freebsd.org References: <20040507160253.B61288@woozle.rinet.ru> <20040507121738.GA97302@cell.sick.ru> <20040507162633.G61288@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040507162633.G61288@woozle.rinet.ru> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:39:52 -0000 On Fri, May 07, 2004 at 04:31:08PM +0400, Dmitry Morozovsky wrote: D> GS> FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This D> GS> support is hardware independent. And it works perfectly with cronyx adapters. D> GS> What is a reason for merging hardware specific support from old cronyx driver into D> GS> base system? D> D> Short answer: keep POLA. D> D> Longer answer: to keep 4.x systems with _existing_ fr setup up to date, D> non-intuitive and non-atomic patches are now required. D> D> BTW: we have more than one perfectly (for particular meaning of 'perfect', os D> course ;-) working firewall systems, more than on (3) ppp inplementations, and D> more than one software raid implementation. I do not see any harm in existing D> another (working!) implementation for fr then, especially when it does so D> little bloat to the code base. From the point of FreeBSD cronyx driver appeared 1 month ago, and was not supported before. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:41:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 166B116A502; Fri, 7 May 2004 05:41:04 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E5443D39; Fri, 7 May 2004 05:41:02 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 37AF95485D; Fri, 7 May 2004 07:41:02 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 59056-06; Fri, 7 May 2004 07:40:51 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 8032854846; Fri, 7 May 2004 07:40:51 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id D46671FAFEF; Fri, 7 May 2004 07:40:43 -0500 (CDT) Date: Fri, 7 May 2004 07:40:43 -0500 From: "Jacques A. Vidrine" To: Martin Stiemerling Message-ID: <20040507124043.GA1136@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Martin Stiemerling , Andre Oppermann , freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> <2147483647.1083923460@[10.1.1.109]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147483647.1083923460@[10.1.1.109]> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:41:04 -0000 On Fri, May 07, 2004 at 09:51:00AM +0200, Martin Stiemerling wrote: > Anyway, setting the default to reject packets is IMHO not > a good idea, After a night's sleep, I also agree. Emitting ICMP messages is probably a bad, bad default. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:42:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79DB416A4CE; Fri, 7 May 2004 05:42:07 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A95B43D60; Fri, 7 May 2004 05:42:07 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id B58DC5487E; Fri, 7 May 2004 07:42:06 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 59056-07; Fri, 7 May 2004 07:41:56 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 3B9D15485D; Fri, 7 May 2004 07:41:56 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 1EF861FB009; Fri, 7 May 2004 07:41:52 -0500 (CDT) Date: Fri, 7 May 2004 07:41:52 -0500 From: "Jacques A. Vidrine" To: Maxim Konovalov Message-ID: <20040507124152.GB1136@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Maxim Konovalov , Andre Oppermann , "David W. Chapman Jr." , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Julian Elischer References: <409AD3D0.DF5114F@freebsd.org> <20040507050215.F5417@mp3files.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040507050215.F5417@mp3files.int.ru> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann cc: Julian Elischer Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:42:07 -0000 On Fri, May 07, 2004 at 05:07:53AM +0400, Maxim Konovalov wrote: > I hope you are not going to turn off ip fragmentation/reassembling by > default to make SO happy, aren't you? I know you are being sarcastic, but: that wouldn't make the SO happy. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri May 7 05:52:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D835016A4D0 for ; Fri, 7 May 2004 05:52:08 -0700 (PDT) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE1D543D53 for ; Fri, 7 May 2004 05:52:07 -0700 (PDT) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.12.11/8.12.11) with ESMTP id i47Cq6be094915; Fri, 7 May 2004 16:52:06 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 7 May 2004 16:52:06 +0400 (MSD) From: Dmitry Morozovsky To: Gleb Smirnoff In-Reply-To: <20040507123947.GA97635@cell.sick.ru> Message-ID: <20040507165035.C61288@woozle.rinet.ru> References: <20040507160253.B61288@woozle.rinet.ru> <20040507121738.GA97302@cell.sick.ru> <20040507123947.GA97635@cell.sick.ru> X-NCC-RegID: ru.rinet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 12:52:09 -0000 On Fri, 7 May 2004, Gleb Smirnoff wrote: GS> From the point of FreeBSD cronyx driver appeared 1 month ago, and was not GS> supported before. This is simply not true; yes, driver in the tree has been obsolete from 3.x era and mostly non-workable; however, cronyx hardware _is_ supported by FreeBSD from 2.x years. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri May 7 06:23:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6254116A4CE for ; Fri, 7 May 2004 06:23:04 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AA2F43D1F for ; Fri, 7 May 2004 06:23:03 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i47DK6po035837 for freebsd-net@freebsd.org.checked; (8.12.8/vak/2.1) Fri, 7 May 2004 17:20:06 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i47DHqY8035731; (8.12.8/vak/2.1) Fri, 7 May 2004 17:17:52 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <409B8CCD.1030300@cronyx.ru> Date: Fri, 07 May 2004 17:19:09 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040507160253.B61288@woozle.rinet.ru> <20040507121738.GA97302@cell.sick.ru> <20040507162633.G61288@woozle.rinet.ru> <20040507123947.GA97635@cell.sick.ru> In-Reply-To: <20040507123947.GA97635@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Dmitry Morozovsky Subject: Re: FrameRelay support for cx/ctau adapters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 13:23:04 -0000 Gleb Smirnoff wrote: >On Fri, May 07, 2004 at 04:31:08PM +0400, Dmitry Morozovsky wrote: >D> GS> FreeBSD has support for FR with help of nodes ng_frame_relay and ng_lmi. This >D> GS> support is hardware independent. And it works perfectly with cronyx adapters. >D> GS> What is a reason for merging hardware specific support from old cronyx driver into >D> GS> base system? >D> >D> Short answer: keep POLA. >D> >D> Longer answer: to keep 4.x systems with _existing_ fr setup up to date, >D> non-intuitive and non-atomic patches are now required. >D> >D> BTW: we have more than one perfectly (for particular meaning of 'perfect', os >D> course ;-) working firewall systems, more than on (3) ppp inplementations, and >D> more than one software raid implementation. I do not see any harm in existing >D> another (working!) implementation for fr then, especially when it does so >D> little bloat to the code base. > > From the point of FreeBSD cronyx driver appeared 1 month ago, and was not >supported before. > > By the way take a look at cvs update -r 1.1.1.2 if_spppsubr.c 15 May 1997 14:48:46 Support for FR was in FreeBSD's sppp since 15 May, but only on vendor branch :-( I can't say why it was only there. I don't know all history, but I may ask Sergey Vakulenko about those days if some one wants to know. I become maintainer of this code a few years later. I there is no serious objections, I can commit this part of our sppp. And personaly I prefer to do so. rik From owner-freebsd-net@FreeBSD.ORG Fri May 7 06:53:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B4316A4CE for ; Fri, 7 May 2004 06:53:49 -0700 (PDT) Received: from profi.kharkov.ua (ats36sas-22.kharkov.ukrtel.net [195.5.17.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B7E843D2D for ; Fri, 7 May 2004 06:53:48 -0700 (PDT) (envelope-from greg@profi.kharkov.ua) Received: by profi.kharkov.ua (Postfix, from userid 1002) id 716E8387190; Fri, 7 May 2004 16:55:10 +0300 (EEST) Date: Fri, 7 May 2004 16:55:10 +0300 From: Gregory Edigarov To: freebsd-net@freebsd.org Message-ID: <20040507135510.GA15963@profi.kharkov.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: selective NAT problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 13:53:49 -0000 Hello, I've already put this question in freebsd-questions, without any response. I have the following configuration: #!/bin/sh ipfw -f flush ipfw add check-state ipfw add allow all from me to any ipfw add allow all from any to any via lo0 ipfw add deny all from 10.0.0.0/8 to any in via tun0 ipfw add deny all from 172.16.0.0/12 to any in via tun0 ipfw add deny all from 192.168.0.0/16 to any in via tun0 ipfw add allow icmp from me to any keep-state ipfw add allow icmp from 192.168.5.0/24 to me ipfw add deny all from any to any frag ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from 192.168.7.70 to any out recv ppp\* xmit tun0 ipfw add divert natd all from any to 195.5.17.86 in recv tun0 ipfw add allow all from 192.168.5.220 to any in via sk0 ipfw add allow all from 192.168.7.70 to any in via ppp\* ipfw add allow all from me to any ipfw add unreach filter-prohib ip from not me to any out recv any xmit tun0 ipfw add allow gre from 192.168.5.0/24 to me ipfw add allow gre from me to any ipfw add allow tcp from me to any keep-state ipfw add allow udp from me to any keep-state ipfw add allow udp from any to me 53 ipfw add allow tcp from any to any established ipfw add allow tcp from any to me 25 setup ipfw add allow tcp from any to me ssh setup ipfw add allow tcp from any to me http setup via tun0 ipfw add allow tcp from 192.168.7.0/24 to me 3128 setup via ppp\* ipfw add allow tcp from 192.168.7.0/24 to me 2080 setup via ppp\* ipfw add allow tcp from 192.168.7.0/24 to me pop3 setup via ppp\* ipfw add allow tcp from 192.168.5.0/24 to me pptp setup ipfw add allow tcp from 192.168.5.0/24 to me ftp\\-data-ftp setup via sk0 ipfw add allow tcp from any to me 53 setup ipfw add deny log all from any to any i.e. if the user is coming from 192.168.5.220 or 192.168.7.70 and his interface is from ppp group - then allow nat from him or to him. it doesn't work. The system is -CURRENT cvsuped ~ 5 days ago. What am I missing? -- With best regards, Gregory Edigarov ------------------------------------------------------------------------------ profi.kharkov.ua Systems Administrator ------------------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Fri May 7 11:10:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CD2716A4D0 for ; Fri, 7 May 2004 11:10:15 -0700 (PDT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEB4A43D53 for ; Fri, 7 May 2004 11:10:14 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21613 invoked from network); 7 May 2004 18:10:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 May 2004 18:10:14 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i47IA5q1078812; Fri, 7 May 2004 14:10:11 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 7 May 2004 14:01:17 -0400 User-Agent: KMail/1.6 References: <409A92FA.6080104@DeepCore.dk> <409AA44B.9010404@freebsd.org> In-Reply-To: <409AA44B.9010404@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200405071401.17296.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-net@FreeBSD.org cc: Scott Long cc: =?iso-8859-1?q?S=F8ren_Schmidt?= cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 18:10:15 -0000 On Thursday 06 May 2004 04:47 pm, Scott Long wrote: > S=F8ren Schmidt wrote: > > Petri Helenius wrote: > >> I=B4m highly confident that this is a case of integrated "CSA" ethernet > >> with broken BIOS. I suspect you get an message about that when booting. > > > > Nope. no messages to that effect, oh and it works in windows(tm)... > > > > The last thing I see if I try to use em0 is: > > em0: Link is up 100 Mbps Full Duplex > > and then the system locks up hard. > > I'm looking a t a similar system right now and it definitely looks like > an interrupt routing problem, not a driver problem. The interesting > thing is that (with 5.2-current as of two days ago) disabling neither > ACPI nor APIC helps. I guess that we might want to get John Baldwin > involved. Ugh, does the interrupt storm stuff in -current help at all? =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri May 7 12:08:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94FCF16A4CE; Fri, 7 May 2004 12:08:51 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23D0943D3F; Fri, 7 May 2004 12:08:51 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) by pooker.samsco.org (8.12.10/8.12.10) with ESMTP id i47JCxu6040217; Fri, 7 May 2004 13:12:59 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <409BDE98.9080200@freebsd.org> Date: Fri, 07 May 2004 13:08:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <409A92FA.6080104@DeepCore.dk> <409AA44B.9010404@freebsd.org> <200405071401.17296.jhb@FreeBSD.org> In-Reply-To: <200405071401.17296.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= cc: John Polstra Subject: Re: em(4) problems. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 19:08:51 -0000 John Baldwin wrote: > On Thursday 06 May 2004 04:47 pm, Scott Long wrote: > >>Søren Schmidt wrote: >> >>>Petri Helenius wrote: >>> >>>>I´m highly confident that this is a case of integrated "CSA" ethernet >>>>with broken BIOS. I suspect you get an message about that when booting. >>> >>>Nope. no messages to that effect, oh and it works in windows(tm)... >>> >>>The last thing I see if I try to use em0 is: >>>em0: Link is up 100 Mbps Full Duplex >>>and then the system locks up hard. >> >>I'm looking a t a similar system right now and it definitely looks like >>an interrupt routing problem, not a driver problem. The interesting >>thing is that (with 5.2-current as of two days ago) disabling neither >>ACPI nor APIC helps. I guess that we might want to get John Baldwin >>involved. > > > Ugh, does the interrupt storm stuff in -current help at all? > The interrupt storm code does indeed get triggered. What info do you need in order to track down the routing? Scott From owner-freebsd-net@FreeBSD.ORG Fri May 7 20:45:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D448316A4CE; Fri, 7 May 2004 20:45:19 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C97043D53; Fri, 7 May 2004 20:45:18 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i483jFi4000983; Sat, 8 May 2004 11:45:15 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i483jF0P000982; Sat, 8 May 2004 11:45:15 +0800 (KRAST) (envelope-from eugen) Date: Sat, 8 May 2004 11:45:14 +0800 From: Eugene Grosbein To: net@freebsd.org, arch@freebsd.org Message-ID: <20040508034514.GA937@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: yar@freebsd.org Subject: Re: bin/65928: [PATCH] stock ftpd uses superuser credentials for active mode sockets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 03:45:20 -0000 Hi! When an active IPv4 TCP connection between localIP:localport and remoteIP1:remoteport1 exists, it is not possible for local non-root user to create outgoing TCP connection from localIP:localport to remoteIP2:remoteport2. Why? It prevents http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/65928 from resolving. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri May 7 23:50:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ECEC16A4CE; Fri, 7 May 2004 23:50:12 -0700 (PDT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D80643D39; Fri, 7 May 2004 23:50:11 -0700 (PDT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 70D3B1FFDD3; Sat, 8 May 2004 08:50:09 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 84BBD1FFDC1; Sat, 8 May 2004 08:50:07 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 038B31566B; Sat, 8 May 2004 06:40:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 00C1F154E2; Sat, 8 May 2004 06:40:41 +0000 (UTC) Date: Sat, 8 May 2004 06:40:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Eugene Grosbein In-Reply-To: <20040508034514.GA937@grosbein.pp.ru> Message-ID: References: <20040508034514.GA937@grosbein.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: arch@freebsd.org cc: yar@freebsd.org cc: net@freebsd.org Subject: Re: bin/65928: [PATCH] stock ftpd uses superuser credentials for active mode sockets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 06:50:12 -0000 On Sat, 8 May 2004, Eugene Grosbein wrote: Hi, > When an active IPv4 TCP connection between > localIP:localport and remoteIP1:remoteport1 exists, > it is not possible for local non-root user to create outgoing > TCP connection from localIP:localport to remoteIP2:remoteport2. > > Why? It prevents http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/65928 > from resolving. to do it with other wording: if in active mode data is send to remote, the server uses ftp-data as port (which is 20 [ftp(21)-1]) and you are running into creating a socket in the privileged port range: net.inet.ip.portrange.reservedlow to net.inet.ip.portrange.reservedhigh which "only may be opened by root-owned processes" [ip(4)]. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Sat May 8 06:23:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3924316A4D2; Sat, 8 May 2004 06:23:59 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7E0B43D3F; Sat, 8 May 2004 06:23:57 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i48DNu3F046266; Sat, 8 May 2004 17:23:56 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i48DNtvn046265; Sat, 8 May 2004 17:23:55 +0400 (MSD) (envelope-from yar) Date: Sat, 8 May 2004 17:23:54 +0400 From: Yar Tikhiy To: "Bjoern A. Zeeb" Message-ID: <20040508132354.GB44214@comp.chem.msu.su> References: <20040508034514.GA937@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: Eugene Grosbein cc: net@freebsd.org Subject: Re: bin/65928: [PATCH] stock ftpd uses superuser credentials for active mode sockets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 13:23:59 -0000 On Sat, May 08, 2004 at 06:40:41AM +0000, Bjoern A. Zeeb wrote: > > > When an active IPv4 TCP connection between > > localIP:localport and remoteIP1:remoteport1 exists, > > it is not possible for local non-root user to create outgoing > > TCP connection from localIP:localport to remoteIP2:remoteport2. > > > > Why? It prevents http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/65928 > > from resolving. > > to do it with other wording: > > if in active mode data is send to remote, the server uses ftp-data > as port (which is 20 [ftp(21)-1]) and you are running into creating > a socket in the privileged port range: > net.inet.ip.portrange.reservedlow to net.inet.ip.portrange.reservedhigh > which "only may be opened by root-owned processes" [ip(4)]. Not exactly. The right to bind a socket to a priviliged port is verified against the process credentials, with suser() and at a different point in the code. Eugene is talking about socket credentials, so_cred, and their use in preventing port stealth. It's a different thing, it applies to any port number. The code in question is in file sys/netinet/in_pcb.c, function in_pcbbind(): if (so->so_cred->cr_uid != 0 && !IN_MULTICAST(ntohl(sin->sin_addr.s_addr))) { t = in_pcblookup_local(inp->inp_pcbinfo, sin->sin_addr, lport, prison ? 0 : INPLOOKUP_WILDCARD); if (t && ... My investigation shows that the problem is somewhat tangled. On the one hand, it has to do with the way in_pcblookup_local() is invoked to check for possible port stealth. The function takes the last on/off argument "wild_okay" instructing it whether to consider connected sockets along with unconnected ones. This argument is set to 1 by the code in question unless we're in jail. Consequently, the function can match established connections. On the other hand, "wild_okay" can't just be set to constant 0 there because in this case in_pcblookup_local() would not match connections with the local wildcard address. Perhaps, yet another "if" needs to be added to check if the existing inpcb found is not connected yet. Another point to note here is that for a UDP inpcb having the foreign address set to something different from INADDR_ANY doesn't mean the inpcb is actually connected. -- Yar From owner-freebsd-net@FreeBSD.ORG Sat May 8 11:02:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6691D16A4CE; Sat, 8 May 2004 11:02:38 -0700 (PDT) Received: from audiogram.mail.pas.earthlink.net (audiogram.mail.pas.earthlink.net [207.217.120.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1018543D3F; Sat, 8 May 2004 11:02:36 -0700 (PDT) (envelope-from richardcoleman@mindspring.com) Received: from c-24-99-11-212.atl.client2.attbi.com ([24.99.11.212] helo=mindspring.com) by audiogram.mail.pas.earthlink.net with asmtp (Exim 3.36 #4) id 1BMW9j-0005wg-00; Sat, 08 May 2004 11:02:35 -0700 Message-ID: <409D20C8.6090105@mindspring.com> Date: Sat, 08 May 2004 14:02:48 -0400 From: Richard Coleman Organization: Critical Magic, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <20040506185854.GB1777@madman.celabo.org> <20040507072031.GA48708@hub.freebsd.org> <200405070755.36055.sam@errno.com> <20040508152531.GA96827@hub.freebsd.org> <20040508101459.A98855@xorpc.icir.org> In-Reply-To: <20040508101459.A98855@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 1ee258965991efcb0865379cdb43356e5e89bb4777695beb702e37df12b9c9ef5bb5dedf8f7f96bc0f8f4cba1cb2b6e1350badd9bab72f9c350badd9bab72f9c cc: "Jacques A. Vidrine" cc: freebsd-net@FreeBSD.org cc: Darren Reed cc: Andre Oppermann cc: Sam Leffler Subject: Re: cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richardcoleman@mindspring.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 18:02:38 -0000 Luigi Rizzo wrote: > On the principle, I tend to agree with Darren here... it is not nice > to replicate functionality in multiple places by using specialized > code instead of relying on (and possibly optimizing) the generic one. > It makes a lot harder to clean up the replication later, and i > believe Andre knows that quite well given the cleanup work he has > done in the past in the network stack. > > I don't think it is worth making a bit fuss about this particular > change, but certainly, as a general principle, we should try as much > as possible to use the generic mechanisms when available -- > especialliy given that performance killers are elsewhere (locking > etc.). > > cheers luigi I'm going to move this over to -net, since I don't want to reply to the cvs list. One question I always have about these type of sysctl (and a couple kernel compile options) is that it is never clear how they interact with the various firewalls. I personally use ipfilter, but would have the same questions whether I was using pf or ipfw. Do these happen before or after the firewall? If I'm using a firewall, are these redundant? A quick glance raises this question about net.inet.tcp.blackhole, net.inet.udp.blackhole, IPSTEALTH, and TCP_DROP_SYNFIN. I'm sure there are others. Richard Coleman richardcoleman@mindspring.com