From owner-freebsd-net@FreeBSD.ORG Sun May 16 07:17: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 393BB16A4CE; Sun, 16 May 2004 07:17:03 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96E1843D53; Sun, 16 May 2004 07:17:01 -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 i4GEGx3F040353; Sun, 16 May 2004 18:16:59 +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 i4GEGwHc040352; Sun, 16 May 2004 18:16:59 +0400 (MSD) (envelope-from yar) Date: Sun, 16 May 2004 18:16:58 +0400 From: Yar Tikhiy To: arch@freebsd.org, net@freebsd.org Message-ID: <20040516141658.GA39893@comp.chem.msu.su> References: <20040508034514.GA937@grosbein.pp.ru> <20040508132354.GB44214@comp.chem.msu.su> <20040515182157.GB89625@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040515182157.GB89625@comp.chem.msu.su> User-Agent: Mutt/1.5.6i cc: Eugene Grosbein Subject: TIME_WAIT sockets from other users (was 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: Sun, 16 May 2004 14:17:03 -0000 Note for the impatient: This message does not discuss the well-known issue of reusing local addresses through setting SO_REUSEADDR. This message is on reusing local addresses occupied by sockets belonging to other users. On Sat, May 15, 2004 at 10:21:57PM +0400, Yar Tikhiy wrote: > > Attached below is a patch addressing the issue of the inability to > reuse a local IP:port couple occupied by an established TCP connection > from another user, but by no listeners. Could anybody with fair > understanding of our TCP/IP stack review it please? Thanks. > > -- > Yar > > Index: in_pcb.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v > retrieving revision 1.146 > diff -u -p -r1.146 in_pcb.c > --- in_pcb.c 23 Apr 2004 23:29:49 -0000 1.146 > +++ in_pcb.c 15 May 2004 17:37:18 -0000 > @@ -340,6 +340,8 @@ in_pcbbind_setup(inp, nam, laddrp, lport > return (EADDRINUSE); > } else > if (t && > + (so->so_type != SOCK_STREAM || > + ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && > (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || > ntohl(t->inp_laddr.s_addr) != INADDR_ANY || > (t->inp_socket->so_options & One more detail to note: Currently if another user's socket is in the TIME_WAIT state, it still counts as occupying the local IP:port couple. I cannot see the point of such a behaviour. Restricting bind() is to disallow unprivileged port stealth, but how can one steal a connection in the TIME_WAIT state? For FreeBSD-4 the above patch would take care of this case along with established connections, but in CURRENT TIME_WAIT connections are a special case since they no longer use full-blown state. Therefore, for CURRENT the above patch mutates into the below one. Do I have a point? -- Yar Index: in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.146 diff -u -p -r1.146 in_pcb.c --- in_pcb.c 23 Apr 2004 23:29:49 -0000 1.146 +++ in_pcb.c 16 May 2004 13:33:33 -0000 @@ -332,14 +332,10 @@ in_pcbbind_setup(inp, nam, laddrp, lport * XXX * This entire block sorely needs a rewrite. */ - if (t && (t->inp_vflag & INP_TIMEWAIT)) { - if ((ntohl(sin->sin_addr.s_addr) != INADDR_ANY || - ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - (intotw(t)->tw_so_options & SO_REUSEPORT) == 0) && - (so->so_cred->cr_uid != intotw(t)->tw_cred->cr_uid)) - return (EADDRINUSE); - } else if (t && + ((t->inp_vflag & INP_TIMEWAIT) == 0) && + (so->so_type != SOCK_STREAM || + ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || (t->inp_socket->so_options & From owner-freebsd-net@FreeBSD.ORG Sun May 16 09:36: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 0909716A4CF; Sun, 16 May 2004 09:36:36 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58D5743D5C; Sun, 16 May 2004 09:36:32 -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 i4GGaTDE002428; Mon, 17 May 2004 00:36:29 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4GGaTam002427; Mon, 17 May 2004 00:36:29 +0800 (KRAST) (envelope-from eugen) Date: Mon, 17 May 2004 00:36:29 +0800 From: Eugene Grosbein To: bug-followup@freebsd.org Message-ID: <20040516163629.GA2271@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: bms@freebsd.org cc: net@freebsd.org Subject: Re: bin/51927: routed(8) fails to use multicast with IFF_POINTOPOINT interfaces 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, 16 May 2004 16:36:36 -0000 Reply-To: Hi! ip(4) man page says that IP_MULTICAST_IF, IP_ADD_MEMBERSHIP etc. must use local IP address of desired interface. There are (at least) two undersirable consequents: 1) It is hard (if not impossible) to distinguish between "unnumbered" IFF_POINTOPOINT interfaces, those share the same local IP address with an ethernet interface (think of pppd and proxyarp). 2) routed, zebra and quagga cannot currently use outgoing RIPv2 multicasts with IFF_POINTOPOINT interfaces (ppp, gif etc.) at least in 4-STABLE. There was an attempt to fix this by modifying INADDR_TO_IFP: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_var.h#rev1.7 It was unsuccessful and Ruslan undid it: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_var.h#rev1.39 However, we still need working RIPv2: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/51927 Presently there are only two consumers of INADDR_TO_IFP in a 4.x kernel: ipfw[2] and ip_multicast_if() in src/sys/netinet/ip_output.h, the latter is exactly what prevents routed and ripd to enable multicasts on IFF_POINTOPOINT. Another attempt to fix that is presented. The next patch introduces another macro INADDR_TO_IFP_P2P that is used by ip_multicast_if() when INADDR_TO_IFP does not find ifp. --- in_var.h.orig Sat Dec 15 03:09:34 2001 +++ in_var.h Sun May 16 23:51:14 2004 @@ -117,6 +117,20 @@ (ifp) = (ia == NULL) ? NULL : ia->ia_ifp; \ } +#define INADDR_TO_IFP_P2P(addr, ifp) \ + /* struct in_addr addr; */ \ + /* struct ifnet *ifp; */ \ +{ \ + struct in_ifaddr *ia; \ +\ + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) \ + if ((ia->ia_ifp->if_flags & IFF_POINTOPOINT) && \ + IA_DSTSIN(ia)->sin_addr.s_addr == (addr).s_addr) { \ + break; \ + } \ + (ifp) = (ia == NULL) ? NULL : ia->ia_ifp; \ +} + /* * Macro for finding the internet address structure (in_ifaddr) corresponding * to a given interface (ifnet structure). --- sys/netinet/ip_output.c.orig Fri May 14 18:51:35 2004 +++ sys/netinet/ip_output.c Fri May 14 20:40:49 2004 @@ -1785,6 +1785,9 @@ *ifindexp = ifindex; } else { INADDR_TO_IFP(*a, ifp); + if (ifp == NULL) { + INADDR_TO_IFP_P2P(*a, ifp); + } } return ifp; } I think this can be improved by introducing another hash for remote IPs of IFF_POINTOPOINT intefaces (similar to in_ifaddrhashtbl) to avoid linear search but leave that for later stage. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun May 16 11:30: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 B26E716A4CE for ; Sun, 16 May 2004 11:30:28 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8F0B43D2F for ; Sun, 16 May 2004 11:30:27 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BPQP5-0005vu-00 for freebsd-net@freebsd.org; Sun, 16 May 2004 20:30:27 +0200 Received: from [216.58.85.218] (helo=[10.0.0.49]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BPQP4-0005dq-00 for freebsd-net@freebsd.org; Sun, 16 May 2004 20:30:26 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Sun, 16 May 2004 20:32:01 +0200 User-Agent: KMail/1.6.2 References: <200404291422.56670.max@love2party.net> <20040514093817.GA54302@fbsd.lv> In-Reply-To: <20040514093817.GA54302@fbsd.lv> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200405162032.03291.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 Subject: Re: 'struct ifnet' question! 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, 16 May 2004 18:30:28 -0000 On Friday 14 May 2004 11:38, Artis Caune wrote: <...> > And here is the problem: > If i watch departure events, interface renaming feature will > flush walid rules: > case SIOCSIFNAME: > ... > EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); > ... change if_xname ... > EVENTHANDLER_INVOKE(ifnet_arrival_event, ifp); > > how about another event? ;) > EVENTHANDLER_INVOKE(ifnet_rename_event, ifp->ifx_name, new_name); > strlcpy(ifp->if_xname, new_name, sizeof(ifp->if_xname)); PLEASE NO! I can't say that I have read your implementation sketch in-depth, but if you need such a thing it is broken. > > The other (big) problem in this field is, how to handle yet unknown > > interfaces (e.g. USB/Cardbus/ppp/tun/...). > > What is about usb/cardbus/... interfaces? Don't they also call > ether_ifattach()/if_attach()? Of course they do, but you might want to write rules for those interfaces *before* you plug in your card so you can not use if_nametoindex. -- Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet From owner-freebsd-net@FreeBSD.ORG Sun May 16 12:13: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 8523916A4CE; Sun, 16 May 2004 12:13:47 -0700 (PDT) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CAA843D2F; Sun, 16 May 2004 12:13:46 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i4GJDY6W001294; Sun, 16 May 2004 20:13:34 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Sun, 16 May 2004 20:13:33 +0100 User-Agent: KMail/1.6.1 References: <20040425094940.A50968@xorpc.icir.org> In-Reply-To: <20040425094940.A50968@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405162013.33894.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Luigi Rizzo cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 16 May 2004 19:13:47 -0000 On Sunday 25 April 2004 17:49, Luigi Rizzo wrote: > Here is a snapshot of the new arp code that i have been working on > lately, based a on Andre's ideas. (I say 'ARP' for brevity, what i > mean is the layer3-to-layer2 address translation code -- arp, aarp, > nd6 all fit in the category). Sorry for the delay but I've only just had reason to look at the arp code since I've recently been working on an implementation of rfc2734 IP over firewire. In your patch, you assume that the size of the link-level address is always six bytes. This assumption is not valid - from the looks of the existing arp code, people went to great lengths to avoid making this assumption throughout the networking code. For IP over firewire, the link-level address is sixteen bytes. Other link types have various sizes. You must use ifp->if_addrlen in the generic code to cope with this correctly. From owner-freebsd-net@FreeBSD.ORG Sun May 16 20:17: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 B2D3D16A4CE for ; Sun, 16 May 2004 20:17:31 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAE143D2D for ; Sun, 16 May 2004 20:17:31 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:4103:5074:9c90:4e33]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CF44615263; Mon, 17 May 2004 12:17:26 +0900 (JST) Date: Mon, 17 May 2004 12:17:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "George V. Neville-Neil" In-Reply-To: <87r7u7wsp1.wl@jchurch.neville-neil.com.neville-neil.com> References: <87r7u7wsp1.wl@jchurch.neville-neil.com.neville-neil.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: RFC 2292 CMSG_FIRSTHDR macro... 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, 17 May 2004 03:17:31 -0000 >>>>> On Wed, 28 Apr 2004 17:09:30 -0700, >>>>> "George V. Neville-Neil" said: > This should be a minor nit but, is there any reason we > implement this this way: > #define CMSG_FIRSTHDR(mhdr) ((struct cmsghdr *)(mhdr)->msg_control) > instead of this way: > #define CMSG_FIRSTHDR(mhdr) \ > ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ > (struct cmsghdr *)(mhdr)->msg_control : \ > (struct cmsghdr *)NULL ) > as suggested in RFC 2292? > A coworker of mine asked about this and then I got to wondering > myself. I see no special reason. In fact, KAME snapshots have this check as suggested in RFC2292 (or 3542): /* * RFC 2292 requires to check msg_controllen, in case that the kernel returns * an empty list for some reasons. */ #define CMSG_FIRSTHDR(mhdr) \ ((mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ (struct cmsghdr *)(mhdr)->msg_control : \ (struct cmsghdr *)NULL) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Mon May 17 04:21: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 046D516A4CE for ; Mon, 17 May 2004 04:21:02 -0700 (PDT) Received: from mail.startatom.ru (helios.startatom.ru [62.33.65.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A59643D5F for ; Mon, 17 May 2004 04:20:57 -0700 (PDT) (envelope-from lan@startatom.ru) Received: from localhost (localhost.startatom.ru [127.0.0.1]) by mail.startatom.ru (Postfix) with ESMTP id D936F7DD62; Mon, 17 May 2004 15:20:54 +0400 (MSD) Received: from mail.startatom.ru ([127.0.0.1]) by localhost (helios.startatom.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45421-09; Mon, 17 May 2004 15:20:54 +0400 (MSD) Received: from [192.168.253.93] (zeus.startatom.ru [62.33.65.2]) by mail.startatom.ru (Postfix) with ESMTP id 707A47DD13 for ; Mon, 17 May 2004 15:20:54 +0400 (MSD) Date: Mon, 17 May 2004 15:20:20 +0400 From: Alexander Lunyov Organization: PO Start X-Priority: 3 (Normal) Message-ID: <1373993879.20040517152020@startatom.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------859018731FD1161" X-Virus-Scanned: by amavisd-new at startatom.ru Subject: ppp receiving wrong device number (cuaa10 instead of cuaaa, cuaa15 instead of cuaaf) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Lunyov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 11:21:02 -0000 ------------859018731FD1161 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. We have a gateway for our inner clients, it is FreeBSD-4.8R-p14, three Cronyx Omega PCI multiport cards (24 ports in sum), mgetty listening on all those ports, and when user connects, mgetty run exppp (enchanced ppp incarnation, http://shs.sumy.ua). Freeradius handles authentication and accounting. When i've enable freeradius module rlm_ippool (ip addresses pooling module), dialup users start receiving error "server have not assign ip address" after connecting on some telephone numbers (not all, just some numbers), and when i dig some further, i found, that freeradius in such cases did not receive NAS-Port-Id attribute from exppp. Freeradius receive standard request, but without one attribute, in example: Service-Type = Framed-User User-Name = "bpv89" Framed-Protocol = PPP CHAP-Password = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx CHAP-Challenge = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx NAS-Identifier = "zeus.domain.ru" NAS-Port-Type = Async Then i started to watch for ppp connections. And i found strange thing. Look at this (ppp log): Phase: Using interface: tun9 Phase: deflink: Created in closed state Command: default: set radius /etc/radius.conf Command: default: set dns 192.168.33.127 Command: default: set local_ip 62.33.65.0/24 Warning: Add local net: 62.33.65.0/24 Command: default: accept dns Command: default: enable lqr Command: default: enable pap Command: default: enable chap Command: default: enable mschap Command: default: enable mschapv2 Command: default: set rad_alive 20 Command: default: disable acfcomp protocomp Command: default: deny acfcomp Command: dialup: set timeout 900 Command: dialup: set mru 576 Command: dialup: set mtu 576 Phase: PPP Started (direct mode). Phase: bundle: Establish Phase: deflink: closed -> opening Phase: deflink: Connected! Phase: deflink: opening -> carrier > Phase: deflink: /dev/cuaa15: CD detected *** (1) Phase: deflink: carrier -> lcp Phase: bundle: Authenticate Phase: deflink: his = none, mine = CHAP 0x05 Phase: Chap Output: CHALLENGE Phase: Chap Input: RESPONSE (16 bytes from rim74) > Error: NAS-Port-Id borken: -1 *** (2) Phase: Radius: Request sent Phase: Radius(auth): ACCEPT received Phase: Octets limit 292770808 Phase: Chap Output: SUCCESS Phase: deflink: lcp -> open Phase: bundle: Network Then disconnection occures - freeradius didn't deliver ip address for this connection. (1) - But mgetty said that modem connects to /dev/cuaaf port! Where did come digit 15 from? This situation (decimal port number instead of hex) can also be seen on ports cuaa10 (cuaaa), cuaa11 (cuaab), cuaa12 (cuaac) etc till cuaa15 - port cuaag always comes in hex. (2) - This is my debug entry, that i insert in radius.c. Original code: if ((slot = physical_Slot(p)) >= 0) if (rad_put_int(rad, RAD_NAS_PORT, slot) != 0) { log_Printf(LogERROR, "rad_put: rad_put_int: %s\n", rad_strerror(rad)); rad_close(rad); return 0; } I've added debug 'else' for first 'if' (2). Thus physical_Slot() from physical.c returning '-1'. In physical.c: int physical_Slot(struct physical *p) { if (p->handler && p->handler->slot) return (*p->handler->slot)(p); return -1; } And p->handler is coming from tty.c (if i'm not missed the trail) in tty_iov2device(): memcpy(&dev->dev, &basettydevice, sizeof dev->dev); physical_SetupStack(p, dev->dev.name, PHYSICAL_NOFORCE); if (dev->Timer.state != TIMER_STOPPED) { dev->Timer.state = TIMER_STOPPED; p->handler = &dev->dev; /* For the benefit of StartTimer */ tty_StartTimer(p); } return &dev->dev; And i don't know where should i dig further. Must be some place, where hex numbers returns as decimal, but i don't know, where is it. Ports on multiport cards are: cuaa[1-8] - first card cuaa[9-g] - second card cuaa[h-o] - third card And next strange thing is that this problem rising only on ports cuaa[10-15] (!), in hex is cuaa[a-f] - and i'm surprised that cuaag is working fine! The most surprising thing is that all ports on third card (cuaa[h-o]) is working as they should! But still, 6 of 24 modems are out of order :( Where those decimal port numbers come from? I found only one similar problem, but there is no answer to it: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=313299+0+archive/2000/freebsd-bugs/20000702.freebsd-bugs I've contacted Cronyx company (they produce those multiport cards), and their specialist said that this is not their driver issue and he can prove it. And i believe him :) # uname -a FreeBSD zeus.domain.ru 4.8-RELEASE-p14 FreeBSD 4.8-RELEASE-p14 #4: Tue Mar 30 10:17:02 MSD 2004 root@zeus.domain.ru:/usr/src/sys/compile/zeus i386 # pkg_info -I freeradius\* mgetty\* freeradius-0.9.3 A free RADIUS server implementation mgetty-1.1.28.01.10 Handle external logins, send and receive faxes p.s.: fragments of code in this message have not changed in exppp, they are same as in original ppp p.p.s.: dmesg and all config files are in attachement, if more debug will be needed - i'll give it. -- Alexander Lunyov, lan_mailing@startatom.ru ------------859018731FD1161 Content-Type: APPLICATION/OCTET-STREAM; name="dmesg.boot" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="dmesg.boot" IyAvdmFyL3J1bi9kbWVzZy5ib290CkNvcHlyaWdodCAoYykgMTk5Mi0yMDAzIFRoZSBGcmVl QlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4 OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVu aXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJlZUJTRCA0 LjgtUkVMRUFTRS1wMTQgIzQ6IFR1ZSBNYXIgMzAgMTA6MTc6MDIgTVNEIDIwMDQKICAgIHJv b3RAemV1cy5zdGFydGF0b20ucnU6L3Vzci9zcmMvc3lzL2NvbXBpbGUvemV1cwpUaW1lY291 bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIegpDUFU6IEludGVsKFIpIENlbGVy b24oUikgQ1BVIDEuODBHSHogKDE4MDQuMTAtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2lu ID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHhmMTMgIFN0ZXBwaW5nID0gMwogIEZlYXR1cmVz PTB4M2ZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNF UCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhT UixTU0UsU1NFMixTUyxIVFQsVE0+CnJlYWwgbWVtb3J5ICA9IDUzNjc4ODk5MiAoNTI0MjA4 SyBieXRlcykKYXZhaWwgbWVtb3J5ID0gNTE4MTQ0MDAwICg1MDYwMDBLIGJ5dGVzKQpQcmVs b2FkZWQgZWxmIGtlcm5lbCAia2VybmVsIiBhdCAweGMwMzI4MDAwLgpQZW50aXVtIFBybyBN VFJSIHN1cHBvcnQgZW5hYmxlZAptZDA6IE1hbGxvYyBkaXNrClVzaW5nICRQSVIgdGFibGUs IDEyIGVudHJpZXMgYXQgMHhjMDBmMjNiMAphcG0wOiA8QVBNIEJJT1M+IG9uIG1vdGhlcmJv YXJkCmFwbTA6IGZvdW5kIEFQTSBCSU9TIHYxLjIsIGNvbm5lY3RlZCBhdCB2MS4yCm5weDA6 IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVyZmFj ZQpwY2liMDogPEhvc3QgdG8gUENJIGJyaWRnZT4gb24gbW90aGVyYm9hcmQKcGNpMDogPFBD SSBidXM+IG9uIHBjaWIwCmFncDA6IDxJbnRlbCBHZW5lcmljIGhvc3QgdG8gUENJIGJyaWRn ZT4gbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTAKcGNp YjE6IDxQQ0kgdG8gUENJIGJyaWRnZSAodmVuZG9yPTgwODYgZGV2aWNlPTI1NjEpPiBhdCBk ZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxBVEkg bW9kZWwgNTQ0NiBncmFwaGljcyBhY2NlbGVyYXRvcj4gYXQgMC4wIGlycSAxNQpwY2liMjog PEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBIdWIgdG8gUENJIGJyaWRnZT4gYXQgZGV2aWNl IDMwLjAgb24gcGNpMApwY2kyOiA8UENJIGJ1cz4gb24gcGNpYjIKcGNpMjogPHVua25vd24g Y2FyZD4gKHZlbmRvcj0weDE0ZTQsIGRldj0weDQ0MDEpIGF0IDUuMCBpcnEgMTAKdHgwOiA8 U01DIEV0aGVyUG93ZXIgSUkgMTAvMTAwPiBwb3J0IDB4YTgwMC0weGE4ZmYgbWVtIDB4ZjE4 MDAwMDAtMHhmMTgwMGZmZiBpcnEgNyBhdCBkZXZpY2UgOS4wIG9uIHBjaTIKcXNwaHkwOiA8 UVM2NjEyIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1czAKcXNwaHkwOiAgMTBi YXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwp0eDA6 IGFkZHJlc3MgMDA6ZTA6Mjk6MGM6NGQ6MWIsIHR5cGUgU01DOTQzMlRYCmF0YXBjaTA6IDxQ cm9taXNlIFRYMiBBVEExMzMgY29udHJvbGxlcj4gcG9ydCAweDkwMDAtMHg5MDBmLDB4OTQw MC0weDk0MDMsMHg5ODAwLTB4OTgwNywweGEwMDAtMHhhMDAzLDB4YTQwMC0weGE0MDcgbWVt IDB4ZjEwMDAwMDAtMHhmMTAwZmZmZiBpcnEgNSBhdCBkZXZpY2UgMTAuMCBvbiBwY2kyCmF0 YTI6IGF0IDB4YTQwMCBvbiBhdGFwY2kwCmF0YTM6IGF0IDB4OTgwMCBvbiBhdGFwY2kwCnhs MDogPDNDb20gM2M5MDVDLVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ODgwMC0weDg4 N2YgbWVtIDB4ZjA4MDAwMDAtMHhmMDgwMDA3ZiBpcnEgMTEgYXQgZGV2aWNlIDExLjAgb24g cGNpMgp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA0Ojc1OmMwOmIwOmRkCm1paWJ1czE6 IDxNSUkgYnVzPiBvbiB4bDAKdWtwaHkwOiA8R2VuZXJpYyBJRUVFIDgwMi4zdSBtZWRpYSBp bnRlcmZhY2U+IG9uIG1paWJ1czEKdWtwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEw MGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpzaW9wY2kwOiA8Q3Jvbnl4IE9tZWdhLVBD SSBTZXJpYWwgQWRhcHRlcj4gcG9ydCAweDc4MDAtMHg3ODBmLDB4ODAwMC0weDgwN2YsMHg4 NDAwLTB4ODQ3ZiBpcnEgMTAgYXQgZGV2aWNlIDEyLjAgb24gcGNpMgpzaW8xOiB0eXBlIFNU MTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW8yOiB0eXBlIFNUMTY2NTBBIHdpdGggNjQg Ynl0ZXMgRklGTwpzaW8zOiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW80 OiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW81OiB0eXBlIFNUMTY2NTBB IHdpdGggNjQgYnl0ZXMgRklGTwpzaW82OiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMg RklGTwpzaW83OiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW84OiB0eXBl IFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW9wY2kxOiA8Q3Jvbnl4IE9tZWdhLVBD SSBTZXJpYWwgQWRhcHRlcj4gcG9ydCAweDY4MDAtMHg2ODBmLDB4NzAwMC0weDcwN2YsMHg3 NDAwLTB4NzQ3ZiBpcnEgNyBhdCBkZXZpY2UgMTMuMCBvbiBwY2kyCnNpbzk6IHR5cGUgU1Qx NjY1MEEgd2l0aCA2NCBieXRlcyBGSUZPCnNpbzEwOiB0eXBlIFNUMTY2NTBBIHdpdGggNjQg Ynl0ZXMgRklGTwpzaW8xMTogdHlwZSBTVDE2NjUwQSB3aXRoIDY0IGJ5dGVzIEZJRk8Kc2lv MTI6IHR5cGUgU1QxNjY1MEEgd2l0aCA2NCBieXRlcyBGSUZPCnNpbzEzOiB0eXBlIFNUMTY2 NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW8xNDogdHlwZSBTVDE2NjUwQSB3aXRoIDY0IGJ5 dGVzIEZJRk8Kc2lvMTU6IHR5cGUgU1QxNjY1MEEgd2l0aCA2NCBieXRlcyBGSUZPCnNpbzE2 OiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMgRklGTwpzaW9wY2kyOiA8Q3Jvbnl4IE9t ZWdhLVBDSSBTZXJpYWwgQWRhcHRlcj4gcG9ydCAweDU4MDAtMHg1ODBmLDB4NjAwMC0weDYw N2YsMHg2NDAwLTB4NjQ3ZiBpcnEgMTQgYXQgZGV2aWNlIDE0LjAgb24gcGNpMgpzaW8xNzog dHlwZSBTVDE2NjUwQSB3aXRoIDY0IGJ5dGVzIEZJRk8Kc2lvMTg6IHR5cGUgU1QxNjY1MEEg d2l0aCA2NCBieXRlcyBGSUZPCnNpbzE5OiB0eXBlIFNUMTY2NTBBIHdpdGggNjQgYnl0ZXMg RklGTwpzaW8yMDogdHlwZSBTVDE2NjUwQSB3aXRoIDY0IGJ5dGVzIEZJRk8Kc2lvMjE6IHR5 cGUgU1QxNjY1MEEgd2l0aCA2NCBieXRlcyBGSUZPCnNpbzIyOiB0eXBlIFNUMTY2NTBBIHdp dGggNjQgYnl0ZXMgRklGTwpzaW8yMzogdHlwZSBTVDE2NjUwQSB3aXRoIDY0IGJ5dGVzIEZJ Rk8Kc2lvMjQ6IHR5cGUgU1QxNjY1MEEgd2l0aCA2NCBieXRlcyBGSUZPCmlzYWIwOiA8UENJ IHRvIElTQSBicmlkZ2UgKHZlbmRvcj04MDg2IGRldmljZT0yNGMwKT4gYXQgZGV2aWNlIDMx LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMTogPEludGVsIElD SDQgQVRBMTAwIGNvbnRyb2xsZXI+IGlycSAxNCBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0 YXBjaTE6IEFUQSBjaGFubmVsIGRpc2FibGVkIGJ5IEJJT1MKb3JtMDogPE9wdGlvbiBST01z PiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYsMHhkODAwMC0weGQ4N2ZmIG9uIGlzYTAKZmRj MDogPE5FQyA3MjA2NUIgb3IgY2xvbmU+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJx IDYgZHJxIDIgb24gaXNhMApmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNob2xk CmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCmF0YTAgYXQgcG9y dCAweDFmMC0weDFmNywweDNmNiBpcnEgMTQgb24gaXNhMAphdGExIGF0IHBvcnQgMHgxNzAt MHgxNzcsMHgzNzYgaXJxIDE1IG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xs ZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXli b2FyZD4gZmxhZ3MgMHgxIGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKdmdhMDog PEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4 YmZmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24g aXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzAg YXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTAKc2lvMDogdHlw ZSAxNjU1MEEKaXBmdzIgaW5pdGlhbGl6ZWQsIGRpdmVydCBlbmFibGVkLCBydWxlLWJhc2Vk IGZvcndhcmRpbmcgZW5hYmxlZCwgZGVmYXVsdCB0byBkZW55LCBsb2dnaW5nIGxpbWl0ZWQg dG8gMTAwMDAgcGFja2V0cy9lbnRyeSBieSBkZWZhdWx0CkRVTU1ZTkVUIGluaXRpYWxpemVk ICgwMTEwMzEpCmFyMDogMzgxNDZNQiA8QVRBIFJBSUQxIGFycmF5PiBbNDg2My8yNTUvNjNd IHN0YXR1czogUkVBRFkgc3ViZGlza3M6CiAwIFJFQURZIGFkNDogMzgxNjZNQiA8U1QzNDAw MTRBPiBbNzc1NDUvMTYvNjNdIGF0IGF0YTItbWFzdGVyIFVETUExMDAKICAgICAgICAgIDEg UkVBRFkgYWQ2OiAzODE2Nk1CIDxTVDM0MDAxNEE+IFs3NzU0NS8xNi82M10gYXQgYXRhMy1t YXN0ZXIgVURNQTEwMAogICAgICAgICBNb3VudGluZyByb290IGZyb20gdWZzOi9kZXYvYXIw czFhCg== ------------859018731FD1161 Content-Type: APPLICATION/OCTET-STREAM; name="mgetty_login.config" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="mgetty_login.config" IyAvdXNyL2xvY2FsL2V0Yy9tZ2V0dHkrc2VuZGZheC9sb2dpbi5jb25maWcKL0F1dG9QUFAv ICAtICAgIC0gICAvdXNyL2xvY2FsL2Jpbi9leHBwcF8yIC1kaXJlY3QgZGlhbHVwCgo= ------------859018731FD1161 Content-Type: APPLICATION/OCTET-STREAM; name="mgetty_mgetty.config" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="mgetty_mgetty.config" IyAvdXNyL2xvY2FsL2V0Yy9tZ2V0dHkrc2VuZGZheC9tZ2V0dHkuY29uZmlnCmRlYnVnIDQK c3BlZWQgNTc2MDAKdG9nZ2xlLWR0ciBZRVMKdG9nZ2xlLWR0ci13YWl0dGltZSA1MDAKZGF0 YS1vbmx5IFlFUwptb2RlbS10eXBlIGRhdGEKaW5pdC1jaGF0ICIiIEFUJkYxIE9LIEFUTTBM MFMwPTBTMzM9MzJTMzI9OThzMjc9NjQgT0sKYW5zd2VyLWNoYXQgIiIgQVQmRjEgT0sgQVRN MEwwUzA9MFMzMz0zMlMzMj05OHMyNz02NCBPSyBBVEEgQ09OTkVDVCBcYyBccgptb2RlbS1j aGVjay10aW1lIDM2MDAwCnJpbmdzIDIKYW5zd2VyLWNoYXQtdGltZW91dCA4MAphdXRvYmF1 ZGluZyBOTwpyaW5nYmFjayBOTwpyaW5nYmFjay10aW1lIDMwCmlnbm9yZS1jYXJyaWVyIGZh bHNlCmlzc3VlLWZpbGUgL2V0Yy9pc3N1ZQpwcm9tcHQtd2FpdHRpbWUgNTAwCmxvZ2luLXBy b21wdCBGcmVlQlNEIG9uIEAgKFxMKSBcblxyXEQgXFRcblxuXHJsb2dpbjogCmxvZ2luLXRp bWUgMjQwCmRpc2tzcGFjZSAxMDI0Cm5vdGlmeSByb290CmZheC1vd25lciB1dWNwCmZheC1n cm91cCBtb2RlbQpmYXgtbW9kZSAwNjYwCgpwb3J0IGN1YWExCnBvcnQgY3VhYTIKcG9ydCBj dWFhMwpwb3J0IGN1YWE0CnBvcnQgY3VhYTUKcG9ydCBjdWFhNgpwb3J0IGN1YWE3CnBvcnQg Y3VhYTgKcG9ydCBjdWFhOQpwb3J0IGN1YWFhCnBvcnQgY3VhYWIKcG9ydCBjdWFhYwpwb3J0 IGN1YWFkCnBvcnQgY3VhYWUKcG9ydCBjdWFhZgpwb3J0IGN1YWFnCnJpbmdzIDIKaW5pdC1j aGF0ICIiIEFUJkYgT0sgQVRNMEwwUzA9MCBPSwphbnN3ZXItY2hhdCAiIiBBVCZGIE9LIEFU TTBMMFMwPTAgT0sgQVRBIENPTk5FQ1QgXGMgXHIKCnBvcnQgY3VhYWgKcG9ydCBjdWFhaQpw b3J0IGN1YWFqCnBvcnQgY3VhYWsKcG9ydCBjdWFhbApwb3J0IGN1YWFtCnBvcnQgY3VhYW4K cG9ydCBjdWFhbwoK ------------859018731FD1161 Content-Type: APPLICATION/OCTET-STREAM; name="ppp.conf" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="ppp.conf" IyAvZXRjL3BwcC9wcHAuY29uZgoKZGVmYXVsdDogCiBhbGxvdyBtb2RlIGRpcmVjdAkJCSN0 dXJuIG9uIHBwcCBicmlkZ2luZwogaWRlbnQgW1ZFUlNJT05dCiBzZXQgbG9nIFBoYXNlIElQ Q1AgQ29tbWFuZCBFcnJvciBBbGVydCBXYXJuaW5nICN0dXJuIG9uIHNvbWUgbG9nZ2luZy4g CiBzZXQgcmFkaXVzIC9ldGMvcmFkaXVzLmNvbmYJCSN0dXJuIG9uIHJhZGl1cyBhdXRoIGFu ZCB1c2UgdGhpcyBmaWxlCiBzZXQgZG5zIDE5Mi4xNjguMzMuMTI3IAogc2V0IGxvY2FsX2lw IDYyLjMzLjY1LjAvMjQKIGFjY2VwdCBkbnMKIGVuYWJsZSBscXIKIGVuYWJsZSBwYXAJCQkJ I3R1cm4gb24gY2hhcCBhbmQgcGFwIGFjY291bnRpbmcKIGVuYWJsZSBjaGFwCQkJCSN0dXJu IG9uIGNoYXAgYW5kIHBhcCBhY2NvdW50aW5nCiBlbmFibGUgbXNjaGFwCiBlbmFibGUgbXNj aGFwdjIKIHNldCByYWRfYWxpdmUgMjAgICAgICAgICAgICMg6c7UxdLXwcwgQWxpdmUg2sHQ ydPFyiDEzNEg0sHEydXTwSAtIDYwINPFywogZGlzYWJsZSBhY2Zjb21wIHByb3RvY29tcAog ZGVueSBhY2Zjb21wCgpwcHBvZToKIHNldCB0aW1lb3V0IDAgCiBzZXQgbXJ1IDE0NzIJCQkJ I3NldCBtcnUgYmVsb3cgMTUwMCAoUFBQb0UgTVRVIGlzc3VlKQogc2V0IG10dSAxNDcyCQkJ CSNzZXQgbXR1IGJlbG93IDE1MDAgKFBQUG9FIE1UVSBpc3N1ZSkKIAoKZGlhbHVwOgogc2V0 IHRpbWVvdXQgOTAwCiBzZXQgbXJ1IDU3Ngogc2V0IG10dSA1NzYKCg== ------------859018731FD1161 Content-Type: APPLICATION/OCTET-STREAM; name="radiusd.conf" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="radiusd.conf" IyAvdXNyL2xvY2FsL2V0Yy9yYWRkYi9tZ2V0dHkuY29uZmlnCnByZWZpeCA9IC91c3IvbG9j YWwKZXhlY19wcmVmaXggPSAke3ByZWZpeH0Kc3lzY29uZmRpciA9ICR7cHJlZml4fS9ldGMK bG9jYWxzdGF0ZWRpciA9IC92YXIKc2JpbmRpciA9ICR7ZXhlY19wcmVmaXh9L3NiaW4KbG9n ZGlyID0gJHtsb2NhbHN0YXRlZGlyfS9sb2cvcmFkaXVzCnJhZGRiZGlyID0gJHtzeXNjb25m ZGlyfS9yYWRkYgpyYWRhY2N0ZGlyID0gJHtsb2dkaXJ9L3JhZGFjY3QKY29uZmRpciA9ICR7 cmFkZGJkaXJ9CnJ1bl9kaXIgPSAke2xvY2Fsc3RhdGVkaXJ9L3J1bi9yYWRpdXNkCmxvZ19m aWxlID0gJHtsb2dkaXJ9L3JhZGl1cy5sb2cKbGliZGlyID0gJHtleGVjX3ByZWZpeH0vbGli CnBpZGZpbGUgPSAke3J1bl9kaXJ9L3JhZGl1c2QucGlkCm1heF9yZXF1ZXN0X3RpbWUgPSAz MApkZWxldGVfYmxvY2tlZF9yZXF1ZXN0cyA9IG5vCmNsZWFudXBfZGVsYXkgPSA1Cm1heF9y ZXF1ZXN0cyA9IDEwMjQKYmluZF9hZGRyZXNzID0gKgpwb3J0ID0gMApob3N0bmFtZV9sb29r dXBzID0gbm8KYWxsb3dfY29yZV9kdW1wcyA9IG5vCnJlZ3VsYXJfZXhwcmVzc2lvbnMJPSB5 ZXMKZXh0ZW5kZWRfZXhwcmVzc2lvbnMJPSB5ZXMKbG9nX3N0cmlwcGVkX25hbWVzID0gbm8K bG9nX2F1dGggPSB5ZXMKbG9nX2F1dGhfYmFkcGFzcyA9IHllcwpsb2dfYXV0aF9nb29kcGFz cyA9IG5vCnVzZXJjb2xsaWRlID0geWVzCmxvd2VyX3VzZXIgPSBiZWZvcmUKbG93ZXJfcGFz cyA9IG5vCm5vc3BhY2VfdXNlciA9IG5vCm5vc3BhY2VfcGFzcyA9IG5vCmNoZWNrcmFkID0g JHtzYmluZGlyfS9jaGVja3JhZApzZWN1cml0eSB7CgltYXhfYXR0cmlidXRlcyA9IDIwMAoJ cmVqZWN0X2RlbGF5ID0gMQoJc3RhdHVzX3NlcnZlciA9IG5vCn0KcHJveHlfcmVxdWVzdHMg ID0geWVzCiRJTkNMVURFICAke2NvbmZkaXJ9L3Byb3h5LmNvbmYKJElOQ0xVREUgICR7Y29u ZmRpcn0vY2xpZW50cy5jb25mCnNubXAJPSBubwokSU5DTFVERSAgJHtjb25mZGlyfS9zbm1w LmNvbmYKdGhyZWFkIHBvb2wgewoJc3RhcnRfc2VydmVycyA9IDUKCW1heF9zZXJ2ZXJzID0g MzIKCW1pbl9zcGFyZV9zZXJ2ZXJzID0gMwoJbWF4X3NwYXJlX3NlcnZlcnMgPSAxMAoJbWF4 X3JlcXVlc3RzX3Blcl9zZXJ2ZXIgPSAwCn0KbW9kdWxlcyB7CglzcWxjb3VudGVyIG1vbnRo bHl0cmFmZmljIHsKCQljb3VudGVyLW5hbWUgPSBNb250aGx5LVRyYWZmaWMKCQljaGVjay1u YW1lID0gTWF4LU1vbnRobHktVHJhZmZpYwoJCXNxbG1vZC1pbnN0ID0gc3FsCgkJa2V5ID0g VXNlci1OYW1lCgkJcmVzZXQgPSBtb250aGx5CgkJcXVlcnkgPSAiU0VMRUNUIChzdW0oQWNj dElucHV0T2N0ZXRzKStzdW0oQWNjdE91dHB1dE9jdGV0cykpIEZST00gcmFkYWNjdCBXSEVS RSBVc2VyTmFtZT0nJXUnIEFORCBVTklYX1RJTUVTVEFNUChBY2N0U3RhcnRUaW1lKSArIEFj Y3RTZXNzaW9uVGltZSA+ICclYiciCgl9CglwYXAgewoJCWVuY3J5cHRpb25fc2NoZW1lID0g Y2xlYXIKCX0KCWNoYXAgewoJCWF1dGh0eXBlID0gQ0hBUAoJfQoJcGFtIHsKCQlwYW1fYXV0 aCA9IHJhZGl1c2QKCX0KCXVuaXggewoJCWNhY2hlID0gbm8KCQljYWNoZV9yZWxvYWQgPSA2 MDAKCQlyYWR3dG1wID0gJHtsb2NhbHN0YXRlZGlyfS9sb2cvd3RtcAoJfQoJZWFwIHsKCQlk ZWZhdWx0X2VhcF90eXBlID0gbWQ1CgkJdGltZXJfZXhwaXJlICAgICA9IDYwCgkJbWQ1IHsK CQl9CgkJbGVhcCB7CgkJfQoJfQoJbXNjaGFwIHsKCQlhdXRodHlwZSA9IE1TLUNIQVAKCX0K CWxkYXAgewoJCXNlcnZlciA9ICJsZGFwLmRvbWFpbi5ydSIKCQlpZGVudGl0eSA9ICJjbj1h ZG1pbixkYz1kb21haW4sZGM9cnUiCgkJcGFzc3dvcmQgPSBzZWNyZXR0cGFzcwoJCWJhc2Vk biA9ICJvdT11c2VycyxkYz1kb21haW4sZGM9cnUiCgkJZmlsdGVyID0gIih1aWQ9JXUpIgoJ CXN0YXJ0X3RscyA9IG5vCgkJdGxzX21vZGUgPSBubwoJCWRlZmF1bHRfcHJvZmlsZSA9ICJj bj1yYWRwcm9maWxlLGRjPWRvbWFpbixkYz1ydSIKCQlhY2Nlc3NfZ3JvdXAgPSAiY249ZGlh bHVwLWdyb3VwLGRjPWRvbWFpbixkYz1ydSIKCQlhY2Nlc3NfYXR0ciA9ICJkaWFsdXBBY2Nl c3MiCgkJZGljdGlvbmFyeV9tYXBwaW5nID0gJHtyYWRkYmRpcn0vbGRhcC5hdHRybWFwCgkJ bGRhcF9jb25uZWN0aW9uc19udW1iZXIgPSA1CgkJcGFzc3dvcmRfYXR0cmlidXRlID0gdXNl clBhc3N3b3JkCgkJdGltZW91dCA9IDQKCQl0aW1lbGltaXQgPSAzCgkJbmV0X3RpbWVvdXQg PSAxCgl9CglyZWFsbSByZWFsbXNsYXNoIHsKCQlmb3JtYXQgPSBwcmVmaXgKCQlkZWxpbWl0 ZXIgPSAiLyIKCX0KCXJlYWxtIHN1ZmZpeCB7CgkJZm9ybWF0ID0gc3VmZml4CgkJZGVsaW1p dGVyID0gIkAiCgl9CglyZWFsbSByZWFsbXBlcmNlbnQgewoJCWZvcm1hdCA9IHN1ZmZpeAoJ CWRlbGltaXRlciA9ICIlIgoJfQoJcHJlcHJvY2VzcyB7CgkJaHVudGdyb3VwcyA9ICR7Y29u ZmRpcn0vaHVudGdyb3VwcwoJCWhpbnRzID0gJHtjb25mZGlyfS9oaW50cwoJCXdpdGhfYXNj ZW5kX2hhY2sgPSBubwoJCWFzY2VuZF9jaGFubmVsc19wZXJfbGluZSA9IDIzCgkJd2l0aF9u dGRvbWFpbl9oYWNrID0gbm8KCQl3aXRoX3NwZWNpYWxpeF9qZXRzdHJlYW1faGFjayA9IG5v CgkJd2l0aF9jaXNjb192c2FfaGFjayA9IG5vCgl9CglmaWxlcyB7CgkJdXNlcnNmaWxlID0g JHtjb25mZGlyfS91c2VycwoJCWFjY3R1c2Vyc2ZpbGUgPSAke2NvbmZkaXJ9L2FjY3RfdXNl cnMKCQljb21wYXQgPSBubwoJfQoJZGV0YWlsIHsKCQlkZXRhaWxwZXJtID0gMDYwMAoJfQoJ YWNjdF91bmlxdWUgewoJCWtleSA9ICJVc2VyLU5hbWUsIEFjY3QtU2Vzc2lvbi1JZCwgTkFT LUlQLUFkZHJlc3MsIENsaWVudC1JUC1BZGRyZXNzLCBOQVMtUG9ydC1JZCIKCX0KCSRJTkNM VURFICAke2NvbmZkaXJ9L3NxbC5jb25mCglyYWR1dG1wIHsKCQlmaWxlbmFtZSA9ICR7bG9n ZGlyfS9yYWR1dG1wCgkJdXNlcm5hbWUgPSAle1VzZXItTmFtZX0KCQljYXNlX3NlbnNpdGl2 ZSA9IHllcwoJCWNoZWNrX3dpdGhfbmFzID0geWVzCQkKCQlwZXJtID0gMDYwMAoJCWNhbGxl cmlkID0gInllcyIKCX0KCXJhZHV0bXAgc3JhZHV0bXAgewoJCWZpbGVuYW1lID0gJHtsb2dk aXJ9L3NyYWR1dG1wCgkJcGVybSA9IDA2NDQKCQljYWxsZXJpZCA9ICJubyIKCX0KCWF0dHJf ZmlsdGVyIHsKCQlhdHRyc2ZpbGUgPSAke2NvbmZkaXJ9L2F0dHJzCgl9Cgljb3VudGVyIGRh aWx5IHsKCQlmaWxlbmFtZSA9ICR7cmFkZGJkaXJ9L2RiLmRhaWx5CgkJa2V5ID0gVXNlci1O YW1lCgkJY291bnQtYXR0cmlidXRlID0gQWNjdC1TZXNzaW9uLVRpbWUKCQlyZXNldCA9IGRh aWx5CgkJY291bnRlci1uYW1lID0gRGFpbHktU2Vzc2lvbi1UaW1lCgkJY2hlY2stbmFtZSA9 IE1heC1EYWlseS1TZXNzaW9uCgkJYWxsb3dlZC1zZXJ2aWNldHlwZSA9IEZyYW1lZC1Vc2Vy CgkJY2FjaGUtc2l6ZSA9IDUwMDAKCX0KCWFsd2F5cyBmYWlsIHsKCQlyY29kZSA9IGZhaWwK CX0KCWFsd2F5cyByZWplY3QgewoJCXJjb2RlID0gcmVqZWN0Cgl9CglhbHdheXMgb2sgewoJ CXJjb2RlID0gb2sKCQlzaW11bGNvdW50ID0gMAoJCW1wcCA9IG5vCgl9CglleHByIHsKCX0K CWRpZ2VzdCB7Cgl9CglleGVjIHsKCQl3YWl0ID0geWVzCgkJaW5wdXRfcGFpcnMgPSByZXF1 ZXN0Cgl9CglleGVjIGVjaG8gewoJCXdhaXQgPSB5ZXMKCQlwcm9ncmFtID0gIi9iaW4vZWNo byAle1VzZXItTmFtZX0iCgkJaW5wdXRfcGFpcnMgPSByZXF1ZXN0CgkJb3V0cHV0X3BhaXJz ID0gcmVwbHkKCX0KCWlwcG9vbCBsZWdhbF9wb29sIHsKCQlyYW5nZS1zdGFydCA9IDE5Mi4x NjguMjUzLjIKCQlyYW5nZS1zdG9wID0gMTkyLjE2OC4yNTMuMjU0CgkJbmV0bWFzayA9IDI1 NS4yNTUuMjU1LjAKCQljYWNoZS1zaXplID0gODAwCgkJc2Vzc2lvbi1kYiA9ICR7cmFkZGJk aXJ9L2RiLmxlZ2FscG9vbAoJCWlwLWluZGV4ID0gJHtyYWRkYmRpcn0vZGIubGVnYWxpbmRl eAoJCW92ZXJyaWRlID0geWVzCgl9CglpcHBvb2wgaWxsZWdhbF9wb29sIHsKCQlyYW5nZS1z dGFydCA9IDE5Mi4xNjguMjUyLjIKCQlyYW5nZS1zdG9wID0gMTkyLjE2OC4yNTIuMjU0CgkJ bmV0bWFzayA9IDI1NS4yNTUuMjU1LjAKCQljYWNoZS1zaXplID0gODAwCgkJc2Vzc2lvbi1k YiA9ICR7cmFkZGJkaXJ9L2RiLmlsbGVnYWxwb29sCgkJaXAtaW5kZXggPSAke3JhZGRiZGly fS9kYi5pbGxlZ2FsaW5kZXgKCQlvdmVycmlkZSA9IHllcwoJfQoJJElOQ0xVREUgICR7Y29u ZmRpcn0vcGVybC5jb25mCn0KaW5zdGFudGlhdGUgewoJZXhwcgoJc3FsCn0KYXV0aG9yaXpl IHsKCWNoYXAKCW1zY2hhcAoJZmlsZXMKCWxkYXAKCWZpbGVzCglwZXJsX2xpbWl0cwp9CmF1 dGhlbnRpY2F0ZSB7CglBdXRoLVR5cGUgUEFQIHsKCQlwYXAKCX0KCUF1dGgtVHlwZSBDSEFQ IHsKCQljaGFwCgl9CglBdXRoLVR5cGUgTVMtQ0hBUCB7CgkJbXNjaGFwCgl9Cgl1bml4Cgll YXAKfQpwcmVhY2N0IHsKCXByZXByb2Nlc3MKCXN1ZmZpeAoJZmlsZXMKfQphY2NvdW50aW5n IHsKCWFjY3RfdW5pcXVlCgl1bml4CQkKCXJhZHV0bXAKCXNyYWR1dG1wCglsZWdhbF9wb29s CglpbGxlZ2FsX3Bvb2wKCXNxbAp9CnNlc3Npb24gewoJcmFkdXRtcAoJc3FsCn0KcG9zdC1h dXRoIHsKCWxlZ2FsX3Bvb2wKCWlsbGVnYWxfcG9vbAp9CnByZS1wcm94eSB7Cn0KcG9zdC1w cm94eSB7CgllYXAKfQo= ------------859018731FD1161-- From owner-freebsd-net@FreeBSD.ORG Mon May 17 10:17: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 6CCAE16A4CE for ; Mon, 17 May 2004 10:17:55 -0700 (PDT) Received: from mail.startatom.ru (helios.startatom.ru [62.33.65.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A815343D49 for ; Mon, 17 May 2004 10:17:52 -0700 (PDT) (envelope-from lan_mailing@startatom.ru) Received: from localhost (localhost.startatom.ru [127.0.0.1]) by mail.startatom.ru (Postfix) with ESMTP id DA5227DFC2; Mon, 17 May 2004 21:17:50 +0400 (MSD) Received: from mail.startatom.ru ([127.0.0.1]) by localhost (helios.startatom.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46758-09; Mon, 17 May 2004 21:17:50 +0400 (MSD) Received: from [192.168.253.110] (zeus.startatom.ru [62.33.65.2]) by mail.startatom.ru (Postfix) with ESMTP id 7C0F07DFC1 for ; Mon, 17 May 2004 21:17:50 +0400 (MSD) Date: Mon, 17 May 2004 21:17:04 +0400 From: Alexander Lunyov X-Priority: 3 (Normal) Message-ID: <384220065.20040517211704@startatom.ru> To: freebsd-net@freebsd.org In-Reply-To: <1373993879.20040517152020@startatom.ru> References: <1373993879.20040517152020@startatom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at startatom.ru Subject: Re: ppp receiving wrong device number (cuaa10 instead of cuaaa, cuaa15 instead of cuaaf) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Lunyov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 May 2004 17:17:55 -0000 Hello Alexander, Monday, May 17, 2004, 3:20:20 PM, you wrote: Wrong device name comes from tty_Create() function in tty.c: if (*p->name.full == '\0') { physical_SetDevice(p, ttyname(p->fd)); log_Printf(LogDEBUG, "%s: Input is a tty (%s)\n", p->link.name, p->name.full); } else [skip] I checked this - it's ttyname(3) who return /dev/cuaa10 instead of /dev/cuaaa. Why ttyname(3) is returning wrong device number? Device with such name doesn't even exist: # ls -l /dev/cuaa10 ls: /dev/cuaa10: No such file or directory And all cuaa[0-v] devices are here: # ls -l /dev/cuaa* crw-rw---- 1 uucp dialer 28, 128 4 май 2003 /dev/cuaa0 crw-rw---- 1 uucp uucp 28, 129 17 май 17:10 /dev/cuaa1 crw-rw---- 1 uucp uucp 28, 130 17 май 16:54 /dev/cuaa2 crw-rw---- 1 uucp uucp 28, 131 17 май 20:30 /dev/cuaa3 crw------- 1 uucp uucp 28, 132 17 май 16:42 /dev/cuaa4 crw-rw---- 1 uucp uucp 28, 133 17 май 13:07 /dev/cuaa5 crw-rw---- 1 uucp uucp 28, 134 17 май 18:15 /dev/cuaa6 crw-rw---- 1 uucp uucp 28, 135 17 май 17:10 /dev/cuaa7 crw-rw---- 1 uucp uucp 28, 136 17 май 16:47 /dev/cuaa8 crw-rw---- 1 uucp uucp 28, 137 17 май 13:07 /dev/cuaa9 crw-rw---- 1 uucp uucp 28, 138 17 май 20:51 /dev/cuaaa crw-rw---- 1 uucp uucp 28, 139 17 май 16:43 /dev/cuaab crw-rw---- 1 uucp uucp 28, 140 17 май 17:25 /dev/cuaac crw-rw---- 1 uucp uucp 28, 141 17 май 17:26 /dev/cuaad crw------- 1 uucp uucp 28, 142 14 май 10:18 /dev/cuaae crw-rw---- 1 uucp uucp 28, 143 17 май 17:22 /dev/cuaaf crw-rw---- 1 uucp uucp 28, 144 17 май 20:41 /dev/cuaag crw-rw---- 1 uucp uucp 28, 145 17 май 20:02 /dev/cuaah crw------- 1 uucp uucp 28, 146 14 май 11:51 /dev/cuaai crw-rw---- 1 uucp uucp 28, 147 17 май 19:15 /dev/cuaaj crw-rw---- 1 uucp uucp 28, 148 17 май 16:52 /dev/cuaak crw-rw---- 1 uucp uucp 28, 149 17 май 13:07 /dev/cuaal crw-rw---- 1 uucp uucp 28, 150 17 май 17:28 /dev/cuaam crw-rw---- 1 uucp uucp 28, 151 17 май 17:33 /dev/cuaan crw-rw---- 1 uucp uucp 28, 152 17 май 17:24 /dev/cuaao crw-rw---- 1 uucp uucp 28, 153 23 окт 2002 /dev/cuaap crw-rw---- 1 uucp uucp 28, 154 23 окт 2002 /dev/cuaaq crw-rw---- 1 uucp uucp 28, 155 23 окт 2002 /dev/cuaar crw-rw---- 1 root wheel 28, 156 9 окт 2002 /dev/cuaas crw-rw---- 1 root wheel 28, 157 9 окт 2002 /dev/cuaat crw-rw---- 1 root wheel 28, 158 9 окт 2002 /dev/cuaau crw-rw---- 1 root wheel 28, 159 9 окт 2002 /dev/cuaav Maybe, this is not freebsd-net@ issue anymore? Which list should i go to with this? AL> We have a gateway for our inner clients, it is FreeBSD-4.8R-p14, AL> three Cronyx Omega PCI multiport cards (24 ports in sum), mgetty AL> listening on all those ports, and when user connects, mgetty run AL> exppp (enchanced ppp incarnation, http://shs.sumy.ua). AL> Freeradius handles authentication and accounting. When i've enable AL> freeradius module rlm_ippool (ip addresses pooling module), dialup AL> users start receiving error "server have not assign ip address" AL> after connecting on some telephone numbers (not all, just some AL> numbers), and when i dig some further, i found, that freeradius in AL> such cases did not receive NAS-Port-Id attribute from exppp. AL> Freeradius receive standard request, but without one attribute, in AL> example: AL> Service-Type = Framed-User AL> User-Name = "bpv89" AL> Framed-Protocol = PPP AL> CHAP-Password = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx AL> CHAP-Challenge = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx AL> NAS-Identifier = "zeus.domain.ru" AL> NAS-Port-Type = Async AL> Then i started to watch for ppp connections. And i found strange thing. Look AL> at this (ppp log): AL> Phase: Using interface: tun9 AL> Phase: deflink: Created in closed state AL> Command: default: set radius /etc/radius.conf AL> Command: default: set dns 192.168.33.127 AL> Command: default: set local_ip 62.33.65.0/24 AL> Warning: Add local net: 62.33.65.0/24 AL> Command: default: accept dns AL> Command: default: enable lqr AL> Command: default: enable pap AL> Command: default: enable chap AL> Command: default: enable mschap AL> Command: default: enable mschapv2 AL> Command: default: set rad_alive 20 AL> Command: default: disable acfcomp protocomp AL> Command: default: deny acfcomp AL> Command: dialup: set timeout 900 AL> Command: dialup: set mru 576 AL> Command: dialup: set mtu 576 AL> Phase: PPP Started (direct mode). AL> Phase: bundle: Establish AL> Phase: deflink: closed -> opening AL> Phase: deflink: Connected! AL> Phase: deflink: opening -> carrier >> Phase: deflink: /dev/cuaa15: CD detected *** (1) AL> Phase: deflink: carrier -> lcp AL> Phase: bundle: Authenticate AL> Phase: deflink: his = none, mine = CHAP 0x05 AL> Phase: Chap Output: CHALLENGE AL> Phase: Chap Input: RESPONSE (16 bytes from rim74) >> Error: NAS-Port-Id borken: -1 *** (2) AL> Phase: Radius: Request sent AL> Phase: Radius(auth): ACCEPT received AL> Phase: Octets limit 292770808 AL> Phase: Chap Output: SUCCESS AL> Phase: deflink: lcp -> open AL> Phase: bundle: Network AL> Then disconnection occures - freeradius didn't deliver ip address for AL> this connection. AL> (1) - But mgetty said that modem connects to /dev/cuaaf port! Where AL> did come digit 15 from? This situation (decimal port number instead AL> of hex) can also be seen on ports cuaa10 (cuaaa), cuaa11 (cuaab), AL> cuaa12 (cuaac) etc till cuaa15 - port cuaag always comes in hex. AL> (2) - This is my debug entry, that i insert in radius.c. Original AL> code: AL> if ((slot = physical_Slot(p)) >= 0) AL> if (rad_put_int(rad, RAD_NAS_PORT, slot) != 0) { AL> log_Printf(LogERROR, "rad_put: rad_put_int: %s\n", rad_strerror(rad)); AL> rad_close(rad); AL> return 0; AL> } AL> I've added debug 'else' for first 'if' (2). Thus physical_Slot() from AL> physical.c returning '-1'. In physical.c: AL> int AL> physical_Slot(struct physical *p) AL> { AL> if (p->handler && p->handler->slot) AL> return (*p->handler->slot)(p); AL> return -1; AL> } AL> And p->handler is coming from tty.c (if i'm not missed the trail) AL> in tty_iov2device(): AL> memcpy(&dev->dev, &basettydevice, sizeof dev->dev); AL> physical_SetupStack(p, dev->dev.name, PHYSICAL_NOFORCE); AL> if (dev->Timer.state != TIMER_STOPPED) { AL> dev->Timer.state = TIMER_STOPPED; AL> p->handler = &dev->dev; /* For the benefit of StartTimer */ AL> tty_StartTimer(p); AL> } AL> return &dev->dev; AL> And i don't know where should i dig further. Must be some place, AL> where hex numbers returns as decimal, but i don't know, where is it. -- Best regards, Alexander mailto:lan_mailing@startatom.ru From owner-freebsd-net@FreeBSD.ORG Mon May 17 11:01: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 0496216A4CE for ; Mon, 17 May 2004 11:01:41 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D09D143D3F for ; Mon, 17 May 2004 11:01:40 -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 i4HI1eJX097614 for ; Mon, 17 May 2004 11:01:40 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4HI1dGT097609 for freebsd-net@freebsd.org; Mon, 17 May 2004 11:01:39 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 May 2004 11:01:39 -0700 (PDT) Message-Id: <200405171801.i4HI1dGT097609@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, 17 May 2004 18:01:41 -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 18 00:44: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 49D9F16A4CE for ; Tue, 18 May 2004 00:44:39 -0700 (PDT) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71B0F43D48 for ; Tue, 18 May 2004 00:44:38 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.12.11/8.12.11) id i4I7iaHK015751 for freebsd-net@freebsd.org; Tue, 18 May 2004 17:44:36 +1000 (EST) (envelope-from ernie) From: User Ernie Message-Id: <200405180744.i4I7iaHK015751@spooky.eis.net.au> To: freebsd-net@freebsd.org Date: Tue, 18 May 2004 17:44:36 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: MobileMesh 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, 18 May 2004 07:44:39 -0000 I don't suppose anyone has managed to compile the linux MobileMesh (IP Mesh) Adhoc Networking suite on FreeBSD have they? http://mitre.org/work/tech_transfer/mobilemesh/ - Ernie. From owner-freebsd-net@FreeBSD.ORG Tue May 18 01:25:29 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 99B0716A4CE; Tue, 18 May 2004 01:25:29 -0700 (PDT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9021D43D5A; Tue, 18 May 2004 01:25:27 -0700 (PDT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i4I8OUj47378; Tue, 18 May 2004 10:24:31 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n81.sp.op.dlr.de (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i4I8OUK73220; Tue, 18 May 2004 10:24:30 +0200 Received: from localhost (brandt@localhost) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i4I8OSG08259; Tue, 18 May 2004 10:24:28 +0200 (MET DST) X-Authentication-Warning: zeus.nt.op.dlr.de: brandt owned process doing -bs Date: Tue, 18 May 2004 10:24:26 +0200 (MET DST) From: Harti Brandt X-X-Sender: brandt@zeus To: Luigi Rizzo In-Reply-To: <200405162013.33894.dfr@nlsystems.com> Message-ID: References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Doug Rabson cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 08:25:29 -0000 On Sun, 16 May 2004, Doug Rabson wrote: DR>On Sunday 25 April 2004 17:49, Luigi Rizzo wrote: DR>> Here is a snapshot of the new arp code that i have been working on DR>> lately, based a on Andre's ideas. (I say 'ARP' for brevity, what i DR>> mean is the layer3-to-layer2 address translation code -- arp, aarp, DR>> nd6 all fit in the category). DR> DR>Sorry for the delay but I've only just had reason to look at the arp DR>code since I've recently been working on an implementation of rfc2734 DR>IP over firewire. In your patch, you assume that the size of the DR>link-level address is always six bytes. This assumption is not valid - DR>from the looks of the existing arp code, people went to great lengths DR>to avoid making this assumption throughout the networking code. DR> DR>For IP over firewire, the link-level address is sixteen bytes. Other DR>link types have various sizes. You must use ifp->if_addrlen in the DR>generic code to cope with this correctly. Sorry to step in that late, but I'm currently moving jobs. I had the same comment. The ARP table could be used for the various IP over ATM address mappings. In that case it needs to support 20 byte NSAPs with and optional subaddress (also 20 byte) and variable size E.164 addresses. harti From owner-freebsd-net@FreeBSD.ORG Tue May 18 01:48: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 A0A2A16A4CE; Tue, 18 May 2004 01:48:31 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F89F43D54; Tue, 18 May 2004 01:48:29 -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 i4I8mTgd002554; Tue, 18 May 2004 01:48:29 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4I8mSkM002553; Tue, 18 May 2004 01:48:28 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 01:48:28 -0700 From: Luigi Rizzo To: Harti Brandt Message-ID: <20040518014828.B2380@xorpc.icir.org> References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from harti@freebsd.org on Tue, May 18, 2004 at 10:24:26AM +0200 cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 18 May 2004 08:48:31 -0000 I will try to remove as many assumptions as possible. thanks for the feedback. cheers luigi On Tue, May 18, 2004 at 10:24:26AM +0200, Harti Brandt wrote: > On Sun, 16 May 2004, Doug Rabson wrote: > > DR>On Sunday 25 April 2004 17:49, Luigi Rizzo wrote: > DR>> Here is a snapshot of the new arp code that i have been working on > DR>> lately, based a on Andre's ideas. (I say 'ARP' for brevity, what i > DR>> mean is the layer3-to-layer2 address translation code -- arp, aarp, > DR>> nd6 all fit in the category). > DR> > DR>Sorry for the delay but I've only just had reason to look at the arp > DR>code since I've recently been working on an implementation of rfc2734 > DR>IP over firewire. In your patch, you assume that the size of the > DR>link-level address is always six bytes. This assumption is not valid - > DR>from the looks of the existing arp code, people went to great lengths > DR>to avoid making this assumption throughout the networking code. > DR> > DR>For IP over firewire, the link-level address is sixteen bytes. Other > DR>link types have various sizes. You must use ifp->if_addrlen in the > DR>generic code to cope with this correctly. > > Sorry to step in that late, but I'm currently moving jobs. > > I had the same comment. The ARP table could be used for the various IP > over ATM address mappings. In that case it needs to support 20 byte NSAPs > with and optional subaddress (also 20 byte) and variable size E.164 > addresses. > > harti > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 18 01:55: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 D5AED16A4CE for ; Tue, 18 May 2004 01:55:22 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE8A43D5D for ; Tue, 18 May 2004 01:55:20 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4I8tHa4096831 for ; Tue, 18 May 2004 16:55:17 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40A9CF72.85E2EC9D@kuzbass.ru> Date: Tue, 18 May 2004 16:55:14 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: multicast arp entry 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, 18 May 2004 08:55:22 -0000 Hi! route -n monitor shows me: got message of size 236 on Tue May 18 16:42:26 2004 RTM_ADD: Add Route: len 236, pid: 0, seq 0, errno 0, flags: locks: inits: sockaddrs: 224.0.0.9 1.0.5e.0.0.9 em3:0.7.e9.1f.f1.de 172.20.2.75 After that arp -an shows: (224.0.0.9) at 01:00:5e:00:00:09 on em3 permanent [ethernet] Then tcpdump shows that multicast packets with source IP of interface em1 (those must be directed via em1) go out through em3. I run quagga/ripd (same effect for zebra) on FreeBSD 4.9-STABLE. How do I find who installs this route? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue May 18 02:24:43 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 57CCD16A4CE for ; Tue, 18 May 2004 02:24:43 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C78B43D55 for ; Tue, 18 May 2004 02:24:41 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 776ABACADB; Tue, 18 May 2004 11:24:39 +0200 (CEST) Date: Tue, 18 May 2004 11:24:39 +0200 From: Pawel Jakub Dawidek To: freebsd-net@freebsd.org Message-ID: <20040518092439.GF845@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5lVNUoiW0yyvItcX" 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 Subject: ia_netbroadcast 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, 18 May 2004 09:24:43 -0000 --5lVNUoiW0yyvItcX Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Do we still need ia_netboradcast field? It is calculated depending on old-fashion classes (A, B, C). Is it used still? I wonder if ia_broadaddr isn't sufficient today. IP netmask ia_broadaddr ia_netbroadcast 10.0.0.101 255.0.0.0 10.255.255.255 10.255.255.255 1.0.0.2 255.255.255.252 1.0.0.3 1.255.255.255 2.0.0.1 255.255.0.0 2.0.255.255 2.255.255.255 I'm planing to work on removing O(n) from interface aliases search. Now every incoming packet have to be compared with every single broadcast from every single alias. When I tested something and there were ~10000 aliases on interface it worked really slow. This slowdown probably exists in more places. It exists in NetBSD and OpenBSD as well. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --5lVNUoiW0yyvItcX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqdZXForvXbEpPzQRAipgAJ9mC+kvUyumgPdbSt34JSeGX2gwkgCg6auE 841Wxuy2A8Ya+tPeOPbutb8= =iMqe -----END PGP SIGNATURE----- --5lVNUoiW0yyvItcX-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 02:38: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 7607C16A4CE for ; Tue, 18 May 2004 02:38:40 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC9643D3F for ; Tue, 18 May 2004 02:38:39 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4I9cbT1000931 for ; Tue, 18 May 2004 17:38:37 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40A9D99A.34AA675D@kuzbass.ru> Date: Tue, 18 May 2004 17:38:34 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: in_cksum_skip 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, 18 May 2004 09:38:40 -0000 Hi! src/sys/i386/i386/in_cksum.c floods my logs with 'in_cksum_skip: out of data by NUMBER' messages. The router has 5 em interfaces and works basically Ok. Should I worry about these messages? If yes, what do they mean? If not, shouldn't they be logged with log() instead of printf() so one can filter them out using syslogd? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue May 18 02:43: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 BE7BF16A4CE; Tue, 18 May 2004 02:43:48 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D5643D60; Tue, 18 May 2004 02:43:46 -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 i4I9hkgd005161; Tue, 18 May 2004 02:43:46 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4I9hkof005160; Tue, 18 May 2004 02:43:46 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 02:43:46 -0700 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20040518024346.A5068@xorpc.icir.org> References: <20040518092439.GF845@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040518092439.GF845@darkness.comp.waw.pl>; from pjd@freebsd.org on Tue, May 18, 2004 at 11:24:39AM +0200 cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 18 May 2004 09:43:48 -0000 On Tue, May 18, 2004 at 11:24:39AM +0200, Pawel Jakub Dawidek wrote: > Hi. > > Do we still need ia_netboradcast field? It is calculated depending on > old-fashion classes (A, B, C). Is it used still? > I wonder if ia_broadaddr isn't sufficient today. not just that, it seems that ia_netboradcast contains bogus info. This said, how do you plan to handle the alias search, by implementing a per-interface hash table containing the addresses and broadcast addresses ? cheers luigi > IP netmask ia_broadaddr ia_netbroadcast > 10.0.0.101 255.0.0.0 10.255.255.255 10.255.255.255 > 1.0.0.2 255.255.255.252 1.0.0.3 1.255.255.255 > 2.0.0.1 255.255.0.0 2.0.255.255 2.255.255.255 > > I'm planing to work on removing O(n) from interface aliases search. > Now every incoming packet have to be compared with every single > broadcast from every single alias. When I tested something and > there were ~10000 aliases on interface it worked really slow. > > This slowdown probably exists in more places. It exists in NetBSD and > OpenBSD as well. > > -- > Pawel Jakub Dawidek http://www.FreeBSD.org > pjd@FreeBSD.org http://garage.freebsd.pl > FreeBSD committer Am I Evil? Yes, I Am! From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:05: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 1B13B16A4CE for ; Tue, 18 May 2004 03:05:12 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C9D43D6B for ; Tue, 18 May 2004 03:05:04 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 30A5BACAF1; Tue, 18 May 2004 12:05:03 +0200 (CEST) Date: Tue, 18 May 2004 12:05:03 +0200 From: Pawel Jakub Dawidek To: Luigi Rizzo Message-ID: <20040518100503.GG845@darkness.comp.waw.pl> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="g+nE7Lp8ucACtfsu" Content-Disposition: inline In-Reply-To: <20040518024346.A5068@xorpc.icir.org> 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: ia_netbroadcast 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, 18 May 2004 10:05:12 -0000 --g+nE7Lp8ucACtfsu Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 02:43:46AM -0700, Luigi Rizzo wrote: +> On Tue, May 18, 2004 at 11:24:39AM +0200, Pawel Jakub Dawidek wrote: +> > Hi. +> >=20 +> > Do we still need ia_netboradcast field? It is calculated depending on +> > old-fashion classes (A, B, C). Is it used still? +> > I wonder if ia_broadaddr isn't sufficient today. +>=20 +> not just that, it seems that ia_netboradcast contains bogus info. So? +> This said, how do you plan to handle the alias search, by +> implementing a per-interface hash table containing the +> addresses and broadcast addresses ? First I want to find all places that need fast processing and it probably needs hash tables for IPs and broadcasts, but I'm not sure if that's all. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --g+nE7Lp8ucACtfsu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqd/PForvXbEpPzQRAmchAKCQHB8KmMY3RH17R+21D90U9yD2SACfSn4M BXBbVPX6t6OmvEewUf1/Lc0= =22i5 -----END PGP SIGNATURE----- --g+nE7Lp8ucACtfsu-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:09:57 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 8AB6A16A4CE for ; Tue, 18 May 2004 03:09:57 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A64E43D53 for ; Tue, 18 May 2004 03:09:49 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 90717 invoked from network); 18 May 2004 10:09:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 18 May 2004 10:09:47 -0000 Message-ID: <40A9E0ED.4FD479BD@freebsd.org> Date: Tue, 18 May 2004 12:09:49 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20040518092439.GF845@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 18 May 2004 10:09:57 -0000 Pawel Jakub Dawidek wrote: > > Hi. > > Do we still need ia_netboradcast field? It is calculated depending on > old-fashion classes (A, B, C). Is it used still? > I wonder if ia_broadaddr isn't sufficient today. Yes, it should be sufficient and the ia_netbroadcast field doesn't serve any special purpose anymore since it wrong most of the time anyway. The only problem you could run into is Windoze stuff. They still use it extensively and will broadcast their NetBIOS stuff always on the classful netmask. I don't know how much Samba and such depend on this. You'll have to check. > IP netmask ia_broadaddr ia_netbroadcast > 10.0.0.101 255.0.0.0 10.255.255.255 10.255.255.255 > 1.0.0.2 255.255.255.252 1.0.0.3 1.255.255.255 > 2.0.0.1 255.255.0.0 2.0.255.255 2.255.255.255 > > I'm planing to work on removing O(n) from interface aliases search. > Now every incoming packet have to be compared with every single > broadcast from every single alias. When I tested something and > there were ~10000 aliases on interface it worked really slow. There are two ways I see to optimize this. One is to use a hash for the broadcast addresses too as with the IP address. The second is to go only into this loop if the packet was actually received on an link level broadcast address (M_BCAST flag in mbuf packet header). However this might work only for ieee802-type interfaces. > This slowdown probably exists in more places. It exists in NetBSD and > OpenBSD as well. -- Andre [patch to netinet/ip_fastfwd.c but same to ip_input.c] /* * Or is it for a local IP broadcast address on this host? */ if ((m->m_flags & M_BCAST) && (m->m_pkthdr.rcvif->if_flags & IFF_BROADCAST)) { TAILQ_FOREACH(ifa, &m->m_pkthdr.rcvif->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != AF_INET) continue; ia = ifatoia(ifa); if (ia->ia_netbroadcast.s_addr == ip->ip_dst.s_addr) return 0; if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == ip->ip_dst.s_addr) return 0; } } From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:45: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 E616E16A4CE for ; Tue, 18 May 2004 03:45:14 -0700 (PDT) Received: from hotmail.com (bay3-dav138.bay3.hotmail.com [65.54.169.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B4B643D5E for ; Tue, 18 May 2004 03:44:53 -0700 (PDT) (envelope-from wienne@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 May 2004 03:44:53 -0700 Received: from 61.242.173.156 by bay3-dav138.bay3.hotmail.com with DAV; Tue, 18 May 2004 10:44:53 +0000 X-Originating-IP: [61.242.173.156] X-Originating-Email: [wienne@msn.com] X-Sender: wienne@msn.com From: "=?gb2312?B?0KHA882s1r4=?=" To: Date: Wed, 19 May 2004 18:44:46 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQ9jkYpoa+70qfKRDeoU2JjV4g4hA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 18 May 2004 10:44:53.0332 (UTC) FILETIME=[26F96940:01C43CC5] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: mpd help 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, 18 May 2004 10:45:15 -0000 vpn server A and B 'mpd.conf' is sameness Version 3.15 ----------------------- client_standard: set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set bundle enable encryption set bundle enable compression set ccp yes mppc set ccp yes mpp-compress set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set ecp yes des ----------------------- client cannot dial in A server, sticking point: [pptp1] can't config mppc node at bypass.compress: Protocol not supported mpd log is ... mpd: PPTP connection from 172.16.12.100:3986 pptp0: attached to connection with 172.16.12.100:3986 [pptp1] IFACE: Open event [pptp1] IPCP: Open event [pptp1] IPCP: state change Initial --> Starting [pptp1] IPCP: LayerStart [pptp1] IPCP: Open event [pptp1] bundle: OPEN event in state CLOSED [pptp1] opening link pptp1... [pptp1] link: OPEN event [pptp1] LCP: Open event [pptp1] LCP: state change Initial --> Starting [pptp1] LCP: LayerStart [pptp1] device: OPEN event in state DOWN [pptp1] attaching to peer's outgoing call [pptp1] device is now in state OPENING [pptp1] device: UP event in state OPENING [pptp1] device is now in state UP [pptp1] link: UP event [pptp1] link: origination is remote [pptp1] LCP: Up event [pptp1] LCP: state change Starting --> Req-Sent [pptp1] LCP: phase shift DEAD --> ESTABLISH [pptp1] LCP: SendConfigReq #55 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM ab82d080 AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 0 e8 10 2a 74 pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Configure Request #0 link 0 (Req-Sent) MRU 1400 MAGICNUM 42a16685 PROTOCOMP ACFCOMP CALLBACK Not supported [pptp1] LCP: SendConfigRej #0 CALLBACK [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) MRU 1400 MAGICNUM 42a16685 PROTOCOMP ACFCOMP [pptp1] LCP: SendConfigAck #1 MRU 1400 MAGICNUM 42a16685 PROTOCOMP ACFCOMP [pptp1] LCP: state change Req-Sent --> Ack-Sent [pptp1] LCP: SendConfigReq #56 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM ab82d080 AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 0 e8 10 2a 74 [pptp1] LCP: rec'd Configure Reject #56 link 0 (Ack-Sent) MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 0 e8 10 2a 74 [pptp1] LCP: SendConfigReq #57 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM ab82d080 AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: rec'd Configure Ack #57 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM ab82d080 AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: state change Ack-Sent --> Opened [pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE [pptp1] LCP: auth: peer wants nothing, I want CHAP [pptp1] CHAP: sending CHALLENGE [pptp1] LCP: LayerUp pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Ident #2 link 0 (Opened) MESG: MSRASV5.10 [pptp1] LCP: rec'd Ident #3 link 0 (Opened) MESG: MSRAS-0-SUNJUN [pptp1] CHAP: rec'd RESPONSE #1 Name: sunjun@egotop.com Peer name: sunjun@egotop.com Response is valid [pptp1] CHAP: sending SUCCESS [pptp1] LCP: authorization successful [pptp1] LCP: phase shift AUTHENTICATE --> NETWORK [pptp1] setting interface ng0 MTU to 1400 bytes [pptp1] up: 1 link, total bandwidth 64000 bps [pptp1] IPCP: Up event [pptp1] IPCP: state change Starting --> Req-Sent [pptp1] IPCP: SendConfigReq #23 IPADDR 172.16.100.225 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] CCP: Open event [pptp1] CCP: state change Initial --> Starting [pptp1] CCP: LayerStart [pptp1] CCP: Up event [pptp1] CCP: state change Starting --> Req-Sent [pptp1] CCP: SendConfigReq #34 [pptp1] CCP: Checking wether 40 bits are enabled -> yes [pptp1] CCP: Checking wether 56 bits are enabled -> yes [pptp1] CCP: Checking wether 128 bits are enabled -> yes MPPC 0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] ECP: Open event [pptp1] ECP: state change Initial --> Starting [pptp1] ECP: LayerStart [pptp1] ECP: Up event [pptp1] ECP: state change Starting --> Req-Sent [pptp1] ECP: SendConfigReq #14 [pptp1] CCP: rec'd Configure Request #4 link 0 (Req-Sent) MPPC 0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] CCP: Checking wether 40 bits are acceptable -> yes [pptp1] CCP: Checking wether 56 bits are acceptable -> yes [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigNak #4 MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] IPCP: rec'd Configure Request #5 link 0 (Req-Sent) IPADDR 0.0.0.0 NAKing with 172.16.100.241 PRIDNS 0.0.0.0 NAKing with 172.16.100.225 PRINBNS 0.0.0.0 NAKing with 172.16.100.225 SECDNS 0.0.0.0 SECNBNS 0.0.0.0 [pptp1] IPCP: SendConfigRej #5 SECDNS 0.0.0.0 SECNBNS 0.0.0.0 [pptp1] IPCP: rec'd Configure Reject #23 link 0 (Req-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] IPCP: SendConfigReq #24 IPADDR 172.16.100.225 [pptp1] CCP: rec'd Configure Nak #34 link 0 (Req-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: SendConfigReq #35 [pptp1] CCP: Checking wether 40 bits are enabled -> no [pptp1] CCP: Checking wether 56 bits are enabled -> no [pptp1] CCP: Checking wether 128 bits are enabled -> yes MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: rec'd Configure Request #6 link 0 (Req-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigAck #6 MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: state change Req-Sent --> Ack-Sent [pptp1] IPCP: rec'd Configure Request #7 link 0 (Req-Sent) IPADDR 0.0.0.0 NAKing with 172.16.100.241 PRIDNS 0.0.0.0 NAKing with 172.16.100.225 PRINBNS 0.0.0.0 NAKing with 172.16.100.225 [pptp1] IPCP: SendConfigNak #7 IPADDR 172.16.100.241 PRIDNS 172.16.100.225 PRINBNS 172.16.100.225 [pptp1] IPCP: rec'd Configure Ack #24 link 0 (Req-Sent) IPADDR 172.16.100.225 [pptp1] IPCP: state change Req-Sent --> Ack-Rcvd [pptp1] CCP: rec'd Configure Ack #35 link 0 (Ack-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: state change Ack-Sent --> Opened [pptp1] CCP: LayerUp [pptp1] can't config mppc node at bypass.compress: Protocol not supported ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [pptp1] CCP: compression init failed [pptp1] CCP: parameter negotiation failed [pptp1] CCP: Close event [pptp1] CCP: state change Opened --> Closing [pptp1] CCP: SendTerminateReq #36 [pptp1] CCP: LayerDown [pptp1] CCP: state change Closing --> Closed [pptp1] CCP: LayerFinish [pptp1] IPCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) IPADDR 172.16.100.241 172.16.100.241 is OK PRIDNS 172.16.100.225 PRINBNS 172.16.100.225 [pptp1] IPCP: SendConfigAck #8 IPADDR 172.16.100.241 PRIDNS 172.16.100.225 PRINBNS 172.16.100.225 [pptp1] IPCP: state change Ack-Rcvd --> Opened [pptp1] IPCP: LayerUp 172.16.100.225 -> 172.16.100.241 [pptp1] IFACE: Up event [pptp1] setting interface ng0 MTU to 1398 bytes [pptp1] exec: /sbin/ifconfig ng0 172.16.100.225 172.16.100.241 netmask 0xffffffff #NAME? [pptp1] exec: /usr/sbin/arp #NAME? 172.16.100.241 0:0:e8:10:2a:74 pub [pptp1] exec: /sbin/route add 172.16.100.225 #NAME? lo0 [pptp1] exec: /data/iServer/SysTools/config/mpdserver.sh ng0 inet 172.16.100.225 172.16.100.241 wienne@163.com [pptp1] IFACE: Up event [pptp1] CCP: rec'd Terminate Ack #36 link 0 (Closed) pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Terminate Request #9 link 0 (Opened) [pptp1] LCP: state change Opened --> Stopping [pptp1] LCP: phase shift NETWORK --> TERMINATE [pptp1] setting interface ng0 MTU to 1500 bytes [pptp1] up: 0 links, total bandwidth 9600 bps [pptp1] IPCP: Down event [pptp1] IPCP: state change Opened --> Starting [pptp1] IPCP: LayerDown [pptp1] IFACE: Down event [pptp1] exec: /sbin/route delete 172.16.100.225 #NAME? lo0 [pptp1] exec: /usr/sbin/arp #NAME? 172.16.100.241 [pptp1] exec: /sbin/ifconfig ng0 down delete #NAME? [pptp1] CCP: Down event [pptp1] CCP: state change Closed --> Initial [pptp1] CCP: Close event [pptp1] ECP: Down event [pptp1] ECP: state change Req-Sent --> Starting [pptp1] ECP: Close event [pptp1] ECP: state change Starting --> Initial [pptp1] ECP: LayerFinish [pptp1] LCP: SendTerminateAck #58 [pptp1] LCP: LayerDown [pptp1] LCP: rec'd Terminate Request #10 link 0 (Stopping) [pptp1] LCP: SendTerminateAck #59 [pptp1] LCP: state change Stopping --> Stopped [pptp1] LCP: phase shift TERMINATE --> ESTABLISH [pptp1] LCP: LayerFinish [pptp1] device: CLOSE event in state UP pptp0-0: clearing call pptp0-0: killing channel [pptp1] PPTP call terminated [pptp1] IFACE: Close event [pptp1] IPCP: Close event [pptp1] IPCP: state change Starting --> Initial [pptp1] IPCP: LayerFinish [pptp1] IFACE: Close event pptp0: closing connection with 172.16.12.100:3986 [pptp1] IFACE: Close event [pptp1] device is now in state CLOSING [pptp1] bundle: CLOSE event in state OPENED [pptp1] closing link pptp1... [pptp1] device: DOWN event in state CLOSING [pptp1] device is now in state DOWN [pptp1] link: CLOSE event [pptp1] LCP: Close event [pptp1] LCP: state change Stopped --> Closed [pptp1] device: DOWN event in state DOWN [pptp1] device is now in state DOWN pptp0: killing connection with 172.16.12.100:3986 [pptp1] link: DOWN event [pptp1] LCP: Down event [pptp1] LCP: state change Closed --> Initial [pptp1] LCP: phase shift ESTABLISH --> DEAD [pptp1] link: DOWN event [pptp1] LCP: Down event client can dial in B server, mpd log is ... mpd: PPTP connection from 172.16.12.100:3991 pptp0: attached to connection with 172.16.12.100:3991 [pptp1] IFACE: Open event [pptp1] IPCP: Open event [pptp1] IPCP: state change Initial --> Starting [pptp1] IPCP: LayerStart [pptp1] IPCP: Open event [pptp1] bundle: OPEN event in state CLOSED [pptp1] opening link pptp1... [pptp1] link: OPEN event [pptp1] LCP: Open event [pptp1] LCP: state change Initial --> Starting [pptp1] LCP: LayerStart [pptp1] device: OPEN event in state DOWN [pptp1] attaching to peer's outgoing call [pptp1] device is now in state OPENING [pptp1] device: UP event in state OPENING [pptp1] device is now in state UP [pptp1] link: UP event [pptp1] link: origination is remote [pptp1] LCP: Up event [pptp1] LCP: state change Starting --> Req-Sent [pptp1] LCP: phase shift DEAD --> ESTABLISH [pptp1] LCP: SendConfigReq #145 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM f6e0a9fe AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 5 b7 1 6b ed pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Configure Request #0 link 0 (Req-Sent) MRU 1400 MAGICNUM 51974974 PROTOCOMP ACFCOMP CALLBACK Not supported [pptp1] LCP: SendConfigRej #0 CALLBACK [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) MRU 1400 MAGICNUM 51974974 PROTOCOMP ACFCOMP [pptp1] LCP: SendConfigAck #1 MRU 1400 MAGICNUM 51974974 PROTOCOMP ACFCOMP [pptp1] LCP: state change Req-Sent --> Ack-Sent [pptp1] LCP: SendConfigReq #146 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM f6e0a9fe AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 5 b7 1 6b ed [pptp1] LCP: rec'd Configure Reject #146 link 0 (Ack-Sent) MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 0 5 b7 1 6b ed [pptp1] LCP: SendConfigReq #147 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM f6e0a9fe AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: rec'd Configure Ack #147 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM f6e0a9fe AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: state change Ack-Sent --> Opened [pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE [pptp1] LCP: auth: peer wants nothing, I want CHAP [pptp1] CHAP: sending CHALLENGE [pptp1] LCP: LayerUp [pptp1] LCP: rec'd Ident #2 link 0 (Opened) MESG: MSRASV5.10 pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Ident #3 link 0 (Opened) MESG: MSRAS-0-SUNJUN [pptp1] CHAP: rec'd RESPONSE #1 Name: sunjun@egotop.com Peer name: sunjun@egotop.com Response is valid [pptp1] CHAP: sending SUCCESS [pptp1] LCP: authorization successful [pptp1] LCP: phase shift AUTHENTICATE --> NETWORK [pptp1] setting interface ng0 MTU to 1400 bytes [pptp1] up: 1 link, total bandwidth 64000 bps [pptp1] IPCP: Up event [pptp1] IPCP: state change Starting --> Req-Sent [pptp1] IPCP: SendConfigReq #56 IPADDR 172.16.1.5 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] CCP: Open event [pptp1] CCP: state change Initial --> Starting [pptp1] CCP: LayerStart [pptp1] CCP: Up event [pptp1] CCP: state change Starting --> Req-Sent [pptp1] CCP: SendConfigReq #97 [pptp1] CCP: Checking wether 40 bits are enabled -> yes [pptp1] CCP: Checking wether 56 bits are enabled -> yes [pptp1] CCP: Checking wether 128 bits are enabled -> yes MPPC 0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] ECP: Open event [pptp1] ECP: state change Initial --> Starting [pptp1] ECP: LayerStart [pptp1] ECP: Up event [pptp1] ECP: state change Starting --> Req-Sent [pptp1] ECP: SendConfigReq #89 [pptp1] CCP: rec'd Configure Request #4 link 0 (Req-Sent) MPPC 0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] CCP: Checking wether 40 bits are acceptable -> yes [pptp1] CCP: Checking wether 56 bits are acceptable -> yes [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigNak #4 MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] IPCP: rec'd Configure Request #5 link 0 (Req-Sent) IPADDR 0.0.0.0 NAKing with 172.16.3.1 PRIDNS 0.0.0.0 NAKing with 172.16.1.5 PRINBNS 0.0.0.0 NAKing with 172.16.1.11 SECDNS 0.0.0.0 NAKing with 172.16.1.11 SECNBNS 0.0.0.0 NAKing with 172.16.1.240 [pptp1] IPCP: SendConfigNak #5 IPADDR 172.16.3.1 PRIDNS 172.16.1.5 PRINBNS 172.16.1.11 SECDNS 172.16.1.11 SECNBNS 172.16.1.240 [pptp1] IPCP: rec'd Configure Reject #56 link 0 (Req-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] IPCP: SendConfigReq #57 IPADDR 172.16.1.5 [pptp1] CCP: rec'd Configure Nak #97 link 0 (Req-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: SendConfigReq #98 [pptp1] CCP: Checking wether 40 bits are enabled -> no [pptp1] CCP: Checking wether 56 bits are enabled -> no [pptp1] CCP: Checking wether 128 bits are enabled -> yes MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] LCP: rec'd Protocol Reject #6 link 0 (Opened) [pptp1] LCP: protocol ECP was rejected [pptp1] ECP: protocol was rejected by peer [pptp1] ECP: state change Req-Sent --> Stopped [pptp1] ECP: LayerFinish [pptp1] CCP: rec'd Configure Request #7 link 0 (Req-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: Checking wether 128 bits are acceptable -> yes [pptp1] CCP: SendConfigAck #7 MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: state change Req-Sent --> Ack-Sent [pptp1] IPCP: rec'd Configure Request #8 link 0 (Req-Sent) IPADDR 172.16.3.1 172.16.3.1 is OK PRIDNS 172.16.1.5 PRINBNS 172.16.1.11 SECDNS 172.16.1.11 SECNBNS 172.16.1.240 [pptp1] IPCP: SendConfigAck #8 IPADDR 172.16.3.1 PRIDNS 172.16.1.5 PRINBNS 172.16.1.11 SECDNS 172.16.1.11 SECNBNS 172.16.1.240 [pptp1] IPCP: state change Req-Sent --> Ack-Sent [pptp1] IPCP: rec'd Configure Ack #57 link 0 (Ack-Sent) IPADDR 172.16.1.5 [pptp1] IPCP: state change Ack-Sent --> Opened [pptp1] IPCP: LayerUp 172.16.1.5 -> 172.16.3.1 [pptp1] IFACE: Up event [pptp1] setting interface ng0 MTU to 1216 bytes [pptp1] exec: /sbin/ifconfig ng0 172.16.1.5 172.16.3.1 netmask 0xffffffff #NAME? [pptp1] exec: /usr/sbin/arp #NAME? 172.16.3.1 0:5:b7:1:6b:ed pub [pptp1] exec: /sbin/route add 172.16.1.5 #NAME? lo0 [pptp1] exec: /etc/mpdr.sh ng0 inet 172.16.1.5 172.16.3.1 sunjun@egotop.com [pptp1] IFACE: Up event [pptp1] CCP: rec'd Configure Ack #98 link 0 (Ack-Sent) MPPC 0x01000041: MPPC MPPE, 128 bit, stateless [pptp1] CCP: state change Ack-Sent --> Opened [pptp1] CCP: LayerUp [pptp1] can't config mppc node at bypass.compress: Protocol not supported [pptp1] CCP: compression init failed [pptp1] CCP: parameter negotiation failed [pptp1] CCP: Close event [pptp1] CCP: state change Opened --> Closing [pptp1] CCP: SendTerminateReq #99 [pptp1] CCP: LayerDown [pptp1] CCP: state change Closing --> Closed [pptp1] CCP: LayerFinish [pptp1] rec'd unexpected protocol COMPD on link 0 message repeated 2 times [pptp1] CCP: rec'd Terminate Ack #99 link 0 (Closed) A server what's wrong ????? From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:47:57 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 2F75116A4CE; Tue, 18 May 2004 03:47:57 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC52943D5C; Tue, 18 May 2004 03:47:56 -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 i4IAlugd009863; Tue, 18 May 2004 03:47:56 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4IAluZP009862; Tue, 18 May 2004 03:47:56 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 03:47:56 -0700 From: Luigi Rizzo To: Pawel Jakub Dawidek Message-ID: <20040518034756.A9648@xorpc.icir.org> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040518100503.GG845@darkness.comp.waw.pl>; from pjd@freebsd.org on Tue, May 18, 2004 at 12:05:03PM +0200 cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 18 May 2004 10:47:57 -0000 On Tue, May 18, 2004 at 12:05:03PM +0200, Pawel Jakub Dawidek wrote: ... > +> > Do we still need ia_netboradcast field? It is calculated depending on > +> > old-fashion classes (A, B, C). Is it used still? > +> > I wonder if ia_broadaddr isn't sufficient today. > +> > +> not just that, it seems that ia_netboradcast contains bogus info. > > So? nuke it! Also if, as Andre said, it might be used by windows apps, one could certainly compute it on the fly from the IP address. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue May 18 03:51: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 24FDB16A4CE for ; Tue, 18 May 2004 03:51:33 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7574343D5E for ; Tue, 18 May 2004 03:51:31 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4IAut4I058574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 13:56:57 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4IApYhS071075; Tue, 18 May 2004 13:51:34 +0300 (EEST) (envelope-from ru) Date: Tue, 18 May 2004 13:51:34 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040518105134.GC70919@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <40A9CF72.85E2EC9D@kuzbass.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 18 May 2004 10:51:33 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 04:55:14PM +0800, Eugene Grosbein wrote: > Hi! >=20 > route -n monitor shows me: >=20 > got message of size 236 on Tue May 18 16:42:26 2004=20 > RTM_ADD: Add Route: len 236, pid: 0, seq 0, errno 0, > flags: > locks: inits: > sockaddrs: > 224.0.0.9 1.0.5e.0.0.9 em3:0.7.e9.1f.f1.de 172.20.2.75 >=20 > After that arp -an shows: > (224.0.0.9) at 01:00:5e:00:00:09 on em3 permanent [ethernet] >=20 > Then tcpdump shows that multicast packets with source IP of interface em1 > (those must be directed via em1) go out through em3. I run quagga/ripd > (same effect for zebra) on FreeBSD 4.9-STABLE. >=20 > How do I find who installs this route? >=20 The short answer is: the kernel adds it for you, automatically, just as it does this for you for normal unicast destinations. The long answer could be: you could join to a single multicast group on multiple interfaces, and you will be able to receive multicast on all of them, but if you don't have multicast forwarding enabled, only one interface will be used for sending. Which one gets used will be determined by a normal routing lookup, i.e., ``route -vn get -host 224.0.0.9'' where no entry yet exists. Then, when the actual packet gets delivered, the kernel will insert the corresponding ARP entry, mapping the multicast group address to a MAC address. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqeq2Ukv4P6juNwoRAg4mAJ4zhPiigkN+bvWEbJOvM4eIcQIUQwCbBwsd UGaS22ZxuJUtBaT3MmjAObk= =sV+o -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 04:50: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 8A16B16A4CE for ; Tue, 18 May 2004 04:50:19 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2929643DC2 for ; Tue, 18 May 2004 03:58:17 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4IB3cHg059205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 14:03:40 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4IAwHRK071122; Tue, 18 May 2004 13:58:17 +0300 (EEST) (envelope-from ru) Date: Tue, 18 May 2004 13:58:17 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040518105817.GD70919@ip.net.ua> References: <40A9D99A.34AA675D@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="veXX9dWIonWZEC6h" Content-Disposition: inline In-Reply-To: <40A9D99A.34AA675D@kuzbass.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: in_cksum_skip 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, 18 May 2004 11:50:19 -0000 --veXX9dWIonWZEC6h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 05:38:34PM +0800, Eugene Grosbein wrote: > Hi! >=20 > src/sys/i386/i386/in_cksum.c floods my logs with=20 > 'in_cksum_skip: out of data by NUMBER' messages. >=20 > The router has 5 em interfaces and works basically Ok. > Should I worry about these messages? If yes, what do they mean? > If not, shouldn't they be logged with log() instead of printf() > so one can filter them out using syslogd? >=20 Going into telepathy mode. You're apparently experimenting with IP multicasting. There was a bug with this effect I introduced in ip_output.c,v 1.99.2.43, and shortly fixed it in rev. 1.99.2.44. Check that your revision is not vulnerable. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --veXX9dWIonWZEC6h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqexJUkv4P6juNwoRAhduAJ48I5dM7bVBJpLn0OqmGKziL8A39QCfe7Kr CuYZALEHVv+DpRVQG9DIX9o= =1zsW -----END PGP SIGNATURE----- --veXX9dWIonWZEC6h-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 05:04: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 1183416A4CE for ; Tue, 18 May 2004 05:04:15 -0700 (PDT) Received: from mail.startatom.ru (helios.startatom.ru [62.33.65.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8952D43D7F for ; Tue, 18 May 2004 05:01:27 -0700 (PDT) (envelope-from lan_mailing@startatom.ru) Received: from localhost (localhost.startatom.ru [127.0.0.1]) by mail.startatom.ru (Postfix) with ESMTP id D99647DD43; Tue, 18 May 2004 16:00:03 +0400 (MSD) Received: from mail.startatom.ru ([127.0.0.1]) by localhost (helios.startatom.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91791-07; Tue, 18 May 2004 16:00:03 +0400 (MSD) Received: from [192.168.253.240] (zeus.startatom.ru [62.33.65.2]) by mail.startatom.ru (Postfix) with ESMTP id C04807DD19 for ; Tue, 18 May 2004 16:00:03 +0400 (MSD) Date: Tue, 18 May 2004 15:59:29 +0400 From: Alexander Lunyov X-Priority: 3 (Normal) Message-ID: <1904933465.20040518155929@startatom.ru> To: freebsd-net@freebsd.org In-Reply-To: <384220065.20040517211704@startatom.ru> References: <1373993879.20040517152020@startatom.ru> <384220065.20040517211704@startatom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at startatom.ru Subject: [SOLVED] ppp receiving wrong device number (cuaa10 instead of cuaaa, cuaa15 instead of cuaaf) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Lunyov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 12:04:15 -0000 Hello freebsd-net, This problem was solved by running dev_mkdb (thanks to all those fido7.ru.unix.bsd guys who helped me and especially to Alex Semenyaka). This problem have some relation to PR/66791. -- Best regards, Alexander mailto:lan_mailing@startatom.ru From owner-freebsd-net@FreeBSD.ORG Tue May 18 05:54: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 EED1816A4CE for ; Tue, 18 May 2004 05:54:04 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EA1543DB2 for ; Tue, 18 May 2004 05:53:59 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 90A0DAC96A; Tue, 18 May 2004 13:39:43 +0200 (CEST) Date: Tue, 18 May 2004 13:39:43 +0200 From: Pawel Jakub Dawidek To: Luigi Rizzo Message-ID: <20040518113943.GI845@darkness.comp.waw.pl> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <20040518034756.A9648@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KBjcE0k8Zsqds9qm" Content-Disposition: inline In-Reply-To: <20040518034756.A9648@xorpc.icir.org> 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: ia_netbroadcast 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, 18 May 2004 12:54:05 -0000 --KBjcE0k8Zsqds9qm Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 03:47:56AM -0700, Luigi Rizzo wrote: +> On Tue, May 18, 2004 at 12:05:03PM +0200, Pawel Jakub Dawidek wrote: +> ... +> > +> > Do we still need ia_netboradcast field? It is calculated dependin= g on +> > +> > old-fashion classes (A, B, C). Is it used still? +> > +> > I wonder if ia_broadaddr isn't sufficient today. +> > +>=20 +> > +> not just that, it seems that ia_netboradcast contains bogus info. +> >=20 +> > So? +>=20 +> nuke it! +> Also if, as Andre said, it might be used by windows apps, +> one could certainly compute it on the fly from the IP address. I think it will be much better if some of you guys will nuke it, as you understand this code much better than me. Thanks! --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --KBjcE0k8Zsqds9qm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqfX/ForvXbEpPzQRAkWQAKC6FSf5JLSdsol4Mbr/EwI8apZtCgCg1WHb yOcaGelLZ9vwPTrQZ8Q6CWM= =9Rk0 -----END PGP SIGNATURE----- --KBjcE0k8Zsqds9qm-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 06:10: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 0561616A4CE; Tue, 18 May 2004 06:10:14 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC68743D6B; Tue, 18 May 2004 06:09:34 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i4ID0TkM026891; Tue, 18 May 2004 14:00:29 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4ID0SON089216; Tue, 18 May 2004 14:00:28 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Luigi Rizzo In-Reply-To: <20040518014828.B2380@xorpc.icir.org> References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> Content-Type: text/plain Message-Id: <1084885227.23208.3.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 14:00:28 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Harti Brandt cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 18 May 2004 13:10:14 -0000 On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: > I will try to remove as many assumptions as possible. > thanks for the feedback. I think that in your prototype, the only assumption was in struct llentry. I would suggest defining it as something like: struct llentry { struct llentry *lle_next; struct mbuf *la_hold; uint16_t flags; /* see values in if_ether.h */ uint8_t la_preempt; uint8_t la_asked; time_t expire; struct in_addr l3_addr; uint8_t ll_addr[0]; }; Where the allocation of them uses something like 'malloc(sizeof(struct llentry) + ifp->if_addrlen)'. From owner-freebsd-net@FreeBSD.ORG Tue May 18 06: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 7797716A4CE; Tue, 18 May 2004 06:28:47 -0700 (PDT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DC3743D95; Tue, 18 May 2004 06:28:46 -0700 (PDT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id 1612338CBE2; Tue, 18 May 2004 21:05:54 +0800 (CST) Message-ID: <40AA0A30.3020102@gddsn.org.cn> Date: Tue, 18 May 2004 21:05:52 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040409 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: cuaa0&ttyd0's bug? 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, 18 May 2004 13:28:47 -0000 hi,folks: It seems that the ttyd0 isn't the dialin line to login , and the cuaa0 like is both the dialin/out device!under 4.9 above and 5.X .but the ttyd0 work well under 4.8. here is my test: I wanna direct connected two bsd box via a null-modem cable,on a box ,I congfiured the ttys as follow: # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyd0 "/usr/libexec/getty std.9600" dialup on secure ttyd1 "/usr/libexec/getty std.9600" dialup off secure and kill -HUP 1 on the other box , I use cu connenct the box: cu -l /dev/cuaa0 connected and then , nothing more i could recv! but if I confirgure the ttys as below: # The 'dialup' keyword identifies dialin lines to login, fingerd etc. cuaa0 "/usr/libexec/getty std.9600" dialup on secure ttyd1 "/usr/libexec/getty std.9600" dialup off secure and do it like before i do , it worked! why???? It's a bug??? thanks in advance ---------------------- --wsk From owner-freebsd-net@FreeBSD.ORG Tue May 18 06:48: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 D553C16A4CE; Tue, 18 May 2004 06:48:51 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4063743D5F; Tue, 18 May 2004 06:48:50 -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 i4IDmlTu020556; Tue, 18 May 2004 21:48:47 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4IDmlpv020555; Tue, 18 May 2004 21:48:47 +0800 (KRAST) (envelope-from eugen) Date: Tue, 18 May 2004 21:48:47 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040518134847.GB20471@grosbein.pp.ru> References: <40A9D99A.34AA675D@kuzbass.ru> <20040518105817.GD70919@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518105817.GD70919@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: in_cksum_skip 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, 18 May 2004 13:48:51 -0000 On Tue, May 18, 2004 at 01:58:17PM +0300, Ruslan Ermilov wrote: > > The router has 5 em interfaces and works basically Ok. > > Should I worry about these messages? If yes, what do they mean? > > If not, shouldn't they be logged with log() instead of printf() > > so one can filter them out using syslogd? > Going into telepathy mode. > > You're apparently experimenting with IP multicasting. There was > a bug with this effect I introduced in ip_output.c,v 1.99.2.43, > and shortly fixed it in rev. 1.99.2.44. Check that your revision > is not vulnerable. Great hit! I have 1.99.2.43 really. Hail the telepathy! Eugene From owner-freebsd-net@FreeBSD.ORG Tue May 18 07:09: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 2A06516A4CE; Tue, 18 May 2004 07:09:01 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0A4043D55; Tue, 18 May 2004 07:08:59 -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 i4IE8wE3020685; Tue, 18 May 2004 22:08:58 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4IE8wo9020684; Tue, 18 May 2004 22:08:58 +0800 (KRAST) (envelope-from eugen) Date: Tue, 18 May 2004 22:08:58 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040518140857.GC20471@grosbein.pp.ru> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518105134.GC70919@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: multicast arp entry 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, 18 May 2004 14:09:01 -0000 On Tue, May 18, 2004 at 01:51:34PM +0300, Ruslan Ermilov wrote: > The long answer could be: you could join to a single multicast > group on multiple interfaces, and you will be able to receive > multicast on all of them, but if you don't have multicast > forwarding enabled, only one interface will be used for sending. That's bad. How do I enable "multicast forwarding", or, in other words, do you know why ripd doesn't do it for be? On the other hand, I've got another machine with very simple configuration: one fxp0 interface, one rl0 and one gif0 and started quagga/ripd. Two points: tcpdump shows that multicasts go out all three interfaces with right source IP and there is no arp entries for 224.0.0.9 and 224.0.0.1. I couldn't find what is the vital difference between these two machines yet (there are so many of them). Eugene From owner-freebsd-net@FreeBSD.ORG Tue May 18 08:15: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 2C21316A4CE for ; Tue, 18 May 2004 08:15:08 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA9643D4C for ; Tue, 18 May 2004 08:15:06 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4IFKThv091156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 18:20:30 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4IFF7P5072797; Tue, 18 May 2004 18:15:07 +0300 (EEST) (envelope-from ru) Date: Tue, 18 May 2004 18:15:06 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040518151506.GC72684@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <20040518140857.GC20471@grosbein.pp.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 18 May 2004 15:15:08 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 10:08:58PM +0800, Eugene Grosbein wrote: > On Tue, May 18, 2004 at 01:51:34PM +0300, Ruslan Ermilov wrote: >=20 > > The long answer could be: you could join to a single multicast > > group on multiple interfaces, and you will be able to receive > > multicast on all of them, but if you don't have multicast > > forwarding enabled, only one interface will be used for sending. >=20 > That's bad. How do I enable "multicast forwarding", or, in other words, > do you know why ripd doesn't do it for be? >=20 I use mrouted(8). > On the other hand, I've got another machine with very simple configuratio= n: > one fxp0 interface, one rl0 and one gif0 and started quagga/ripd. > Two points: tcpdump shows that multicasts go out all three interfaces > with right source IP and there is no arp entries for 224.0.0.9 and 224.0.= 0.1. >=20 > I couldn't find what is the vital difference between these two machines y= et > (there are so many of them). >=20 I don't know. Perhaps, quagga/ripd send raw IP packets in this case. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqih6Ukv4P6juNwoRApKwAJ9SSx0DEBju+N+i6dAf673Gz9S9OwCeM47h eqmp3OZ14cihNoH7wdUcBYE= =cWNO -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 08:35: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 B289716A4CE; Tue, 18 May 2004 08:35:15 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id C858D43D41; Tue, 18 May 2004 08:35:11 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 7BAFBACBCB; Tue, 18 May 2004 17:35:10 +0200 (CEST) Date: Tue, 18 May 2004 17:35:10 +0200 From: Pawel Jakub Dawidek To: freebsd-performance@freebsd.org Message-ID: <20040518153510.GP845@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M84Mp/hDKELh/AV5" 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 cc: freebsd-current@freebsd.org Subject: Network performance, netperf patches and more. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-performance@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 15:35:15 -0000 --M84Mp/hDKELh/AV5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. At: http://people.freebsd.org/~pjd/netperf/ One can find many interesting network perfromance tests. Comments are welcome. PS. This mail was send to three lists: freebsd-current@freebsd.org freebsd-net@freebsd.org freebsd-performance@freebsd.org but discussion should countinue probably only on freebsd-performance@, so please, remove other lists while replying. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --M84Mp/hDKELh/AV5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqi0uForvXbEpPzQRAuzjAJoCsQDZRHNDI+/kYpkYRK4oUtkfiQCgxQVk ShxG4DFjpzwX23qtIh+Xysc= =Eaes -----END PGP SIGNATURE----- --M84Mp/hDKELh/AV5-- From owner-freebsd-net@FreeBSD.ORG Tue May 18 08:50: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 2D92D16A4CE for ; Tue, 18 May 2004 08:50:14 -0700 (PDT) Received: from smartmx-03.inode.at (smartmx-03.inode.at [213.229.60.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C2F43D46 for ; Tue, 18 May 2004 08:50:13 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from [62.99.226.131] (port=1035 helo=inode.at) by smartmx-03.inode.at with esmtp (Exim 4.30) id 1BQ6r6-0007of-9m; Tue, 18 May 2004 17:50:12 +0200 Message-ID: <40AA30B4.20600@inode.at> Date: Tue, 18 May 2004 17:50:12 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7b) Gecko/20040421 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: =?GB2312?B?0KHA882s1r4=?= References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: mpd help 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, 18 May 2004 15:50:14 -0000 Hi, РЎАуН¬Цѕ schrieb: > vpn server A and B 'mpd.conf' is sameness > > Version 3.15 > > ----------------------- > client_standard: > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set bundle enable encryption > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-compress ^^^^^^^^^^^^^^^^^^^^^^^you enabled STAC compression, wich needs proprietary code, please remove this line. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com ------------------------------ ---------------------------------- "...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 18 09:07: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 05DC316A4CE; Tue, 18 May 2004 09:07:13 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6842F43D62; Tue, 18 May 2004 09:06:48 -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 i4IG6mgd040121; Tue, 18 May 2004 09:06:48 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4IG6mDR040120; Tue, 18 May 2004 09:06:48 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 09:06:47 -0700 From: Luigi Rizzo To: Doug Rabson Message-ID: <20040518090647.A39810@xorpc.icir.org> References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <1084885227.23208.3.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1084885227.23208.3.camel@builder02.qubesoft.com>; from dfr@nlsystems.com on Tue, May 18, 2004 at 02:00:28PM +0100 cc: Harti Brandt cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 18 May 2004 16:07:13 -0000 On Tue, May 18, 2004 at 02:00:28PM +0100, Doug Rabson wrote: > On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: > > I will try to remove as many assumptions as possible. > > thanks for the feedback. > > I think that in your prototype, the only assumption was in struct > llentry. I would suggest defining it as something like: to be really flexible, both l3_addr and ll_addr should be variable size (v4,v6,v8 over 802.x,firewire,appletalk,snail-mail), then things rapidly become confusing and inefficient. I would like to keep the ipv4 over ethernet case simple and quick, even if this means replicating the code for the generic case (and this is one of the reasons i have stalled a bit on this code -- i want to make up my mind on what is a reasonable approaxch). cheers luigi > struct llentry { > struct llentry *lle_next; > struct mbuf *la_hold; > uint16_t flags; /* see values in if_ether.h */ > uint8_t la_preempt; > uint8_t la_asked; > time_t expire; > struct in_addr l3_addr; > uint8_t ll_addr[0]; > }; > > Where the allocation of them uses something like 'malloc(sizeof(struct > llentry) + ifp->if_addrlen)'. > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue May 18 09:21:43 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 C06AD16A4CE; Tue, 18 May 2004 09:21:43 -0700 (PDT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E21B43D1F; Tue, 18 May 2004 09:21:42 -0700 (PDT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i4IGLMj71962; Tue, 18 May 2004 18:21:22 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n81.sp.op.dlr.de (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i4IGLMK153506; Tue, 18 May 2004 18:21:22 +0200 Received: from localhost (brandt@localhost) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i4IGLH816254; Tue, 18 May 2004 18:21:17 +0200 (MET DST) X-Authentication-Warning: zeus.nt.op.dlr.de: brandt owned process doing -bs Date: Tue, 18 May 2004 18:21:17 +0200 (MET DST) From: Harti Brandt X-X-Sender: brandt@zeus To: Luigi Rizzo In-Reply-To: <20040518090647.A39810@xorpc.icir.org> Message-ID: References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <20040518090647.A39810@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Doug Rabson cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 16:21:43 -0000 On Tue, 18 May 2004, Luigi Rizzo wrote: LR>On Tue, May 18, 2004 at 02:00:28PM +0100, Doug Rabson wrote: LR>> On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: LR>> > I will try to remove as many assumptions as possible. LR>> > thanks for the feedback. LR>> LR>> I think that in your prototype, the only assumption was in struct LR>> llentry. I would suggest defining it as something like: LR> LR>to be really flexible, both l3_addr and ll_addr should be LR>variable size (v4,v6,v8 over 802.x,firewire,appletalk,snail-mail), LR>then things rapidly become confusing and inefficient. LR>I would like to keep the ipv4 over ethernet case simple and quick, even LR>if this means replicating the code for the generic case (and this LR>is one of the reasons i have stalled a bit on this code -- i want LR>to make up my mind on what is a reasonable approaxch). The most common use of that table is to have an l3_addr and search the ll_addr, right? In that case making ll_addr variable shouldn't have a measurable influence on speed. Variable l3_addr could be different though. harti From owner-freebsd-net@FreeBSD.ORG Tue May 18 09: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 083AB16A4CE; Tue, 18 May 2004 09:50:03 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AAEA43D7B; Tue, 18 May 2004 09:49:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i4IGnqkM034082; Tue, 18 May 2004 17:49:53 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4IGnpON094205; Tue, 18 May 2004 17:49:52 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Harti Brandt In-Reply-To: References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <1084885227.23208.3.camel@builder02.qubesoft.com> <20040518090647.A39810@xorpc.icir.org> Content-Type: text/plain Message-Id: <1084898991.23208.14.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 17:49:51 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Luigi Rizzo cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 18 May 2004 16:50:03 -0000 On Tue, 2004-05-18 at 17:21, Harti Brandt wrote: > On Tue, 18 May 2004, Luigi Rizzo wrote: > > LR>On Tue, May 18, 2004 at 02:00:28PM +0100, Doug Rabson wrote: > LR>> On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: > LR>> > I will try to remove as many assumptions as possible. > LR>> > thanks for the feedback. > LR>> > LR>> I think that in your prototype, the only assumption was in struct > LR>> llentry. I would suggest defining it as something like: > LR> > LR>to be really flexible, both l3_addr and ll_addr should be > LR>variable size (v4,v6,v8 over 802.x,firewire,appletalk,snail-mail), > LR>then things rapidly become confusing and inefficient. > LR>I would like to keep the ipv4 over ethernet case simple and quick, even > LR>if this means replicating the code for the generic case (and this > LR>is one of the reasons i have stalled a bit on this code -- i want > LR>to make up my mind on what is a reasonable approaxch). > > The most common use of that table is to have an l3_addr and search the > ll_addr, right? In that case making ll_addr variable shouldn't have a > measurable influence on speed. Variable l3_addr could be different though. Well it seems to me that IPv6 neighbour discovery is different enough from ARP that it makes sense to have IPv4-specialised ARP and IPv6-specialised ND. The only other variable is the size of the LL address and that doesn't add any significant complexity since its just moved around with bcopy. From owner-freebsd-net@FreeBSD.ORG Tue May 18 14:55: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 BCA5F16A4D0; Tue, 18 May 2004 14:55:36 -0700 (PDT) Received: from venus.vincentjardin.net (lns-p19-19-82-65-139-241.adsl.proxad.net [82.65.139.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E2D43DE4; Tue, 18 May 2004 11:15:10 -0700 (PDT) (envelope-from jardin@venus.vincentjardin.net) Received: from venus.vincentjardin.net (localhost [127.0.0.1]) i4IIKTGp006032; Tue, 18 May 2004 20:20:29 +0200 (CEST) (envelope-from jardin@venus.vincentjardin.net) Received: from localhost (localhost [[UNIX: localhost]]) by venus.vincentjardin.net (8.12.9/8.12.9/Submit) id i4IIKSiR006031; Tue, 18 May 2004 20:20:28 +0200 (CEST) From: Vincent Jardin To: Pawel Jakub Dawidek , Luigi Rizzo Date: Tue, 18 May 2004 20:20:26 +0200 User-Agent: KMail/1.5.2 References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> In-Reply-To: <20040518100503.GG845@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200405182020.28286.vjardin@free.fr> cc: freebsd-net@FreeBSD.org Subject: Re: ia_netbroadcast 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, 18 May 2004 21:55:36 -0000 > +> This said, how do you plan to handle the alias search, by > +> implementing a per-interface hash table containing the > +> addresses and broadcast addresses ? > > First I want to find all places that need fast processing and it probably > needs hash tables for IPs and broadcasts, but I'm not sure if that's all. Why not a lookup using Patricia ? It is very efficient, moreover it is alre= ady=20 provided by net/radix.c Regards, Vincent From owner-freebsd-net@FreeBSD.ORG Tue May 18 15:39: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 6E27016A4CE; Tue, 18 May 2004 15:39:15 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492AD43E36; Tue, 18 May 2004 11:13:06 -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 i4IIBsgd047168; Tue, 18 May 2004 11:11:54 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i4IIBsVO047167; Tue, 18 May 2004 11:11:54 -0700 (PDT) (envelope-from rizzo) Date: Tue, 18 May 2004 11:11:54 -0700 From: Luigi Rizzo To: Doug Rabson Message-ID: <20040518111153.A46894@xorpc.icir.org> References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <1084885227.23208.3.camel@builder02.qubesoft.com> <20040518090647.A39810@xorpc.icir.org> <1084898991.23208.14.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1084898991.23208.14.camel@builder02.qubesoft.com>; from dfr@nlsystems.com on Tue, May 18, 2004 at 05:49:51PM +0100 cc: Harti Brandt cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... 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, 18 May 2004 22:39:15 -0000 On Tue, May 18, 2004 at 05:49:51PM +0100, Doug Rabson wrote: ... > > The most common use of that table is to have an l3_addr and search the > > ll_addr, right? In that case making ll_addr variable shouldn't have a > > measurable influence on speed. Variable l3_addr could be different though. > > Well it seems to me that IPv6 neighbour discovery is different enough > from ARP that it makes sense to have IPv4-specialised ARP and actually, not too much -- the patch i used already included nd6 code that borrowed a lot from the v4 version. anyways, as i said, i need to think a bit about things before making a decision. cheers luigi > _______________________________________________ > 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 18 16:05: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 2790016A4D0 for ; Tue, 18 May 2004 16:05:19 -0700 (PDT) Received: from mta7.adelphia.net (mta7.adelphia.net [68.168.78.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4F3243E83 for ; Tue, 18 May 2004 15:11:15 -0700 (PDT) (envelope-from rneese@adelphia.net) Received: from 69-160-8-12.bflony.adelphia.net ([69.160.8.12]) by mta13.adelphia.netESMTP <20040518220744.DKGQ13425.mta13.adelphia.net@69-160-8-12.bflony.adelphia.net> for ; Tue, 18 May 2004 18:07:44 -0400 From: Richard Neese To: freebsd-net@freebsd.org Date: Tue, 18 May 2004 18:07:44 -0400 User-Agent: KMail/1.6.2 References: <40AA0A30.3020102@gddsn.org.cn> In-Reply-To: <40AA0A30.3020102@gddsn.org.cn> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <200405181807.44557.rneese@adelphia.net> Subject: Re: cuaa0&ttyd0's bug? 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, 18 May 2004 23:05:19 -0000 you need to change the terminal type.. from dialup to vt100 or vt220 On May 18, 2004 09:05 am, wsk wrote: > hi,folks: > It seems that the ttyd0 isn't the dialin line to login , and > the cuaa0 like is both the dialin/out device!under 4.9 above > and 5.X .but the ttyd0 work well under 4.8. > here is my test: > I wanna direct connected two bsd box via a null-modem cable,on > a box ,I congfiured the ttys as follow: > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > ttyd0 "/usr/libexec/getty std.9600" dialup on secure > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > and kill -HUP 1 > on the other box , I use cu connenct the box: > cu -l /dev/cuaa0 > connected > and then , nothing more i could recv! > but if I confirgure the ttys as below: > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > cuaa0 "/usr/libexec/getty std.9600" dialup on secure > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > and do it like before i do , it worked! > why???? It's a bug??? > thanks in advance > ---------------------- > --wsk > _______________________________________________ > 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 18 16:12:09 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 7DBF116A4F8; Tue, 18 May 2004 16:12:09 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 257DF440C6; Tue, 18 May 2004 15:49:58 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i4IMlbNg024761; Tue, 18 May 2004 18:47:37 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i4IMlbS7024760; Tue, 18 May 2004 18:47:37 -0400 (EDT) (envelope-from barney) Date: Tue, 18 May 2004 18:47:37 -0400 From: Barney Wolff To: Vincent Jardin Message-ID: <20040518224737.GA24171@pit.databus.com> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <200405182020.28286.vjardin@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200405182020.28286.vjardin@free.fr> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.43 cc: Luigi Rizzo cc: Pawel Jakub Dawidek cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 18 May 2004 23:12:14 -0000 On Tue, May 18, 2004 at 08:20:26PM +0200, Vincent Jardin wrote: > > +> This said, how do you plan to handle the alias search, by > > +> implementing a per-interface hash table containing the > > +> addresses and broadcast addresses ? > > > > First I want to find all places that need fast processing and it probably > > needs hash tables for IPs and broadcasts, but I'm not sure if that's all. > >Why not a lookup using Patricia ? It is very efficient, moreover it is already > provided by net/radix.c Well, no. A trie is very efficient when the problem is to match an address with an addr/mask pair. For matching on equality, hashing is far better. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Tue May 18 16:50: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 0475916A4CE for ; Tue, 18 May 2004 16:50:52 -0700 (PDT) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54AD843D2D for ; Tue, 18 May 2004 16:50:49 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.12.11/8.12.11) id i4INKt2x019230 for freebsd-net@freebsd.org; Wed, 19 May 2004 09:20:55 +1000 (EST) (envelope-from ernie) From: User Ernie Message-Id: <200405182320.i4INKt2x019230@spooky.eis.net.au> To: freebsd-net@freebsd.org Date: Wed, 19 May 2004 09:20:55 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: mgetty ppp stallion problem 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, 18 May 2004 23:50:52 -0000 Something I have been meaning to post about but kept forgetting. I have a FreeBSD 4.9-STABLE machine with a stallion card stl0: port 0x7400-0x7403,0x7800-0x7807,0x8000-0x8003,0x8400-0x8407 irq 11 at device 12.0 on pci0 stl0: EC8/32-PCI (driver version 5.6.0b1) unit=0 nrpanels=1 nrports=16 It's acting as a modem server running mgetty+sendfax from the ports collection MD5 (mgetty1.1.30-Dec16.tar.gz) = 4b80c418bc58add3e40de3be0ac6c02a mgetty is set to spawn off a user ppp session which it does quite well, but every now and then when the caller hangs up the ppp session stays active so the serail port is unusable. If I do a kill on the ppp session the ppp process dies but the sertial port on the stallion card does not free up and a reboot is required. The megetty.config is as follows: debug 6 data-only YES speed 57600 port-owner uucp port-group network port-mode 0666 toggle-dtr YES toggle-dtr-waittime 500 direct NO blocking NO modem-type data init-chat "" ATS0=0Q0&D3&C1 OK modem-check-time 3600 rings 2 answer-chat "" ATA CONNECT \c \r answer-chat-timeout 80 autobauding NO ringback NO ringback-time 30 ignore-carrier false prompt-waittime 500 login-prompt @!login: login-time 240 It's almost as if ppp is not sending the right signal to release the serial port back to mgetty. Any ideas? - Ernie. From owner-freebsd-net@FreeBSD.ORG Tue May 18 17:15: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 CCA3716A4D1 for ; Tue, 18 May 2004 17:15:02 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5942243D3F for ; Tue, 18 May 2004 17:15:02 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BQEjF-00016A-00; Wed, 19 May 2004 02:14:37 +0200 Received: from [216.58.85.218] (helo=[10.0.0.49]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BQEjF-00053O-00; Wed, 19 May 2004 02:14:37 +0200 From: Max Laier To: pf4freebsd@freelists.org Date: Wed, 19 May 2004 02:16:09 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200405190216.16204.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 cc: freebsd-altq@rofug.ro cc: net@freebsd.org Subject: pf 3.5 + ALTQ import / Looking for beta testers and altq drivers 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, 19 May 2004 00:15:03 -0000 Hello, http://people.freebsd.org/~mlaier/ has an import of the OpenBSD 3.5 pf sources (OPENBSD_3_5_BASE, stable imports will follow later). To build this you need a recent -current source tree. Just apply the patch and copy over the other files. After this you should be ready for a build{world, kernel}. If you do not want to do a full buildworld, make sure to update (at least) pfctl(8) and authpf(8). You might also want to update ifconfig(8) and kdump(1). This comes bundled with latest ALTQ sources from KAME, providing "pf_mode" only (i.e. no support of /dev/altq). This makes the locking really easy and keeps the impact of ALTQ to the tree very small (i.e. no classifier hooks etc). The ALTQ-enabled driver set is very limited at the moment as I'd like to import only well-tested drivers to this patchset anticipating a possible import into the tree. The pf import is a bit different in respect to the interface handling. As FreeBSD allows network interfaces to be renamed at runtime I had to introduce a special group for interfaces that have not yet been seen. Just to explain what this "notyet" group is all about and what "(placeholder)" means. Other than this, there should be no noticable difference between Open- and FreeBSD. Please test this stuff if you have time/resources at hand and possibly feedback drivers after a reasonable time of testing. It should be able to apply the driver patch from the rofug.ro patchset in most cases, if you run into troubles - let me know. Note that this is really a BETA patch. It works great for me on two routers, my desktop and laptop, but that does not mean anything. It is also missing some glue in regards to pfsync(4) (which is kinda pointless w/o carp[1] anyways) and other minor tweaks that make up a proper import. If you run into anything let me know! (w/ or w/o patches to fix it). Okay ... this is a bit of a disordered mess, but I think you get the point. I am in Canada at the moment and will not be very available until monday, but I just had to send this out ... finally. [1] There is an old patchset available to import this. Pick up from there or fund me to finish it ;) P.S.: There is also this "jailed.patch". If you have an application for it, please give it a try (discription is on the site) and let me know what you think about it. -- Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet From owner-freebsd-net@FreeBSD.ORG Tue May 18 17:49: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 8768A16A4CE for ; Tue, 18 May 2004 17:49:36 -0700 (PDT) Received: from hotmail.com (bay3-f17.bay3.hotmail.com [65.54.169.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C8943D41 for ; Tue, 18 May 2004 17:49:36 -0700 (PDT) (envelope-from wienne@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 May 2004 17:49:36 -0700 Received: from 61.242.173.156 by by3fd.bay3.hotmail.msn.com with HTTP; Wed, 19 May 2004 00:49:36 GMT X-Originating-IP: [61.242.173.156] X-Originating-Email: [wienne@msn.com] X-Sender: wienne@msn.com From: "sun wienne" To: mbretter@inode.at Date: Wed, 19 May 2004 08:49:36 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 19 May 2004 00:49:36.0538 (UTC) FILETIME=[2884E7A0:01C43D3B] cc: freebsd-net@freebsd.org Subject: Re: mpd help 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, 19 May 2004 00:49:36 -0000 ok, remove this line 'set ccp yes mpp-compress' is can dial in A server. but i want enable mpp-compress,'proprietary code' is what ? >From: Michael Bretterklieber >To: РЎАуН¬Цѕ >CC: freebsd-net@freebsd.org >Subject: Re: mpd help >Date: Tue, 18 May 2004 17:50:12 +0200 >MIME-Version: 1.0 >Received: from smartmx-03.inode.at ([213.229.60.35]) by mc10-f6.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 18 May 2004 08:50:15 -0700 >Received: from [62.99.226.131] (port=1035 helo=inode.at)by smartmx-03.inode.at with esmtp (Exim 4.30)id 1BQ6r6-0007of-9m; Tue, 18 May 2004 17:50:12 +0200 >X-Message-Info: JGTYoYF78jEw4eYW3/YVNfla1+nH1hQ3 >Message-ID: <40AA30B4.20600@inode.at> >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.7b) Gecko/20040421 >X-Accept-Language: de-at, de, en-us, en >References: >In-Reply-To: >Return-Path: mbretter@inode.at >X-OriginalArrivalTime: 18 May 2004 15:50:17.0251 (UTC) FILETIME=[D0E18F30:01C43CEF] > >Hi, > >РЎАуН¬Цѕ schrieb: > > vpn server A and B 'mpd.conf' is sameness > > > > Version 3.15 > > > > ----------------------- > > client_standard: > > set iface disable on-demand > > set iface enable proxy-arp > > set iface idle 1800 > > set bundle enable multilink > > set link yes acfcomp protocomp > > set link no pap chap > > set link enable chap > > set link keep-alive 10 60 > > set ipcp yes vjcomp > > set bundle enable encryption > > set bundle enable compression > > set ccp yes mppc > > set ccp yes mpp-compress > ^^^^^^^^^^^^^^^^^^^^^^^you enabled STAC compression, wich >needs proprietary code, please remove this line. > >bye, >-- >------------------------------- ---------------------------------- >Michael Bretterklieber - http://www.bretterklieber.com >------------------------------ ---------------------------------- >"...the number of UNIX installations has grown to 10, with more >expected..." >- Dennis Ritchie and Ken Thompson, June 1972 _________________________________________________________________ Гв·СПВФШ MSN Explorer: http://explorer.msn.com/lccn/ From owner-freebsd-net@FreeBSD.ORG Tue May 18 18:16: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 637EE16A4D1 for ; Tue, 18 May 2004 18:16:05 -0700 (PDT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEACB43D31 for ; Tue, 18 May 2004 18:16:02 -0700 (PDT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id BF6C638CBE2; Wed, 19 May 2004 09:15:59 +0800 (CST) Message-ID: <40AAB54E.9010509@gddsn.org.cn> Date: Wed, 19 May 2004 09:15:58 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040409 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: Richard Neese , net@freebsd.org References: <40AA0A30.3020102@gddsn.org.cn> <200405181807.44557.rneese@adelphia.net> In-Reply-To: <200405181807.44557.rneese@adelphia.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: cuaa0&ttyd0's bug? 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, 19 May 2004 01:16:05 -0000 Richard Neese : >you need to change the terminal type.. from dialup to vt100 or vt220 > >On May 18, 2004 09:05 am, wsk wrote: > > >>hi,folks: >>It seems that the ttyd0 isn't the dialin line to login , and >>the cuaa0 like is both the dialin/out device!under 4.9 above >>and 5.X .but the ttyd0 work well under 4.8. >>here is my test: >>I wanna direct connected two bsd box via a null-modem cable,on >>a box ,I congfiured the ttys as follow: >># The 'dialup' keyword identifies dialin lines to login, fingerd etc. >>ttyd0 "/usr/libexec/getty std.9600" dialup on secure >>ttyd1 "/usr/libexec/getty std.9600" dialup off secure >>and kill -HUP 1 >>on the other box , I use cu connenct the box: >>cu -l /dev/cuaa0 >>connected >>and then , nothing more i could recv! >>but if I confirgure the ttys as below: >># The 'dialup' keyword identifies dialin lines to login, fingerd etc. >>cuaa0 "/usr/libexec/getty std.9600" dialup on secure >>ttyd1 "/usr/libexec/getty std.9600" dialup off secure >>and do it like before i do , it worked! >>why???? It's a bug??? >>thanks in advance >>---------------------- >>--wsk >>_______________________________________________ >>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" >> >> >_______________________________________________ >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" > > > I had been tested as u said , but as same as I set the type dialup! From owner-freebsd-net@FreeBSD.ORG Tue May 18 18:50:06 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 7A46C16A4CE; Tue, 18 May 2004 18:50:06 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE6FC43D46; Tue, 18 May 2004 18:50:04 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4J1mswv098957; Wed, 19 May 2004 09:48:54 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40AABCFE.AD46764C@kuzbass.ru> Date: Wed, 19 May 2004 09:48:46 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ruslan Ermilov References: <40A9D99A.34AA675D@kuzbass.ru> <20040518105817.GD70919@ip.net.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: in_cksum_skip 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, 19 May 2004 01:50:06 -0000 Ruslan Ermilov wrote: > You're apparently experimenting with IP multicasting. There was > a bug with this effect I introduced in ip_output.c,v 1.99.2.43, > and shortly fixed it in rev. 1.99.2.44. Check that your revision > is not vulnerable. Is it safe to apply diff for just this file or that commit touched more than one file? From owner-freebsd-net@FreeBSD.ORG Tue May 18 22:28: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 693C816A4CE for ; Tue, 18 May 2004 22:28:18 -0700 (PDT) Received: from flock1.newmail.ru (morda.newmail.ru [212.48.140.150]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F62343D31 for ; Tue, 18 May 2004 22:28:17 -0700 (PDT) (envelope-from Andrew.Karjagin@newmail.ru) Received: (qmail 2826 invoked by alias); 19 May 2004 05:25:52 -0000 Message-ID: <20040519052552.2821.qmail@flock1.newmail.ru> From: Andrew Karjagin To: , X-Priority: 3 MIME-Version: 1.0 X-Mailer: DenMail v1.0 by ORC X-Uid: 689 X-RemoteIP: 81.89.64.105 Date: Wed, 19 May 2004 09:25:52 +0400 In-Reply-To: <200405182320.i4INKt2x019230@spooky.eis.net.au> X-DWM-In-Reply-To: <1084944352.2765.denwebmail-11923-INBOX@Andrew_Karjagin> Content-type: text/plain; charset="koi8-r" Subject: Re: mgetty ppp stallion problem 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, 19 May 2004 05:28:18 -0000 Hello User Ernie Add to your /etc/rc.serial -clocal parameter, for example ================================= # Modem init function modem { comcontrol ... d=shift a=shift for $i { stty < /dev/cua$ai$i crtscts -clocal 57600 stty < /dev/tty$di$i crtscts -clocal 57600 stty < /dev/cua$al$i crtscts stty < /dev/tty$dl$i crtscts } } modem d a 0 1 2 3 4 5 6 7 ... ================================= уТ, 19.05.2004 03:20:55 you wrote: > UE> Something I have been meaning to post about but kept forgetting. UE> UE> I have a FreeBSD 4.9-STABLE machine with a stallion card UE> stl0: port 0x7400-0x7403,0x7800-0x7807,0x8000-0x8003,0x8400-0x8407 irq 11 at device 12.0 on pci0 UE> stl0: EC8/32-PCI (driver version 5.6.0b1) unit=0 nrpanels=1 nrports=16 UE> UE> UE> UE> It's acting as a modem server running mgetty+sendfax from the ports collection UE> MD5 (mgetty1.1.30-Dec16.tar.gz) = 4b80c418bc58add3e40de3be0ac6c02a UE> UE> mgetty is set to spawn off a user ppp session which it does quite well, but UE> every now and then when the caller hangs up the ppp session stays active so UE> the serail port is unusable. If I do a kill on the ppp session the ppp UE> process dies but the sertial port on the stallion card does not free up and UE> a reboot is required. UE> UE> The megetty.config is as follows: UE> UE> debug 6 UE> data-only YES UE> UE> speed 57600 UE> port-owner uucp UE> port-group network UE> port-mode 0666 UE> toggle-dtr YES UE> toggle-dtr-waittime 500 UE> direct NO UE> blocking NO UE> modem-type data UE> init-chat "" ATS0=0Q0&D3&C1 OK UE> modem-check-time 3600 UE> rings 2 UE> answer-chat "" ATA CONNECT \c \r UE> answer-chat-timeout 80 UE> autobauding NO UE> ringback NO UE> ringback-time 30 UE> ignore-carrier false UE> prompt-waittime 500 UE> login-prompt @!login: UE> login-time 240 UE> UE> It's almost as if ppp is not sending the right signal to release the serial UE> port back to mgetty. UE> UE> Any ideas? UE> UE> - Ernie. UE> UE> _______________________________________________ UE> freebsd-net@freebsd.org mailing list UE> http://lists.freebsd.org/mailman/listinfo/freebsd-net UE> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" UE> __________ UE> www.zakaz.orc.ru - ДПУФБЧЛБ ЛБТФ УЧСЪЙ: птг (IP-ФЕМЕЖПОЙС, ДПУФХР Ч йОФЕТОЕФ, ИПУФЙОЗ), нфу, вй рМАУ __________ www.newmail.ru -- ХЪЕМ УЧПВПДОЩИ ЛПННХОЙЛБГЙК. From owner-freebsd-net@FreeBSD.ORG Tue May 18 23:02:06 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 B522916A4CE for ; Tue, 18 May 2004 23:02:06 -0700 (PDT) Received: from smartmx-05.inode.at (smartmx-05.inode.at [213.229.60.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E4A943D3F for ; Tue, 18 May 2004 23:02:06 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from [62.99.226.131] (port=65048 helo=inode.at) by smartmx-05.inode.at with esmtp (Exim 4.30) id 1BQK9T-00053u-I6; Wed, 19 May 2004 08:02:03 +0200 Message-ID: <40AAF85B.8050101@inode.at> Date: Wed, 19 May 2004 08:02:03 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7a) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sun wienne References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: mpd help 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, 19 May 2004 06:02:06 -0000 Hi, sun wienne wrote: > ok, remove this line 'set ccp yes mpp-compress' is can dial in A server. > > but i want enable mpp-compress,'proprietary code' is what ? > > http://www.hifn.com/products/MPPC.html bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com ------------------------------ ---------------------------------- "...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 Wed May 19 02:01: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 3AB0D16A4CE for ; Wed, 19 May 2004 02:01:47 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E1A343D54 for ; Wed, 19 May 2004 02:01:46 -0700 (PDT) (envelope-from kwl02r@ecs.soton.ac.uk) Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) i4J91W7s003346 for ; Wed, 19 May 2004 10:01:32 +0100 (BST) Received: from ecs.soton.ac.uk (kaiwen [152.78.66.89]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA15082 for ; Wed, 19 May 2004 10:01:28 +0100 (BST) Message-ID: <40AB2209.6060108@ecs.soton.ac.uk> Date: Wed, 19 May 2004 09:59:53 +0100 From: kwl02r User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 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 X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean Subject: About tcp_fastimo() and tcp_slowtimo() 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, 19 May 2004 09:01:47 -0000 Dear all, I just follow the book "TCP/IP illustrate vol 2" to understand more about TCP timer. In the book, tcp_fastimo() is invoked each 200 ms to do delay ack job and tcp_slowtimo() is invoked each 500 ms to do the rest of other tcp times. But at the last version of FreeBSD source code, I couldn't find tcp_fastimo() anymore and tcp_slowtimo() is quite different compared with source code present at book. My questions are: At the new FreeBSD: 1. Did delay ack time still be detected each 200ms? Which function do this job? If not, can anybody help to describe some detail things about delay ack time at freebsd source code. 2. The new tcp_slowtimo() following is invoked each 500ms, but seems only detects tcp_keepintvl timer, how about other timers (eg. SYN, FIN_WAIT ..) void tcp_slowtimo() { int s; s = splnet(); tcp_maxidle = tcp_keepcnt * tcp_keepintvl; splx(s); } 3. Did TCP timer (detect 200 or 500 ms each time) doing the same job under the LINUX kernel? 4. Any web or book can find detail describe at source code about TCP timer under both FreeBSD and Linux kernel? Thanks Calvin From owner-freebsd-net@FreeBSD.ORG Wed May 19 02:28: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 9973016A4CE for ; Wed, 19 May 2004 02:28:39 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F73543D1F for ; Wed, 19 May 2004 02:28:38 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4J9XF9c069789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 12:33:16 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4J9RnKY024655; Wed, 19 May 2004 12:27:49 +0300 (EEST) (envelope-from ru) Date: Wed, 19 May 2004 12:27:49 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040519092749.GA24625@ip.net.ua> References: <40A9D99A.34AA675D@kuzbass.ru> <20040518105817.GD70919@ip.net.ua> <40AABCFE.AD46764C@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <40AABCFE.AD46764C@kuzbass.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: in_cksum_skip 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, 19 May 2004 09:28:39 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 19, 2004 at 09:48:46AM +0800, Eugene Grosbein wrote: > Ruslan Ermilov wrote: >=20 > > You're apparently experimenting with IP multicasting. There was > > a bug with this effect I introduced in ip_output.c,v 1.99.2.43, > > and shortly fixed it in rev. 1.99.2.44. Check that your revision > > is not vulnerable. >=20 > Is it safe to apply diff for just this file or that commit touched > more than one file? >=20 Only this file was affected, so just updating it to rev. 1.99.2.44 will fix the problem. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqyiVUkv4P6juNwoRAhpJAJ9lAwwmf5vQlD11NrWSA6nwTersVgCfXG5z +299o39N2pdmsnVrWejOYBE= =zsx8 -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-net@FreeBSD.ORG Wed May 19 03:18: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 8C81D16A4CE; Wed, 19 May 2004 03:18:11 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4D943D48; Wed, 19 May 2004 03:18:09 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4JAHewX043200; Wed, 19 May 2004 18:17:40 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40AB3439.7837653E@kuzbass.ru> Date: Wed, 19 May 2004 18:17:29 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ruslan Ermilov References: <40A9D99A.34AA675D@kuzbass.ru> <20040518105817.GD70919@ip.net.ua> <40AABCFE.AD46764C@kuzbass.ru> <20040519092749.GA24625@ip.net.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: in_cksum_skip 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, 19 May 2004 10:18:11 -0000 Ruslan Ermilov wrote: > > On Wed, May 19, 2004 at 09:48:46AM +0800, Eugene Grosbein wrote: > > Ruslan Ermilov wrote: > > > > > You're apparently experimenting with IP multicasting. There was > > > a bug with this effect I introduced in ip_output.c,v 1.99.2.43, > > > and shortly fixed it in rev. 1.99.2.44. Check that your revision > > > is not vulnerable. > > > > Is it safe to apply diff for just this file or that commit touched > > more than one file? > > > Only this file was affected, so just updating it to rev. 1.99.2.44 > will fix the problem. Thanks, it helps. Eugene From owner-freebsd-net@FreeBSD.ORG Wed May 19 03:25: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 C8FCA16A4D2; Wed, 19 May 2004 03:25:15 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CBB43D2F; Wed, 19 May 2004 03:25:13 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4JAOfBa043775; Wed, 19 May 2004 18:24:41 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40AB35DE.DF743CCB@kuzbass.ru> Date: Wed, 19 May 2004 18:24:30 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ruslan Ermilov References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518151506.GC72684@ip.net.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: Eugene Grosbein cc: net@freebsd.org Subject: Re: multicast arp entry 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, 19 May 2004 10:25:15 -0000 Ruslan Ermilov wrote: > > > The long answer could be: you could join to a single multicast > > > group on multiple interfaces, and you will be able to receive > > > multicast on all of them, but if you don't have multicast > > > forwarding enabled, only one interface will be used for sending. > > > > That's bad. How do I enable "multicast forwarding", or, in other words, > > do you know why ripd doesn't do it for be? > > > I use mrouted(8). > > > On the other hand, I've got another machine with very simple configuration: > > one fxp0 interface, one rl0 and one gif0 and started quagga/ripd. > > Two points: tcpdump shows that multicasts go out all three interfaces > > with right source IP and there is no arp entries for 224.0.0.9 and 224.0.0.1. > > > > I couldn't find what is the vital difference between these two machines yet > > (there are so many of them). > > > I don't know. Perhaps, quagga/ripd send raw IP packets in this case. No, it does not. I've finally found that one need not MROUTING and mrouted just to send RIPv2 multicasts out via several interfaces and FreeBSD does it right by default. But if outgoint multicast packet is diverted to ipacctd accounting daemon using 'ipfw divert' then it is sent to an interface pointed by route to 224.0.0.9 instead of right one (no such effect for P2P interfaces, though). I wonder if it's a fault of ipacctd or of divert's way of life. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed May 19 03:57: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 BE1E316A4CE for ; Wed, 19 May 2004 03:57:13 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA4F043D1D for ; Wed, 19 May 2004 03:57:12 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4JB2Clm079669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 14:02:13 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4JAukhu025253; Wed, 19 May 2004 13:56:46 +0300 (EEST) (envelope-from ru) Date: Wed, 19 May 2004 13:56:46 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040519105646.GB25177@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <40AB35DE.DF743CCB@kuzbass.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Eugene Grosbein cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 19 May 2004 10:57:13 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 19, 2004 at 06:24:30PM +0800, Eugene Grosbein wrote: > Ruslan Ermilov wrote: >=20 > > > > The long answer could be: you could join to a single multicast > > > > group on multiple interfaces, and you will be able to receive > > > > multicast on all of them, but if you don't have multicast > > > > forwarding enabled, only one interface will be used for sending. > > > > > > That's bad. How do I enable "multicast forwarding", or, in other word= s, > > > do you know why ripd doesn't do it for be? > > > > > I use mrouted(8). > >=20 > > > On the other hand, I've got another machine with very simple configur= ation: > > > one fxp0 interface, one rl0 and one gif0 and started quagga/ripd. > > > Two points: tcpdump shows that multicasts go out all three interfaces > > > with right source IP and there is no arp entries for 224.0.0.9 and 22= 4.0.0.1. > > > > > > I couldn't find what is the vital difference between these two machin= es yet > > > (there are so many of them). > > > > > I don't know. Perhaps, quagga/ripd send raw IP packets in this case. >=20 > No, it does not. >=20 > I've finally found that one need not MROUTING and mrouted just to send > RIPv2 multicasts out via several interfaces and FreeBSD does it right > by default. But if outgoint multicast packet is diverted to ipacctd > accounting daemon using 'ipfw divert' then it is sent to an interface > pointed by route to 224.0.0.9 instead of right one > (no such effect for P2P interfaces, though). >=20 Care to share the experience of how you were able to send multicasts out several interfaces without tmulticast forwarding using mrouted(8) or its equivalent? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAqz1uUkv4P6juNwoRAr8qAJ9YpdY0ykGKpGOQkJKMRDdWxFIRkwCeJXKm En/LF1Kq4lg99PMwsBvN/4A= =JWQE -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-net@FreeBSD.ORG Wed May 19 05:37: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 D10C716A4CE for ; Wed, 19 May 2004 05:37:27 -0700 (PDT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 716BB43D1D for ; Wed, 19 May 2004 05:37:27 -0700 (PDT) (envelope-from rneese@adelphia.net) Received: from 69-160-8-12.bflony.adelphia.net ([69.160.8.12]) by mta9.adelphia.netESMTP <20040519123709.MTZH26615.mta9.adelphia.net@69-160-8-12.bflony.adelphia.net> for ; Wed, 19 May 2004 08:37:09 -0400 From: Richard Neese To: freebsd-net@freebsd.org Date: Wed, 19 May 2004 08:37:16 -0400 User-Agent: KMail/1.6.2 References: <40AA0A30.3020102@gddsn.org.cn> <200405181807.44557.rneese@adelphia.net> <40AAB54E.9010509@gddsn.org.cn> In-Reply-To: <40AAB54E.9010509@gddsn.org.cn> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405190837.16730.rneese@adelphia.net> Subject: Re: cuaa0&ttyd0's bug? 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, 19 May 2004 12:37:27 -0000 hmm I have 4 serial terminals and they all work fine... I have not tried box to box... I will test ltr today and let you know what I fiind. From owner-freebsd-net@FreeBSD.ORG Wed May 19 05:51:45 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 BF0C716A4CE; Wed, 19 May 2004 05:51:45 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF56B43D41; Wed, 19 May 2004 05:51:44 -0700 (PDT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) i4JCpcPP059128; Wed, 19 May 2004 20:51:38 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.12.11/8.12.11/Submit) id i4JCpcfG059127; Wed, 19 May 2004 20:51:38 +0800 (KRAST) (envelope-from eugen) Date: Wed, 19 May 2004 20:51:38 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040519125138.GA58630@svzserv.kemerovo.su> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> <20040519105646.GB25177@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040519105646.GB25177@ip.net.ua> User-Agent: Mutt/1.4i cc: Eugene Grosbein cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 19 May 2004 12:51:45 -0000 > Care to share the experience of how you were able to send multicasts > out several interfaces without tmulticast forwarding using mrouted(8) > or its equivalent? 1. Get FreeBSD 4.9-STABLE :-) 2. Install quagga from _fresh_ port collection (0.96.4 does NOT work) 3. run zebra and ripd, configure as usual. Eugene From owner-freebsd-net@FreeBSD.ORG Wed May 19 07:18: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 8559716A4CF for ; Wed, 19 May 2004 07:18:21 -0700 (PDT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69A7543D1F for ; Wed, 19 May 2004 07:18:20 -0700 (PDT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id 6732338CBE4; Wed, 19 May 2004 22:18:00 +0800 (CST) Message-ID: <40AB6C97.2030603@gddsn.org.cn> Date: Wed, 19 May 2004 22:17:59 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040409 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: Richard Neese , net@freebsd.org References: <40AA0A30.3020102@gddsn.org.cn> <200405181807.44557.rneese@adelphia.net> <40AAB54E.9010509@gddsn.org.cn> <200405190837.16730.rneese@adelphia.net> In-Reply-To: <200405190837.16730.rneese@adelphia.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: cuaa0&ttyd0's bug? 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, 19 May 2004 14:18:21 -0000 Richard Neese Write: >hmm I have 4 serial terminals and they all work fine... I have not tried box >to box... I will test ltr today and let you know what I fiind. >_______________________________________________ >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" > > > thanks in advance! I also test it on a 5.2-CURRENT box with 2 sios,and get the same result. last,thanks again From owner-freebsd-net@FreeBSD.ORG Wed May 19 09:13: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 F092016A4CE for ; Wed, 19 May 2004 09:13:09 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E4E143D1D for ; Wed, 19 May 2004 09:13:08 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4JGIPq2014511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 19:18:26 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4JGCwmo027318; Wed, 19 May 2004 19:12:58 +0300 (EEST) (envelope-from ru) Date: Wed, 19 May 2004 19:12:58 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040519161257.GA26262@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> <20040519105646.GB25177@ip.net.ua> <20040519125138.GA58630@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <20040519125138.GA58630@svzserv.kemerovo.su> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Eugene Grosbein cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 19 May 2004 16:13:10 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 19, 2004 at 08:51:38PM +0800, Eugene Grosbein wrote: > > Care to share the experience of how you were able to send multicasts > > out several interfaces without tmulticast forwarding using mrouted(8) > > or its equivalent? >=20 > 1. Get FreeBSD 4.9-STABLE :-) > 2. Install quagga from _fresh_ port collection (0.96.4 does NOT work) > 3. run zebra and ripd, configure as usual. >=20 They apparently do the thing equivalent to mrouted(8), and that's not what I've understood from your email. Thanks anyway. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --9amGYk9869ThD9tj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAq4eJUkv4P6juNwoRApdxAJ9lEd9HhioxYp3S6LR75Aazaebm0ACdEZS8 BvC+CSNgODDMztzHbTb7Gew= =/tKd -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-net@FreeBSD.ORG Wed May 19 09:23: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 067E216A4CE; Wed, 19 May 2004 09:23:33 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07A9043D1D; Wed, 19 May 2004 09:23:32 -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 i4JGNLKe001589; Thu, 20 May 2004 00:23:21 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4JGNLZ0001588; Thu, 20 May 2004 00:23:21 +0800 (KRAST) (envelope-from eugen) Date: Thu, 20 May 2004 00:23:21 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040519162320.GA1545@grosbein.pp.ru> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> <20040519105646.GB25177@ip.net.ua> <20040519125138.GA58630@svzserv.kemerovo.su> <20040519161257.GA26262@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040519161257.GA26262@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: multicast arp entry 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, 19 May 2004 16:23:33 -0000 On Wed, May 19, 2004 at 07:12:58PM +0300, Ruslan Ermilov wrote: > > > Care to share the experience of how you were able to send multicasts > > > out several interfaces without tmulticast forwarding using mrouted(8) > > > or its equivalent? > > 1. Get FreeBSD 4.9-STABLE :-) > > 2. Install quagga from _fresh_ port collection (0.96.4 does NOT work) > > 3. run zebra and ripd, configure as usual. > They apparently do the thing equivalent to mrouted(8), and that's > not what I've understood from your email. Thanks anyway. ;) So, why divert breaks outgoing multicasts? Or, perhaps, a daemon should take measures to not break this? Eugene From owner-freebsd-net@FreeBSD.ORG Wed May 19 10:02: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 D54EA16A4CE; Wed, 19 May 2004 10:02:33 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F2CD43D2F; Wed, 19 May 2004 10:02:33 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i4JH2ODv054166 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 May 2004 19:02:28 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i4JH18Ui048167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 19:01:09 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i4JH182h061775; Wed, 19 May 2004 19:01:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i4JH16C3061774; Wed, 19 May 2004 19:01:06 +0200 (CEST) (envelope-from ticso) Date: Wed, 19 May 2004 19:01:06 +0200 From: Bernd Walter To: wsk Message-ID: <20040519170105.GZ70900@cicely12.cicely.de> References: <40AA0A30.3020102@gddsn.org.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40AA0A30.3020102@gddsn.org.cn> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.cicely.de cc: current@freebsd.org cc: net@freebsd.org Subject: Re: cuaa0&ttyd0's bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2004 17:02:34 -0000 On Tue, May 18, 2004 at 09:05:52PM +0800, wsk wrote: > hi,folks: > It seems that the ttyd0 isn't the dialin line to login , and > the cuaa0 like is both the dialin/out device!under 4.9 above > and 5.X .but the ttyd0 work well under 4.8. > here is my test: > I wanna direct connected two bsd box via a null-modem cable,on > a box ,I congfiured the ttys as follow: > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > ttyd0 "/usr/libexec/getty std.9600" dialup on secure > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > and kill -HUP 1 > on the other box , I use cu connenct the box: > cu -l /dev/cuaa0 > connected > and then , nothing more i could recv! > but if I confirgure the ttys as below: > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > cuaa0 "/usr/libexec/getty std.9600" dialup on secure > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > and do it like before i do , it worked! > why???? It's a bug??? The behavour is intentional. Your cable doesn't supply DCD signal. Either use a cable with DCD suport or stay with cuaa. It's OK to use cuaa if you don't need dialout support. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-net@FreeBSD.ORG Wed May 19 10:37: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 9F10E16A4CE for ; Wed, 19 May 2004 10:37:31 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B1843D5A for ; Wed, 19 May 2004 10:37:31 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i4JHbRd5000177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 19 May 2004 13:37:27 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i4JHbQvm000174; Wed, 19 May 2004 13:37:26 -0400 (EDT) (envelope-from wollman) Date: Wed, 19 May 2004 13:37:26 -0400 (EDT) From: Garrett Wollman Message-Id: <200405191737.i4JHbQvm000174@khavrinen.lcs.mit.edu> To: kwl02r In-Reply-To: <40AB2209.6060108@ecs.soton.ac.uk> References: <40AB2209.6060108@ecs.soton.ac.uk> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: About tcp_fastimo() and tcp_slowtimo() 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, 19 May 2004 17:37:31 -0000 < said: > 1. Did delay ack time still be detected each 200ms? Which function do > this job? If not, can anybody help to describe some detail things about > delay ack time at freebsd source code. The TCP timer code has been completely rewritten. You can see how it works now by grepping for `callout' in netinet/tcp*.[ch]. This change was necessary in order to scale TCP to large numbers of active connections. Otherwise, a variant of the ``thundering herd'' problem arises, when the old timers must iterate over thousands of TCBs and do essentially the same thing to each one. This way breaks up the synchronization by scheduling timeouts with finer granularity. It also improves TCP performance on fast, congested networks by allowing more granular (and hopefully more accurate) retransmit timeouts. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed May 19 10:51: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 2BC5116A4CE; Wed, 19 May 2004 10:51:42 -0700 (PDT) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 321D143D46; Wed, 19 May 2004 10:51:39 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id DAA23630; Thu, 20 May 2004 03:51:08 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 20 May 2004 03:51:08 +1000 (EST) From: Ian Smith To: Bernd Walter In-Reply-To: <20040519170105.GZ70900@cicely12.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: wsk cc: net@freebsd.org Subject: Re: cuaa0&ttyd0's bug? 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, 19 May 2004 17:51:42 -0000 On Wed, 19 May 2004, Bernd Walter wrote: > On Tue, May 18, 2004 at 09:05:52PM +0800, wsk wrote: > > hi,folks: > > It seems that the ttyd0 isn't the dialin line to login , and > > the cuaa0 like is both the dialin/out device!under 4.9 above > > and 5.X .but the ttyd0 work well under 4.8. > > here is my test: > > I wanna direct connected two bsd box via a null-modem cable,on Define the wiring of null-modem cable? DTR (tied to DSR) asserts CD the other end, either way? RTS asserts CTS the other end, either way? > > a box ,I congfiured the ttys as follow: > > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > > ttyd0 "/usr/libexec/getty std.9600" dialup on secure > > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > > and kill -HUP 1 > > on the other box , I use cu connenct the box: > > cu -l /dev/cuaa0 > > connected > > and then , nothing more i could recv! What's in /etc/rc.serial for these ports, either end? Using crtscts? > > but if I confirgure the ttys as below: > > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > > cuaa0 "/usr/libexec/getty std.9600" dialup on secure > > ttyd1 "/usr/libexec/getty std.9600" dialup off secure > > and do it like before i do , it worked! > > why???? It's a bug??? > > The behavour is intentional. > Your cable doesn't supply DCD signal. Or it does, but RTS/CTS aren't wired right? (if used .. so many options!) > Either use a cable with DCD suport or stay with cuaa. > It's OK to use cuaa if you don't need dialout support. Still depends on how cuaa0 and ttyd1 are defined, no? Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed May 19 12:13: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 0E3AF16A4CE for ; Wed, 19 May 2004 12:13:59 -0700 (PDT) Received: from europa.lunarpages.com (europa.lunarpages.com [64.235.234.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED79643D31 for ; Wed, 19 May 2004 12:13:58 -0700 (PDT) (envelope-from russ@500records.com) Received: from cpanel by europa.lunarpages.com with local (Exim 4.34) id 1BQWZD-00043G-0J for freebsd-net@freebsd.org; Wed, 19 May 2004 12:17:27 -0700 Received: from 64.1.168.26 ([64.1.168.26]) by 500records.com (IMP) with HTTP for ; Wed, 19 May 2004 12:17:26 -0700 Message-ID: <1084994246.40abb2c6ef47a@500records.com> Date: Wed, 19 May 2004 12:17:26 -0700 From: Russell Adams To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 64.1.168.26 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - europa.lunarpages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - 500records.com X-Source: X-Source-Args: X-Source-Dir: Subject: arp: is using my IP address again. 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, 19 May 2004 19:13:59 -0000 Hello, I have seen this question posted twice to the list each without any response. Does anybody out there know if this is possible, a Yes or No, will do if you can't offer anything else. If it is possible then how do we get rid of the Arp/IP conflict problem. This is what I want to do: A transparent bridge with no IPs (2 NICs) A 3rd NIC to access the box via SSH for monitoring and configuration. this is what I have done. xl0 and xl1 set up as a transparent bridge, no ips rl0 set up as 192.168.30.254 on the LAN Bridge is inbetween 192.168.30.1 (ROUTER to Internet) and 5500 Cisco Switch. I log in via SSH to configure the bridge via rl0, so far so good. I plug in the bridge between the router and the switch via xl0 and xl1, the bridge begins to pass packets perfectly. BUT now rl0 is not reachable via anything, no even a ping. Login into the console for investigation I find this message: FreeBSD Kernel: Arp: 00:00:00:00:00 is using my IP address 192.168.30.254 FreeBSD Kernel: Arp: 11:11:11:11:11 is using my IP address 192.168.30.254 The 00 and 11 MACs address representing the MAC for the 2 NICs that are part of the bridge. 192.168.30.254 was the previously working admin interface accepting conections via SSH. Below is are 2 unanswered posts that are asking the same thing but both are regarding 4.8, I am using 5.2.1 http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-June/000586.html http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-December/002109.html Thanks, Russ __________________________________________________________ From owner-freebsd-net@FreeBSD.ORG Wed May 19 12:55: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 62D8B16A4CE; Wed, 19 May 2004 12:55:49 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D245343D2F; Wed, 19 May 2004 12:55:48 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i4JJqO7f019354; Wed, 19 May 2004 13:52:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 19 May 2004 13:53:38 -0600 (MDT) Message-Id: <20040519.135338.08457763.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20040519170105.GZ70900@cicely12.cicely.de> References: <40AA0A30.3020102@gddsn.org.cn> <20040519170105.GZ70900@cicely12.cicely.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: wsk@gddsn.org.cn cc: net@freebsd.org Subject: Re: cuaa0&ttyd0's bug? 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, 19 May 2004 19:55:49 -0000 In message: <20040519170105.GZ70900@cicely12.cicely.de> Bernd Walter writes: : On Tue, May 18, 2004 at 09:05:52PM +0800, wsk wrote: : > hi,folks: : > It seems that the ttyd0 isn't the dialin line to login , and : > the cuaa0 like is both the dialin/out device!under 4.9 above : > and 5.X .but the ttyd0 work well under 4.8. : > here is my test: : > I wanna direct connected two bsd box via a null-modem cable,on : > a box ,I congfiured the ttys as follow: : > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. : > ttyd0 "/usr/libexec/getty std.9600" dialup on secure : > ttyd1 "/usr/libexec/getty std.9600" dialup off secure : > and kill -HUP 1 : > on the other box , I use cu connenct the box: : > cu -l /dev/cuaa0 : > connected : > and then , nothing more i could recv! : > but if I confirgure the ttys as below: : > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. : > cuaa0 "/usr/libexec/getty std.9600" dialup on secure : > ttyd1 "/usr/libexec/getty std.9600" dialup off secure : > and do it like before i do , it worked! : > why???? It's a bug??? : : The behavour is intentional. : Your cable doesn't supply DCD signal. : Either use a cable with DCD suport or stay with cuaa. : It's OK to use cuaa if you don't need dialout support. or turn off modem flow control in the lock device... Warner From owner-freebsd-net@FreeBSD.ORG Wed May 19 13:02: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 A929316A4CE for ; Wed, 19 May 2004 13:02:48 -0700 (PDT) Received: from ack.Berkeley.EDU (ack.berkeley.edu [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F5743D31 for ; Wed, 19 May 2004 13:02:48 -0700 (PDT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id i4JJxxE03106; Wed, 19 May 2004 12:59:59 -0700 (PDT) Date: Wed, 19 May 2004 12:59:59 -0700 From: Mike Hunter To: Russell Adams Message-ID: <20040519195959.GA3046@ack.Berkeley.EDU> References: <1084994246.40abb2c6ef47a@500records.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1084994246.40abb2c6ef47a@500records.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: arp: is using my IP address again. 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, 19 May 2004 20:02:48 -0000 On May 19, "Russell Adams" wrote: > I have seen this question posted twice to the list each without any response. > Does anybody out there know if this is possible, a Yes or No, will do if you > can't offer anything else. If it is possible then how do we get rid of the > Arp/IP conflict problem. > > This is what I want to do: > > A transparent bridge with no IPs (2 NICs) > A 3rd NIC to access the box via SSH for monitoring and configuration. > > this is what I have done. > > xl0 and xl1 set up as a transparent bridge, no ips > rl0 set up as 192.168.30.254 on the LAN > Bridge is inbetween 192.168.30.1 (ROUTER to Internet) and 5500 Cisco Switch. > > I log in via SSH to configure the bridge via rl0, so far so good. I plug in the > bridge between the router and the switch via xl0 and xl1, the bridge begins to > pass packets perfectly. BUT now rl0 is not reachable via anything, no even a > ping. Login into the console for investigation I find this message: > > FreeBSD Kernel: Arp: 00:00:00:00:00 is using my IP address 192.168.30.254 > FreeBSD Kernel: Arp: 11:11:11:11:11 is using my IP address 192.168.30.254 > > The 00 and 11 MACs address representing the MAC for the 2 NICs that are part of > the bridge. 192.168.30.254 was the previously working admin interface accepting > conections via SSH. > > Below is are 2 unanswered posts that are asking the same thing but both are > regarding 4.8, I am using 5.2.1 > > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-June/000586.html > http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-December/002109.html I never had any trouble passing traffic, but I did get spurious arp error messages. In my /etc/rc.conf, I specifically disabled arp on the bridge interfaces, and the messages went away. I think I saw that suggestion on an archived mailing list post somewhere. Good luck, Mike From owner-freebsd-net@FreeBSD.ORG Wed May 19 14:56: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 2BF7016A502; Wed, 19 May 2004 14:56:56 -0700 (PDT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FFF643D41; Wed, 19 May 2004 14:56:55 -0700 (PDT) (envelope-from anderson@centtech.com) Received: from centtech.com (neutrino.centtech.com [10.177.171.220]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id i4JLtpE8046294; Wed, 19 May 2004 16:55:51 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <40ABD7C8.7050405@centtech.com> Date: Wed, 19 May 2004 16:55:20 -0500 From: Eric Anderson User-Agent: Mozilla Thunderbird 0.5 (X11/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Max NFSD processes 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, 19 May 2004 21:56:56 -0000 I have several heavily used NFS servers, currently running FreeBSD 4.9-RELEASE. I'm getting jammed up with all my nfsd processes being busy, so clients see slow connections to the server. I have the nfsd starting with a count of 20, which is the max set in the nfsd.c file. Are there any risks I should be aware of before bumping up the max to say 40, or even 50? What would it take to make this a sysctl adjustable value? Should the max be bumped higher by default nowdays? Thanks - any help/hints is appreciated. Eric -- ------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Today is the tomorrow you worried about yesterday. ------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Wed May 19 15:11:23 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 AB37316A4CE; Wed, 19 May 2004 15:11:23 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5426A43D1D; Wed, 19 May 2004 15:11:23 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i4JMApsA069924; Wed, 19 May 2004 17:10:51 -0500 (CDT) (envelope-from dan) Date: Wed, 19 May 2004 17:10:50 -0500 From: Dan Nelson To: Eric Anderson Message-ID: <20040519221048.GA86452@dan.emsphone.com> References: <40ABD7C8.7050405@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40ABD7C8.7050405@centtech.com> X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Max NFSD processes 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, 19 May 2004 22:11:23 -0000 In the last episode (May 19), Eric Anderson said: > I have several heavily used NFS servers, currently running FreeBSD > 4.9-RELEASE. I'm getting jammed up with all my nfsd processes being > busy, so clients see slow connections to the server. I have the nfsd > starting with a count of 20, which is the max set in the nfsd.c file. > > Are there any risks I should be aware of before bumping up the max to > say 40, or even 50? > > What would it take to make this a sysctl adjustable value? > > Should the max be bumped higher by default nowdays? What's the output of "ps ax | grep nfsd"? How much CPU does the last nfsd process have? If your backend storage is a RAID with lots of disks, and your last nfsd is actually getting some use, then bumping up the nfsds will probably help. Although if you're hitting a kernel bottleneck (locking for example), more nfsds won't do any good. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Wed May 19 16:03: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 9E29716A4CE for ; Wed, 19 May 2004 16:03:36 -0700 (PDT) Received: from europa.lunarpages.com (europa.lunarpages.com [64.235.234.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8925943D2F for ; Wed, 19 May 2004 16:03:36 -0700 (PDT) (envelope-from russ@500records.com) Received: from cpanel by europa.lunarpages.com with local (Exim 4.34) id 1BQaA4-0007xp-6b; Wed, 19 May 2004 16:07:44 -0700 Received: from 64.1.168.26 ([64.1.168.26]) by 500records.com (IMP) with HTTP for ; Wed, 19 May 2004 16:07:44 -0700 Message-ID: <1085008064.40abe8c024a10@500records.com> Date: Wed, 19 May 2004 16:07:44 -0700 From: Russell Adams To: Mike Hunter References: <1084994246.40abb2c6ef47a@500records.com> <20040519195959.GA3046@ack.Berkeley.EDU> In-Reply-To: <20040519195959.GA3046@ack.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 64.1.168.26 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - europa.lunarpages.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - 500records.com X-Source: X-Source-Args: X-Source-Dir: cc: freebsd-net@freebsd.org Subject: Re: arp: is using my IP address again. 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, 19 May 2004 23:03:36 -0000 Quoting Mike Hunter : > On May 19, "Russell Adams" wrote: > > > I have seen this question posted twice to the list each without any > response. > > Does anybody out there know if this is possible, a Yes or No, will do if > you > > can't offer anything else. If it is possible then how do we get rid of the > > Arp/IP conflict problem. > > > > This is what I want to do: > > > > A transparent bridge with no IPs (2 NICs) > > A 3rd NIC to access the box via SSH for monitoring and configuration. > > > > this is what I have done. > > > > xl0 and xl1 set up as a transparent bridge, no ips > > rl0 set up as 192.168.30.254 on the LAN > > Bridge is inbetween 192.168.30.1 (ROUTER to Internet) and 5500 Cisco > Switch. > > > > I log in via SSH to configure the bridge via rl0, so far so good. I plug in > the > > bridge between the router and the switch via xl0 and xl1, the bridge begins > to > > pass packets perfectly. BUT now rl0 is not reachable via anything, no even > a > > ping. Login into the console for investigation I find this message: > > > > FreeBSD Kernel: Arp: 00:00:00:00:00 is using my IP address 192.168.30.254 > > FreeBSD Kernel: Arp: 11:11:11:11:11 is using my IP address 192.168.30.254 > > > > The 00 and 11 MACs address representing the MAC for the 2 NICs that are > part of > > the bridge. 192.168.30.254 was the previously working admin interface > accepting > > conections via SSH. > > > > Below is are 2 unanswered posts that are asking the same thing but both > are > > regarding 4.8, I am using 5.2.1 > > > > > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-June/000586.html > > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2003-December/002109.html > > I never had any trouble passing traffic, but I did get spurious arp error > messages. In my /etc/rc.conf, I specifically disabled arp on the bridge > interfaces, and the messages went away. I think I saw that suggestion on > an archived mailing list post somewhere. > > Good luck, > > Mike > > I don't really mind the error messages, I just want it to work... the bridge works great, the problem is the 3rd admin NIC stops working as soon as the bridge interfeaces are up and running. Do you think that turning off arp will allow my 3rd NIC to start working again? I will give it a try and see what effect it has on the situation, thanks for you comments! Russ From owner-freebsd-net@FreeBSD.ORG Wed May 19 17:55: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 7780916A4CE; Wed, 19 May 2004 17:55:47 -0700 (PDT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B8AE43D2F; Wed, 19 May 2004 17:55:47 -0700 (PDT) (envelope-from anderson@centtech.com) Received: from centtech.com ([192.168.42.25]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id i4K0tfE8075672; Wed, 19 May 2004 19:55:42 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <40AC01F0.3030409@centtech.com> Date: Wed, 19 May 2004 19:55:12 -0500 From: Eric Anderson User-Agent: Mozilla Thunderbird 0.5 (X11/20040406) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Nelson References: <40ABD7C8.7050405@centtech.com> <20040519221048.GA86452@dan.emsphone.com> In-Reply-To: <20040519221048.GA86452@dan.emsphone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Max NFSD processes 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, 20 May 2004 00:55:47 -0000 Dan Nelson wrote: >In the last episode (May 19), Eric Anderson said: > > >>I have several heavily used NFS servers, currently running FreeBSD >>4.9-RELEASE. I'm getting jammed up with all my nfsd processes being >>busy, so clients see slow connections to the server. I have the nfsd >>starting with a count of 20, which is the max set in the nfsd.c file. >> >>Are there any risks I should be aware of before bumping up the max to >>say 40, or even 50? >> >>What would it take to make this a sysctl adjustable value? >> >>Should the max be bumped higher by default nowdays? >> >> > >What's the output of "ps ax | grep nfsd"? How much CPU does the last >nfsd process have? > >If your backend storage is a RAID with lots of disks, and your last >nfsd is actually getting some use, then bumping up the nfsds will >probably help. Although if you're hitting a kernel bottleneck (locking >for example), more nfsds won't do any good. > > Here's the output: 97 ?? Is 0:00.01 nfsd: master (nfsd) 99 ?? S 4:52.61 nfsd: server (nfsd) 100 ?? S 1:15.74 nfsd: server (nfsd) 101 ?? S 0:44.05 nfsd: server (nfsd) 102 ?? S 0:31.79 nfsd: server (nfsd) 103 ?? S 0:26.15 nfsd: server (nfsd) 104 ?? S 0:20.36 nfsd: server (nfsd) 105 ?? S 0:18.47 nfsd: server (nfsd) 106 ?? S 0:16.86 nfsd: server (nfsd) 107 ?? S 0:19.11 nfsd: server (nfsd) 108 ?? S 0:16.68 nfsd: server (nfsd) 109 ?? S 0:13.59 nfsd: server (nfsd) 110 ?? S 0:13.60 nfsd: server (nfsd) 111 ?? S 0:12.30 nfsd: server (nfsd) 112 ?? S 0:12.44 nfsd: server (nfsd) 113 ?? S 0:13.84 nfsd: server (nfsd) 114 ?? S 0:12.65 nfsd: server (nfsd) 115 ?? S 0:13.57 nfsd: server (nfsd) 116 ?? S 0:11.31 nfsd: server (nfsd) 117 ?? S 0:11.21 nfsd: server (nfsd) 118 ?? I 0:11.99 nfsd: server (nfsd) The machine has been up now less than 5 hours, and this is a 'quiet' time. During the 'slow' time, top showed the nfsd processes in "biorw" and "inode" states. All were consumed in those states. The machine has two raid 5 arrays, with a hardware raid controller. iostat showed xfer speeds to the first array about 2MB/s, and nothing really abnormal about it. Clients had difficulty with simple things like 'ls' on the partition. mountd was responding quickly with mount requests (I believe), but once the mount was made, accessing the nfs disk was horribly slow. Any more ideas? I'm not subscribed on -questions or -net, so please keep me on the cc's. Eric -- ------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Today is the tomorrow you worried about yesterday. ------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Wed May 19 18:20: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 9B9D116A4CE for ; Wed, 19 May 2004 18:20:58 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B266D43D1D for ; Wed, 19 May 2004 18:20:57 -0700 (PDT) (envelope-from flip@ecr.mu.oz.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i4K1KK4u032641 for ; Thu, 20 May 2004 11:20:20 +1000 Received: from ecr.mu.oz.au (ppp2513.dyn.pacific.net.au [61.8.37.19]) i4K1KILR013893 for ; Thu, 20 May 2004 11:20:19 +1000 Message-ID: <40AC07DB.10509@ecr.mu.oz.au> Date: Thu, 20 May 2004 11:20:27 +1000 From: Phillip Crumpler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 802.1x, HOSTAP, station association notifications 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, 20 May 2004 01:20:58 -0000 Hi folks! As part of a university project I'm building a IEEE 802.1x authenticator for use with wireless networks. The project is based upon a FreeBSD machine using a Prism based NIC in HOSTAP mode. The role of the authenticator is to selectively allow hosts use of the access point. Part of the authenticator (the PAE) is built as a netgraph module and the remainder (the EAPOL protocol state machines etc.) as user processes. The IEEE 802.1x protocol was largely framed with wired networks in mind but for use with 802.11 an 802.1x 'port' is represented by an asociation of a station with an access point. This means that the 802.1x implementation needs to know about associations and disassociations and I'm trying to find a way to do this. I need a neat and tidy way of notifying either a netgraph node or a user process about associations. Monitor/RFMON mode seems to be mutually exclusive with HOSTAP mode so that idea is out. The file sys/net80211/ieee80211_input.c in eee80211_recv_mgmt() has this directly after it processes an association request: /* give driver a chance to setup state like ni_txrate */ if (ic->ic_newassoc) (*ic->ic_newassoc)(ic, ni, newassoc); The only driver that seems to use this is ath. There seems to be no similar function pointer in struct ieee80211com for disassociation events. I'd like to be able to do this without modifying any FreeBSD files if possible, otherwise I could just add another member into struct ieee80211com and add newassoc and disassoc functions into if_wi.c. Can anyone shed some light on how I could achieve this? cheers, Phillip Crumpler flip@ecr.mu.oz.au From owner-freebsd-net@FreeBSD.ORG Wed May 19 19:03:37 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 21FD516A4CE; Wed, 19 May 2004 19:03:37 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62CD043D49; Wed, 19 May 2004 19:03:35 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i4K23MN7039715; Thu, 20 May 2004 10:03:23 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <40AC11DB.EBBB2827@kuzbass.ru> Date: Thu, 20 May 2004 10:03:07 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ruslan Ermilov References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> <20040519105646.GB25177@ip.net.ua> <20040519125138.GA58630@svzserv.kemerovo.su> <20040519161257.GA26262@ip.net.ua> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: Eugene Grosbein cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 20 May 2004 02:03:37 -0000 > > 1. Get FreeBSD 4.9-STABLE :-) > > 2. Install quagga from _fresh_ port collection (0.96.4 does NOT work) > > 3. run zebra and ripd, configure as usual. > > > They apparently do the thing equivalent to mrouted(8), and that's > not what I've understood from your email. Thanks anyway. ;) By the way, zebra doesn't depend on the kernel options MROUTING. Eugene From owner-freebsd-net@FreeBSD.ORG Wed May 19 22:55: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 0A9C516A4CF for ; Wed, 19 May 2004 22:55:07 -0700 (PDT) Received: from nickel.nocdirect.com (nickel.nocdirect.com [69.73.151.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B8643D41 for ; Wed, 19 May 2004 22:55:06 -0700 (PDT) (envelope-from rick@lgarchitecture.com) Received: from 66-215-127-98.slo-cbi.charterpipeline.net ([66.215.127.98] helo=lga2) by nickel.nocdirect.com with asmtp (Exim 4.34) id 1BQgW0-0006Sg-O0 for freebsd-net@freebsd.org; Thu, 20 May 2004 00:54:49 -0500 From: "Rick Richard" To: Date: Wed, 19 May 2004 22:55:00 -0700 Message-ID: <000c01c43e2e$fd7e7f40$7d0aa8c0@lgarchitecture.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nickel.nocdirect.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - lgarchitecture.com X-Source: X-Source-Args: X-Source-Dir: Subject: sk0 in 5.1.0 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, 20 May 2004 05:55:07 -0000 I'm having issues with a SysKonnect 9843 under FBSD 5.1. The card works fine on FBSD 4.9, but miibus cannot attach to it under 5.1. It complains that "No PHY found!," naturally, and then dies. If anyone has some insight on this, it would be greatly appreciated. -Rick From owner-freebsd-net@FreeBSD.ORG Thu May 20 01:32: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 BA6EC16A4CE for ; Thu, 20 May 2004 01:32:28 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0401C43D31 for ; Thu, 20 May 2004 01:32:28 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4K8buBe077148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2004 11:37:57 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4K8WPGD078622; Thu, 20 May 2004 11:32:25 +0300 (EEST) (envelope-from ru) Date: Thu, 20 May 2004 11:32:25 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040520083225.GB78561@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040518140857.GC20471@grosbein.pp.ru> <20040518151506.GC72684@ip.net.ua> <40AB35DE.DF743CCB@kuzbass.ru> <20040519105646.GB25177@ip.net.ua> <20040519125138.GA58630@svzserv.kemerovo.su> <20040519161257.GA26262@ip.net.ua> <40AC11DB.EBBB2827@kuzbass.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <40AC11DB.EBBB2827@kuzbass.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: Eugene Grosbein cc: net@FreeBSD.org Subject: Re: multicast arp entry 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, 20 May 2004 08:32:28 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 10:03:07AM +0800, Eugene Grosbein wrote: > > > 1. Get FreeBSD 4.9-STABLE :-) > > > 2. Install quagga from _fresh_ port collection (0.96.4 does NOT work) > > > 3. run zebra and ripd, configure as usual. > > > > > They apparently do the thing equivalent to mrouted(8), and that's > > not what I've understood from your email. Thanks anyway. ;) >=20 > By the way, zebra doesn't depend on the kernel options MROUTING. >=20 Zebra uses raw IP socket (fd 4 below) to send multicasts through multiple interfaces, so it's not a surprise: $ fstat -p 125 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root ospfd 125 root / 2 drwxr-xr-x 1024 r root ospfd 125 wd / 2 drwxr-xr-x 1024 r root ospfd 125 text /usr 24539 -r-xr-xr-x 426628 r root ospfd 125 1 / 1126 crw-rw-rw- null rw root ospfd 125 2 / 1126 crw-rw-rw- null rw root ospfd 125 3 / 1126 crw-rw-rw- null rw root ospfd 125 4* internet stream tcp d20ade00 root ospfd 125 5* internet raw ip d2905ec0 root ospfd 125 6* local stream d2f98dc0 Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArG0ZUkv4P6juNwoRAhC+AKCJENRMXr/15VGcdfP3yKdrZwyWcgCbBIZO J/LhGcRoeFGahhgzXzt8F80= =Rp4N -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 01:58: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 1704D16A4CF for ; Thu, 20 May 2004 01:58:48 -0700 (PDT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D34143D1F for ; Thu, 20 May 2004 01:58:47 -0700 (PDT) (envelope-from 4711@chello.at) Received: (qmail 35724 invoked from network); 20 May 2004 08:58:34 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 20 May 2004 08:58:34 -0000 From: Christian Hiris <4711@chello.at> To: freebsd-questions@freebsd.org Date: Thu, 20 May 2004 10:58:23 +0200 User-Agent: KMail/1.6.2 References: <40ABD7C8.7050405@centtech.com> In-Reply-To: <40ABD7C8.7050405@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_5MHrA4uYY/K2/Gd"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405201058.34008.4711@chello.at> cc: freebsd-net@freebsd.org cc: Eric Anderson Subject: Re: Max NFSD processes 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, 20 May 2004 08:58:48 -0000 --Boundary-02=_5MHrA4uYY/K2/Gd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 19 May 2004 23:55, Eric Anderson wrote: > I have several heavily used NFS servers, currently running FreeBSD > 4.9-RELEASE. I'm getting jammed up with all my nfsd processes being > busy, so clients see slow connections to the server. I have the nfsd > starting with a count of 20, which is the max set in the nfsd.c file. > > Are there any risks I should be aware of before bumping up the max to > say 40, or even 50? > > What would it take to make this a sysctl adjustable value? > > Should the max be bumped higher by default nowdays? > > Thanks - any help/hints is appreciated. > > Eric About a year ago i observed strong nfs performance decrease when using =20 RLT8139A nics. Nfs transfers leaded into high system load, because of an=20 excessive high packet retransmission rate. Switching over to 3Com nics solv= ed=20 my problem. =20 regards=20 ch =2D-=20 Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B=20 OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu --Boundary-02=_5MHrA4uYY/K2/Gd Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBArHM5cyi/EZQbawsRAh/xAJ9lwlcQ0u/izMzUFKzGvt5jDDKt/gCgmyb4 fWs/RwjNutFHP1zj156Sv8w= =oOij -----END PGP SIGNATURE----- --Boundary-02=_5MHrA4uYY/K2/Gd-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 02:24: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 4130616A4CE for ; Thu, 20 May 2004 02:24:39 -0700 (PDT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467C743D2D for ; Thu, 20 May 2004 02:24:38 -0700 (PDT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-12-111.w81-248.abo.wanadoo.fr [81.248.122.111]) by www.citello.it (Postfix) with ESMTP id E6E5D16FA for ; Thu, 20 May 2004 11:24:23 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id 3C628412F; Thu, 20 May 2004 11:17:53 +0200 (CEST) Date: Thu, 20 May 2004 11:17:52 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Message-Id: <20040520111752.10417492@localhost> In-Reply-To: <40AC07DB.10509@ecr.mu.oz.au> References: <40AC07DB.10509@ecr.mu.oz.au> 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: 802.1x, HOSTAP, station association notifications 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, 20 May 2004 09:24:39 -0000 On Thu, 20 May 2004 11:20:27 +1000 Phillip Crumpler wrote: [..] > I need a neat and tidy way of notifying either a netgraph node or a > user process about associations. [..] You did search the archives, did you? ;-) Have a look at the following thread: http://docs.FreeBSD.org/cgi/mid.cgi?39FE23FA-7F75-11D8-8F99-000A95CDA38A I would *love* to see all interested parties come up with a unified way of doing this, and contribute it to FreeBSD. marco From owner-freebsd-net@FreeBSD.ORG Thu May 20 03:05: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 E611F16A4CE; Thu, 20 May 2004 03:05:00 -0700 (PDT) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD42E43D4C; Thu, 20 May 2004 03:04:59 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (hc1.vuokselantie10.fi [193.64.42.193]) by rms04.rommon.net (8.12.10/8.12.9) with ESMTP id i4KA4g3v008937; Thu, 20 May 2004 13:04:43 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <40AC82B7.7040906@he.iki.fi> Date: Thu, 20 May 2004 13:04:39 +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: Christian Hiris <4711@chello.at> References: <40ABD7C8.7050405@centtech.com> <200405201058.34008.4711@chello.at> In-Reply-To: <200405201058.34008.4711@chello.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Eric Anderson cc: freebsd-questions@freebsd.org Subject: Re: Max NFSD processes 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, 20 May 2004 10:05:01 -0000 Christian Hiris wrote: > >About a year ago i observed strong nfs performance decrease when using >RLT8139A nics. Nfs transfers leaded into high system load, because of an >excessive high packet retransmission rate. Switching over to 3Com nics solved >my problem. > > The specific model and it's close relatives is only suitable for light use, like basic web surfing, small remote-monitoring applications, etc. The more recent realtek chips support more sane ways to access the hardware and wastly increased performance. You'll want RTL8139C+, RTL8169, etc. which use the "re" driver instead of the "rl" driver. Pete From owner-freebsd-net@FreeBSD.ORG Thu May 20 03:39: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 D3ECE16A4CE; Thu, 20 May 2004 03:39:15 -0700 (PDT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B41343D45; Thu, 20 May 2004 03:39:14 -0700 (PDT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i4KAd2gU071568; Thu, 20 May 2004 14:39:02 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 20 May 2004 14:38:56 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: freebsd-net@freebsd.org Message-ID: <20040520143249.K22933@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Paul Saab Subject: "thundering herd" problem in accept 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, 20 May 2004 10:39:15 -0000 Hi, I noticed rev 1.123 of src/sys/kern/uipc_socket2.c and two MFC's of the fix. Does it mean that the "thundering herd" problem in accept() appeared again in FreeBSD since 4.4-STABLE (after syncache was introduced) ? Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu May 20 04:47: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 586F616A4CE for ; Thu, 20 May 2004 04:47:18 -0700 (PDT) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36BE43D46 for ; Thu, 20 May 2004 04:47:17 -0700 (PDT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (unknown [211.96.21.195]) by gddsn.org.cn (Postfix) with ESMTP id C9F4A38CBE2; Thu, 20 May 2004 19:47:05 +0800 (CST) Message-ID: <40AC9AB7.6070109@gddsn.org.cn> Date: Thu, 20 May 2004 19:47:03 +0800 From: wsk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040409 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: Ian Smith , net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: cuaa0&ttyd0's bug? 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, 20 May 2004 11:47:18 -0000 Ian Smith : >Define the wiring of null-modem cable? DTR (tied to DSR) asserts CD the >other end, either way? RTS asserts CTS the other end, either way? > > > > > The behavour is intentional. > > Your cable doesn't supply DCD signal. > >Or it does, but RTS/CTS aren't wired right? (if used .. so many options!) > > > Either use a cable with DCD suport or stay with cuaa. > > It's OK to use cuaa if you don't need dialout support. > >Still depends on how cuaa0 and ttyd1 are defined, no? > >Cheers, Ian > > > > yep,It's my null-modem cable's probem O:-) ,and it works excellents with another null-modem!thanks again! From owner-freebsd-net@FreeBSD.ORG Thu May 20 06:01: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 5344D16A4CE; Thu, 20 May 2004 06:01:02 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 345F643D46; Thu, 20 May 2004 06:00:56 -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 i4KD0rY1000579; Thu, 20 May 2004 21:00:53 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4KD0qCY000578; Thu, 20 May 2004 21:00:52 +0800 (KRAST) (envelope-from eugen) Date: Thu, 20 May 2004 21:00:52 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040520130052.GA442@grosbein.pp.ru> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040518105134.GC70919@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: [ANALISYS] Re: multicast arp entry 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, 20 May 2004 13:01:02 -0000 On Tue, May 18, 2004 at 01:51:34PM +0300, Ruslan Ermilov wrote: > > got message of size 236 on Tue May 18 16:42:26 2004 > > RTM_ADD: Add Route: len 236, pid: 0, seq 0, errno 0, > > flags: > > locks: inits: > > sockaddrs: > > 224.0.0.9 1.0.5e.0.0.9 em3:0.7.e9.1f.f1.de 172.20.2.75 > > > > After that arp -an shows: > > (224.0.0.9) at 01:00:5e:00:00:09 on em3 permanent [ethernet] > > > > Then tcpdump shows that multicast packets with source IP of interface em1 > > (those must be directed via em1) go out through em3. I run quagga/ripd > > (same effect for zebra) on FreeBSD 4.9-STABLE. > > > > How do I find who installs this route? > > > The short answer is: the kernel adds it for you, automatically, > just as it does this for you for normal unicast destinations. > > The long answer could be: you could join to a single multicast > group on multiple interfaces, and you will be able to receive > multicast on all of them, but if you don't have multicast > forwarding enabled, only one interface will be used for sending. > Which one gets used will be determined by a normal routing > lookup, i.e., ``route -vn get -host 224.0.0.9'' where no entry > yet exists. Then, when the actual packet gets delivered, the > kernel will insert the corresponding ARP entry, mapping the > multicast group address to a MAC address. I've found that divert machanics is guilty in broken multicasts. Here is the scenario. 1. ripd assignes an outgoing interface for the mulicast socket using setsockopt (sock, IPPROTO_IP, IP_MULTICAST_IF, (void *)&m, sizeof(m)); 2. ripd runs: memset (&mreq, 0, sizeof(mreq)); mreq.imr_multiaddr.s_addr = mcast_addr; mreq.imr_interface = if_addr; /* (1) */ setsockopt (sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (void *)&mreq, sizeof(mreq)); This leads to igmp_joingroup(inm) and igmp_sendpkt(inm, inm->inm_rti->rti_type, 0), here inm->inm_ifp is filled with the contents of imo.imo_multicast_ifp, that is if_addr from (1). Still good. 3. Now we enter ip_output() keeping imo as one of arguments. There we run the following code: else if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && imo != NULL && imo->imo_multicast_ifp != NULL) { /* * Bypass the normal routing lookup for multicast * packets if the interface is specified. */ ifp = imo->imo_multicast_ifp; IFP_TO_IA(ifp, ia); isbroadcast = 0; /* fool gcc */ } It's allright still. 4. When ipfw diverts our packet, we call /* Deliver packet to divert input routine */ divert_packet(m, 0, off & 0xffff, args.divert_rule); Ops, imo is not passed by! So our imo->imo_multicast_ifp is lost and diverted packet will not be sent through it but routing lookup will be performed. Should I fill the PR? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu May 20 06:16: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 3B2E816A4CE for ; Thu, 20 May 2004 06:16:50 -0700 (PDT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 835E343D39 for ; Thu, 20 May 2004 06:16:49 -0700 (PDT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i4KDMGg5009195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 May 2004 16:22:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i4KDGTA9002245; Thu, 20 May 2004 16:16:29 +0300 (EEST) (envelope-from ru) Date: Thu, 20 May 2004 16:16:29 +0300 From: Ruslan Ermilov To: Eugene Grosbein Message-ID: <20040520131629.GL1664@ip.net.ua> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040520130052.GA442@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Re2uCLPLNzqOLVJA" Content-Disposition: inline In-Reply-To: <20040520130052.GA442@grosbein.pp.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: [ANALISYS] Re: multicast arp entry 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, 20 May 2004 13:16:50 -0000 --Re2uCLPLNzqOLVJA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 09:00:52PM +0800, Eugene Grosbein wrote: [...] > 3. Now we enter ip_output() keeping imo as one of arguments. > There we run the following code: >=20 > else if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) && > imo !=3D NULL && imo->imo_multicast_ifp !=3D NULL) { > /* > * Bypass the normal routing lookup for multicast > * packets if the interface is specified. > */ > ifp =3D imo->imo_multicast_ifp; > IFP_TO_IA(ifp, ia); > isbroadcast =3D 0; /* fool gcc */ > } >=20 > It's allright still. >=20 > 4. When ipfw diverts our packet, we call >=20 > /* Deliver packet to divert input routine */ > divert_packet(m, 0, off & 0xffff, args.divert_rule); >=20 > Ops, imo is not passed by! So our imo->imo_multicast_ifp is lost > and diverted packet will not be sent through it but routing lookup > will be performed. >=20 > Should I fill the PR? >=20 You're rather supposed to submit a working patch. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Re2uCLPLNzqOLVJA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArK+tUkv4P6juNwoRAqnmAJ9wTHhugHieevBKf/RL9EBlM7pgrgCeN++a abWCrmLJAvCP1gO93IwVCKo= =Vfxo -----END PGP SIGNATURE----- --Re2uCLPLNzqOLVJA-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 08:21:29 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 3769316A4CE; Thu, 20 May 2004 08:21:29 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9AB943D2D; Thu, 20 May 2004 08:21:28 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 8C4E2ACAE0; Thu, 20 May 2004 17:21:27 +0200 (CEST) Date: Thu, 20 May 2004 17:21:27 +0200 From: Pawel Jakub Dawidek To: Luigi Rizzo Message-ID: <20040520152127.GP845@darkness.comp.waw.pl> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <20040518034756.A9648@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nzBWqDnK1U3UjuAj" Content-Disposition: inline In-Reply-To: <20040518034756.A9648@xorpc.icir.org> 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 cc: andre@freebsd.org Subject: Re: ia_netbroadcast 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, 20 May 2004 15:21:29 -0000 --nzBWqDnK1U3UjuAj Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 18, 2004 at 03:47:56AM -0700, Luigi Rizzo wrote: +> On Tue, May 18, 2004 at 12:05:03PM +0200, Pawel Jakub Dawidek wrote: +> ... +> > +> > Do we still need ia_netboradcast field? It is calculated dependin= g on +> > +> > old-fashion classes (A, B, C). Is it used still? +> > +> > I wonder if ia_broadaddr isn't sufficient today. +> > +>=20 +> > +> not just that, it seems that ia_netboradcast contains bogus info. +> >=20 +> > So? +>=20 +> nuke it! +> Also if, as Andre said, it might be used by windows apps, +> one could certainly compute it on the fly from the IP address. Ok, this patch: http://people.freebsd.org/~pjd/patches/no_old_style_nets.patch removes ia_netbroadcast, ia_net, ia_netmask field from structure in_ifaddr and removes sysctl net.inet.ip.subnets_are_local as suggested in commit log of revision 1.24 of file netinet/in.c: Set subnetsarelocal to false. In a classless world, the other case is almost never useful. (This is only a quick hack; someone should go back and delete the entire subnetsarelocal=3D=3D1 code path.) Tests and comments are welcome. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --nzBWqDnK1U3UjuAj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArMz3ForvXbEpPzQRAriuAJ0WR07PWsqzQjyU5hUoEGLA1Ap9pACfftLx xUmWdjrNsdJZVuD5/Cqa1Ac= =TBGN -----END PGP SIGNATURE----- --nzBWqDnK1U3UjuAj-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 08:39: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 B0EF216A4CE for ; Thu, 20 May 2004 08:39:01 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FFF943D54 for ; Thu, 20 May 2004 08:39:01 -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 i4KFcwWR069634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 20 May 2004 08:38:58 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Thu, 20 May 2004 08:36:31 -0700 User-Agent: KMail/1.6.1 References: <40AC07DB.10509@ecr.mu.oz.au> <20040520111752.10417492@localhost> In-Reply-To: <20040520111752.10417492@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405200836.31526.sam@errno.com> Subject: Re: 802.1x, HOSTAP, station association notifications 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, 20 May 2004 15:39:01 -0000 On Thursday 20 May 2004 02:17 am, Marco Molteni wrote: > On Thu, 20 May 2004 11:20:27 +1000 > Phillip Crumpler wrote: > > [..] > > > I need a neat and tidy way of notifying either a netgraph node or a > > user process about associations. > > [..] > > You did search the archives, did you? ;-) > > Have a look at the following thread: > http://docs.FreeBSD.org/cgi/mid.cgi?39FE23FA-7F75-11D8-8F99-000A95CDA38A > > I would *love* to see all interested parties come up with a > unified way of doing this, and contribute it to FreeBSD. I pointed him at the madwifi project on sourceforge. It's a Linux port of the net80211 layer that now includes an 802.1x authenticator and soon will have WPA support too. Backporting to FreeBSD should be straightforward. For user-level notification I have some simple additions to kqueue to define new events equivalent to the Linux wireless extensions events (scan done, station associate, station deauth, station join, station leave). Sam From owner-freebsd-net@FreeBSD.ORG Thu May 20 08:44:45 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 AC75616A4CE; Thu, 20 May 2004 08:44:45 -0700 (PDT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28C1F43D46; Thu, 20 May 2004 08:44:45 -0700 (PDT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id i4KFihE8090393; Thu, 20 May 2004 10:44:44 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <40ACD24E.8010401@centtech.com> Date: Thu, 20 May 2004 10:44:14 -0500 From: Eric Anderson User-Agent: Mozilla Thunderbird 0.6 (X11/20040520) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Shorter References: <40ABD7C8.7050405@centtech.com> <20040520154459.GA99944@nomad.lets.net> In-Reply-To: <20040520154459.GA99944@nomad.lets.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Max NFSD processes 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, 20 May 2004 15:44:45 -0000 Steve Shorter wrote: >On Wed, May 19, 2004 at 04:55:20PM -0500, Eric Anderson wrote: > > >>I have several heavily used NFS servers, currently running FreeBSD >>4.9-RELEASE. I'm getting jammed up with all my nfsd processes being >>busy, so clients see slow connections to the server. I have the nfsd >>starting with a count of 20, which is the max set in the nfsd.c file. >> >>Are there any risks I should be aware of before bumping up the max to >>say 40, or even 50? >> >> > > Depending on where the bottlnecks in the system are, >you can crank this up to whatever works for you. > > I have tested and am running nfs servers with 80 >and 100 nfsd's with no problems at all > > That's good to hear. Did you do any other tweaks? sysctl settings? mbufs? >>What would it take to make this a sysctl adjustable value? >> >> > > > This isn't neccessary IM0, because the number of >nfd's can be set at runtime. But the default max in >nfsd.c should be increased. > > I meant a sysctl for the MAXNFSDCNT setting in nfsd.c. >>Should the max be bumped higher by default nowdays? >> >> > > Yep. > > > >>Thanks - any help/hints is appreciated. >> >> >> > > You probably also want good nics (fxp0) and to >increase UDP buffer space. I have found that nfs over udp >offers supperior performance than tcp on a good LAN > > I'm currently using 3com's (xl0,xl1) and Intel Gigabit cards (em0,em1). Most of my clients are using udp. What did you set your buffer space to? Which sysctl did you change? Thanks! Eric -- ------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Today is the tomorrow you worried about yesterday. ------------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Thu May 20 09:22: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 3F07516A4CF; Thu, 20 May 2004 09:22:14 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E8D43D54; Thu, 20 May 2004 09:22:12 -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 i4KGMAl1001516; Fri, 21 May 2004 00:22:10 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4KGMA76001515; Fri, 21 May 2004 00:22:10 +0800 (KRAST) (envelope-from eugen) Date: Fri, 21 May 2004 00:22:10 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040520162209.GA1362@grosbein.pp.ru> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040520130052.GA442@grosbein.pp.ru> <20040520131629.GL1664@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040520131629.GL1664@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: [ANALISYS] Re: multicast arp entry 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, 20 May 2004 16:22:14 -0000 On Thu, May 20, 2004 at 04:16:29PM +0300, Ruslan Ermilov wrote: > > Should I fill the PR? > > > You're rather supposed to submit a working patch. ;) I'm afraid I do not have enough knowledge :-( Eugene From owner-freebsd-net@FreeBSD.ORG Thu May 20 09:29: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 7707C16A4CE for ; Thu, 20 May 2004 09:29:22 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id ACEBD43D1F for ; Thu, 20 May 2004 09:29:20 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 8219 invoked from network); 20 May 2004 16:20:40 -0000 Received: from install.online.bg (HELO straylight.m.ringlet.net) (217.75.128.4) by gandalf.online.bg with SMTP; 20 May 2004 16:20:40 -0000 Received: (qmail 8217 invoked by uid 1000); 20 May 2004 16:29:19 -0000 Date: Thu, 20 May 2004 19:29:19 +0300 From: Peter Pentchev To: freebsd-net@FreeBSD.org Message-ID: <20040520162919.GA1971@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: [RFC] ifconfig: match by link-level address 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, 20 May 2004 16:29:22 -0000 --vGgW1X5XWziG23Ko Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I found out recently that the Linux (or at least recent RedHat) startup scripts could be configured to not bring up an Ethernet interface unless it has a specified MAC address. This, combined with the wonderful interface renaming functionality recently committed to -CURRENT, led me to the idea of interface renaming on boot-up, by hardware addresses - something like 'I don't care how you detected this network card, or how many others like it are there, but the card with MAC address 00:03:0d:08:dc:a7 will be known as sis0int from now on'. The main missing piece was the ability to find an interface by MAC address; hence the attached patch, also available at http://www.ringlet.net/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.patch http://people.FreeBSD.org/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.patch It teaches ifconfig(8) to treat interface "names" beginning with 'hw-' as link-level addresses; ifconfig tries to find an interface with this address and behaves as if its name was specified on the command line: [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> ./ifconfig hw-00:03:0d:08:dc:= a7 sis0: flags=3D8843 mtu 1500 options=3D8 inet 10.0.8.129 netmask 0xffff0000 broadcast 10.0.255.255 inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:03:0d:08:dc:a7 media: Ethernet autoselect (100baseTX ) status: active [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> This could be the first step towards teaching rc.conf about something like network_interfaces_rename=3D"hw-00:03:0d:08:dc:a7 sis0int" I had initially written my own function for parsing the user-supplied address into a sequence of bytes instead of using ether_aton(); it would have the advantage of being able to specify 'hw-' to match lo0's empty link-level "address". However, the odds of somebody actually wishing to rename lo0 don't seem to be so high :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just fin= ished reading. --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=windows-1251 Content-Disposition: attachment; filename="sbin-ifconfig-hwmatch.patch" Content-Transfer-Encoding: quoted-printable Index: src/sbin/ifconfig/ifconfig.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.104 diff -u -r1.104 ifconfig.c --- src/sbin/ifconfig/ifconfig.c 30 Apr 2004 22:34:12 -0000 1.104 +++ src/sbin/ifconfig/ifconfig.c 20 May 2004 16:02:44 -0000 @@ -145,6 +145,9 @@ void usage(void); void ifmaybeload(char *name); =20 +static char *findifname(const char *); +static void parseaddr(const char *, struct sockaddr_dl *); + #ifdef INET6 void in6_fillscopeid(struct sockaddr_in6 *sin6); int prefix(void *, int); @@ -509,6 +512,14 @@ if (argc < 1) usage(); =20 + if (!strncmp(*argv, "hw-", 3)) { + char *tmp; + =09 + tmp =3D findifname(*argv + 3); + if (tmp =3D=3D NULL) + errx(1, "no interface with address %s", *argv); + *argv =3D tmp; + } strncpy(name, *argv, sizeof(name)); argc--, argv++; =20 @@ -1947,3 +1958,57 @@ */ printname =3D 0; } + +/* + * Return the name of the interface with this link-level address, or NULL + */ +char * +findifname(const char *addr) +{ + struct ifaddrs *l, *c; + struct sockaddr_dl *sdl, templ; + char *name; +=09 + parseaddr(addr, &templ); + + if (getifaddrs(&l) =3D=3D -1) + err(1, "getifaddrs"); + name =3D NULL; + for (c =3D l; c !=3D NULL; c =3D c->ifa_next) { + if (c->ifa_addr =3D=3D NULL || c->ifa_addr->sa_family !=3D AF_LINK) + continue; + sdl =3D (struct sockaddr_dl *)c->ifa_addr; + if (sdl->sdl_alen =3D=3D templ.sdl_alen && + memcmp(sdl->sdl_data + sdl->sdl_nlen, + templ.sdl_data + templ.sdl_nlen, + sdl->sdl_alen) =3D=3D 0) { + name =3D strdup(c->ifa_name); + break; + } + } + freeifaddrs(l); + return (name); +} + +/* + * Parse the interface address into a sockaddr_dl structure + */ +static void +parseaddr(const char *addr, struct sockaddr_dl *dst) +{ + struct sockaddr_dl sdl; + struct ether_addr *e; + + /* Init the sockaddr_dl structure */ + memset(&sdl, 0, sizeof(sdl)); + sdl.sdl_len =3D sizeof(sdl); + sdl.sdl_family =3D AF_LINK; + sdl.sdl_nlen =3D 0; + e =3D ether_aton(addr); + if (e =3D=3D NULL) + errx(1, "Invalid link-level address format: %s", addr); + memcpy(sdl.sdl_data, e, sizeof(*e)); + sdl.sdl_alen =3D 6; + sdl.sdl_slen =3D 0; + memcpy(dst, &sdl, sizeof(*dst)); +} --5mCyUwZo2JvN/JJP-- --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArNzf7Ri2jRYZRVMRAqQAAJ9PRsutVwA1MbubrwFoM1Io3wNGvgCfYaBP SMiecWpec8Iga+Hg32tPqsU= =vUEg -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 09:58: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 6822F16A4CE; Thu, 20 May 2004 09:58:49 -0700 (PDT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B6143D49; Thu, 20 May 2004 09:58:47 -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 i4KGwjZe001743; Fri, 21 May 2004 00:58:45 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i4KGwj9Q001742; Fri, 21 May 2004 00:58:45 +0800 (KRAST) (envelope-from eugen) Date: Fri, 21 May 2004 00:58:45 +0800 From: Eugene Grosbein To: Ruslan Ermilov Message-ID: <20040520165845.GB1665@grosbein.pp.ru> References: <40A9CF72.85E2EC9D@kuzbass.ru> <20040518105134.GC70919@ip.net.ua> <20040520130052.GA442@grosbein.pp.ru> <20040520131629.GL1664@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040520131629.GL1664@ip.net.ua> User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Re: [ANALISYS] Re: multicast arp entry 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, 20 May 2004 16:58:49 -0000 > > Should I fill the PR? > You're rather supposed to submit a working patch. ;) OTOH, I'd rather wait and see how much time will it take for http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/51927 to be commited or carped. That another multicast problem is much simplier and PR contains a patch now. Eugene From owner-freebsd-net@FreeBSD.ORG Thu May 20 10:18: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 1609316A4CE for ; Thu, 20 May 2004 10:18:40 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0FAB43D1F for ; Thu, 20 May 2004 10:18:39 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i4KHIds0023972; Thu, 20 May 2004 10:18:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i4KHIc3s023971; Thu, 20 May 2004 10:18:38 -0700 Date: Thu, 20 May 2004 10:18:38 -0700 From: Brooks Davis To: Peter Pentchev Message-ID: <20040520171833.GA22494@Odin.AC.HMC.Edu> References: <20040520162919.GA1971@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20040520162919.GA1971@straylight.m.ringlet.net> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: [RFC] ifconfig: match by link-level address 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, 20 May 2004 17:18:40 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 07:29:19PM +0300, Peter Pentchev wrote: > Hi, >=20 > I found out recently that the Linux (or at least recent RedHat) startup > scripts could be configured to not bring up an Ethernet interface unless > it has a specified MAC address. This, combined with the wonderful > interface renaming functionality recently committed to -CURRENT, led me > to the idea of interface renaming on boot-up, by hardware addresses - > something like 'I don't care how you detected this network card, or how > many others like it are there, but the card with MAC address > 00:03:0d:08:dc:a7 will be known as sis0int from now on'. >=20 > The main missing piece was the ability to find an interface by MAC > address; hence the attached patch, also available at > http://www.ringlet.net/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.patch > http://people.FreeBSD.org/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.pa= tch >=20 > It teaches ifconfig(8) to treat interface "names" beginning with 'hw-' > as link-level addresses; ifconfig tries to find an interface with this > address and behaves as if its name was specified on the command line: >=20 > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> ./ifconfig hw-00:03:0d:08:d= c:a7 > sis0: flags=3D8843 mtu 1500 > options=3D8 > inet 10.0.8.129 netmask 0xffff0000 broadcast 10.0.255.255 > inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:03:0d:08:dc:a7 > media: Ethernet autoselect (100baseTX ) > status: active > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> >=20 > This could be the first step towards teaching rc.conf about something like > network_interfaces_rename=3D"hw-00:03:0d:08:dc:a7 sis0int" >=20 > I had initially written my own function for parsing the user-supplied > address into a sequence of bytes instead of using ether_aton(); it would > have the advantage of being able to specify 'hw-' to match lo0's empty > link-level "address". However, the odds of somebody actually wishing to > rename lo0 don't seem to be so high :) I don't really like the idea of adding magic values to the interface namespace that only work with ifconfig. If you want ifconfig to match the lladdr, I'd suggest adding a flag that means match interface by address instead of by name. That would be a fairly simple change to your patch and seems like a potentialy useful feature. FWIW, I've talked to Warner about automaticly renaming interfaces based on things like their MAC address or their PCI slot and we think devd will eventually be the place to do this. We're probably going to have to rethink interface configuration for this to work though. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFArOhnXY6L6fI4GtQRApoUAKDD137CCU8b/nKeWZCJ8h8+GIx3UQCfYRwu zkcgBHXgWn6uPNYOlZ2pRaU= =jUJD -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 10:30: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 0975316A4CE for ; Thu, 20 May 2004 10:30:14 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3D0243D46 for ; Thu, 20 May 2004 10:30:13 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 52698ACAE0; Thu, 20 May 2004 19:30:12 +0200 (CEST) Date: Thu, 20 May 2004 19:30:12 +0200 From: Pawel Jakub Dawidek To: freebsd-net@freebsd.org Message-ID: <20040520173012.GR845@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QUQ5hgLY738rkNmy" 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 Subject: Socket selection. 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, 20 May 2004 17:30:14 -0000 --QUQ5hgLY738rkNmy Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. In in_pcblookup_hash() function, in the last loop if we find exact match, we return immediately, if it is "wild", we store a pointer and we countinue looking for exact match. I wonder if this is ok, that we change pointer every time we find a "wild" match. Is it inteded? Shouldn't it be: http://people.freebsd.org/~pjd/patches/in_pcb.c.2.patch ? While I'm here, I want to improve code readability a bit: http://people.freebsd.org/~pjd/patches/in_pcb.c.3.patch Is it ok? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --QUQ5hgLY738rkNmy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArOskForvXbEpPzQRAuqYAJsEGP+3IZc3Iisjnnd5/gsPirjNlQCg99KE P07Vse12bNaTjw38fQHeQJs= =nweI -----END PGP SIGNATURE----- --QUQ5hgLY738rkNmy-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 13:55: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 91EE416A4CE for ; Thu, 20 May 2004 13:55:24 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEBF843D49 for ; Thu, 20 May 2004 13:55:23 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 45453 invoked from network); 20 May 2004 20:55:22 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 20 May 2004 20:55:22 -0000 Message-ID: <40AD1B39.AAF75D9D@freebsd.org> Date: Thu, 20 May 2004 22:55:21 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <20040518034756.A9648@xorpc.icir.org> <20040520152127.GP845@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 20 May 2004 20:55:24 -0000 Pawel Jakub Dawidek wrote: > > On Tue, May 18, 2004 at 03:47:56AM -0700, Luigi Rizzo wrote: > +> On Tue, May 18, 2004 at 12:05:03PM +0200, Pawel Jakub Dawidek wrote: > +> ... > +> > +> > Do we still need ia_netboradcast field? It is calculated depending on > +> > +> > old-fashion classes (A, B, C). Is it used still? > +> > +> > I wonder if ia_broadaddr isn't sufficient today. > +> > +> > +> > +> not just that, it seems that ia_netboradcast contains bogus info. > +> > > +> > So? > +> > +> nuke it! > +> Also if, as Andre said, it might be used by windows apps, > +> one could certainly compute it on the fly from the IP address. > > Ok, this patch: > > http://people.freebsd.org/~pjd/patches/no_old_style_nets.patch > > removes ia_netbroadcast, ia_net, ia_netmask field from structure > in_ifaddr and removes sysctl net.inet.ip.subnets_are_local as suggested > in commit log of revision 1.24 of file netinet/in.c: > > Set subnetsarelocal to false. In a classless world, the other case > is almost never useful. (This is only a quick hack; someone should > go back and delete the entire subnetsarelocal==1 code path.) > > Tests and comments are welcome. I have checked that at least Win2k doesn't use the classful broadcast address anymore. I don't know about older versions of Windows. However I'm not yet sure we (better I) understand all implications of removing the things you do in your patch. Please hold off for a moment until I've finished thinking and looking through the implications. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 20 13:57: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 2CD9216A4CF; Thu, 20 May 2004 13:57:39 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB8E243D3F; Thu, 20 May 2004 13:57:38 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 3AA8AAC995; Thu, 20 May 2004 22:57:37 +0200 (CEST) Date: Thu, 20 May 2004 22:57:37 +0200 From: Pawel Jakub Dawidek To: Andre Oppermann Message-ID: <20040520205737.GW845@darkness.comp.waw.pl> References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <20040518034756.A9648@xorpc.icir.org> <20040520152127.GP845@darkness.comp.waw.pl> <40AD1B39.AAF75D9D@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/O0dDd4i/4YhZnsV" Content-Disposition: inline In-Reply-To: <40AD1B39.AAF75D9D@freebsd.org> 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: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 20 May 2004 20:57:39 -0000 --/O0dDd4i/4YhZnsV Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 10:55:21PM +0200, Andre Oppermann wrote: +> > Ok, this patch: +> >=20 +> > http://people.freebsd.org/~pjd/patches/no_old_style_nets.patch +> >=20 +> > removes ia_netbroadcast, ia_net, ia_netmask field from structure +> > in_ifaddr and removes sysctl net.inet.ip.subnets_are_local as suggested +> > in commit log of revision 1.24 of file netinet/in.c: +> >=20 +> > Set subnetsarelocal to false. In a classless world, the other case +> > is almost never useful. (This is only a quick hack; someone should +> > go back and delete the entire subnetsarelocal=3D=3D1 code path.) +> >=20 +> > Tests and comments are welcome. +>=20 +> I have checked that at least Win2k doesn't use the classful broadcast +> address anymore. I don't know about older versions of Windows. +>=20 +> However I'm not yet sure we (better I) understand all implications of +> removing the things you do in your patch. Please hold off for a moment +> until I've finished thinking and looking through the implications. Don't worry. I'm not going to commit it before I hear clear "Go ahead!". --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --/O0dDd4i/4YhZnsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArRvBForvXbEpPzQRArHWAKDEk5Puq0OUDGpy2x0TRgCMpMemcgCfc6Ur NUG0S8cmF3X9dKr1b1IamjM= =EZbh -----END PGP SIGNATURE----- --/O0dDd4i/4YhZnsV-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 14:01: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 6FC5916A4CF for ; Thu, 20 May 2004 14:01:49 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9E443D45 for ; Thu, 20 May 2004 14:01:48 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 45803 invoked from network); 20 May 2004 21:01:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 20 May 2004 21:01:47 -0000 Message-ID: <40AD1CBA.4CB46233@freebsd.org> Date: Thu, 20 May 2004 23:01: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: Pawel Jakub Dawidek References: <20040520173012.GR845@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Socket selection. 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, 20 May 2004 21:01:49 -0000 Pawel Jakub Dawidek wrote: > > Hello. > > In in_pcblookup_hash() function, in the last loop if we find exact > match, we return immediately, if it is "wild", we store a pointer and > we countinue looking for exact match. > I wonder if this is ok, that we change pointer every time we find a > "wild" match. Is it inteded? Shouldn't it be: > > http://people.freebsd.org/~pjd/patches/in_pcb.c.2.patch No. This is a stack variable which is unconditionally initialized to NULL a few lines earlier. Checking for variable == NULL is always going to be true and makes your 'optimization' just redundand. > While I'm here, I want to improve code readability a bit: > > http://people.freebsd.org/~pjd/patches/in_pcb.c.3.patch > > Is it ok? No. You change the logic of the 'if' statements to something totally different. This ain't going to work in any way. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 20 14:11: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 078FA16A4CE; Thu, 20 May 2004 14:11:00 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 906D143D3F; Thu, 20 May 2004 14:10:59 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 290C8ACAE3; Thu, 20 May 2004 23:10:58 +0200 (CEST) Date: Thu, 20 May 2004 23:10:58 +0200 From: Pawel Jakub Dawidek To: Andre Oppermann Message-ID: <20040520211058.GX845@darkness.comp.waw.pl> References: <20040520173012.GR845@darkness.comp.waw.pl> <40AD1CBA.4CB46233@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RM4LNcG2CLff9Gl5" Content-Disposition: inline In-Reply-To: <40AD1CBA.4CB46233@freebsd.org> 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: Socket selection. 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, 20 May 2004 21:11:00 -0000 --RM4LNcG2CLff9Gl5 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 11:01:46PM +0200, Andre Oppermann wrote: +> Pawel Jakub Dawidek wrote: +> >=20 +> > Hello. +> >=20 +> > In in_pcblookup_hash() function, in the last loop if we find exact +> > match, we return immediately, if it is "wild", we store a pointer and +> > we countinue looking for exact match. +> > I wonder if this is ok, that we change pointer every time we find a +> > "wild" match. Is it inteded? Shouldn't it be: +> >=20 +> > http://people.freebsd.org/~pjd/patches/in_pcb.c.2.patch +>=20 +> No. This is a stack variable which is unconditionally initialized to +> NULL a few lines earlier. Checking for variable =3D=3D NULL is always +> going to be true and makes your 'optimization' just redundand. But we have loop there: local_wild =3D NULL; [...] LIST_FOREACH(...) { [...] local_wild =3D ; [...] } Isn't that possible that local_wild will be set few times? +> > While I'm here, I want to improve code readability a bit: +> >=20 +> > http://people.freebsd.org/~pjd/patches/in_pcb.c.3.patch +> >=20 +> > Is it ok? +>=20 +> No. You change the logic of the 'if' statements to something totally +> different. This ain't going to work in any way. Hmm, no: for (...) { if (a =3D=3D b && c =3D=3D d) { /* do something */ } /* nothing here */ } is equivalent to: for (...) { if (a !=3D b || c !=3D d) continue; /* do something */ } isn't it? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --RM4LNcG2CLff9Gl5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFArR7iForvXbEpPzQRAt/BAJoCHKo4w3fVXfRd8vIIhwj5V9NM/ACaApAM dSy1/HgFoYXDGBrp9GKstUw= =Q0QC -----END PGP SIGNATURE----- --RM4LNcG2CLff9Gl5-- From owner-freebsd-net@FreeBSD.ORG Thu May 20 14:27: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 455B316A4CE for ; Thu, 20 May 2004 14:27:15 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBBE043D31 for ; Thu, 20 May 2004 14:27:14 -0700 (PDT) (envelope-from ddenissov@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 13:38:12 -0400 Message-ID: From: Dmitri Denissov To: freebsd-net@freebsd.org Date: Thu, 20 May 2004 13:38:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: protecting netgraph calls from outside of the network context 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, 20 May 2004 21:27:15 -0000 Hi, Currently netgraph code uses splnet/splx to protect timeout calls. This doesn't work with 5.2 SMP kernel. What is the proper method here for a custom netgraph node? Is the Giant lock only the way? Thanks -- Dmitri From owner-freebsd-net@FreeBSD.ORG Thu May 20 14:33: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 7C82D16A4CE for ; Thu, 20 May 2004 14:33:55 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D68E43D48 for ; Thu, 20 May 2004 14:33:55 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <200405202133540130053b48e>; Thu, 20 May 2004 21:33:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA75111; Thu, 20 May 2004 14:33:53 -0700 (PDT) Date: Thu, 20 May 2004 14:33:52 -0700 (PDT) From: Julian Elischer To: Dmitri Denissov In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: protecting netgraph calls from outside of the network context 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, 20 May 2004 21:33:55 -0000 Ha! funny you should ask that exactly now.. I was just discussing this with Robert Watson.. The answer is "it depends on what you want to do". What DO you want to do and what does your node do? netgraph has internal locking in 5.x that you need to interact with but it should be pretty transparrent depending on what you are doing.. On Thu, 20 May 2004, Dmitri Denissov wrote: > Hi, > > Currently netgraph code uses splnet/splx to protect timeout calls. > This doesn't work with 5.2 SMP kernel. What is the proper method > here for a custom netgraph node? Is the Giant lock only the way? > > Thanks > > -- > Dmitri > > _______________________________________________ > 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 20 15:02: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 F253C16A4CE for ; Thu, 20 May 2004 15:02:40 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0314743D46 for ; Thu, 20 May 2004 15:02:40 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 48449 invoked from network); 20 May 2004 22:02:39 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 20 May 2004 22:02:39 -0000 Message-ID: <40AD2AFD.EA2470CC@freebsd.org> Date: Fri, 21 May 2004 00:02:37 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20040520173012.GR845@darkness.comp.waw.pl> <40AD1CBA.4CB46233@freebsd.org> <20040520211058.GX845@darkness.comp.waw.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Socket selection. 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, 20 May 2004 22:02:41 -0000 Pawel Jakub Dawidek wrote: > > On Thu, May 20, 2004 at 11:01:46PM +0200, Andre Oppermann wrote: > +> Pawel Jakub Dawidek wrote: > +> > > +> > Hello. > +> > > +> > In in_pcblookup_hash() function, in the last loop if we find exact > +> > match, we return immediately, if it is "wild", we store a pointer and > +> > we countinue looking for exact match. > +> > I wonder if this is ok, that we change pointer every time we find a > +> > "wild" match. Is it inteded? Shouldn't it be: > +> > > +> > http://people.freebsd.org/~pjd/patches/in_pcb.c.2.patch > +> > +> No. This is a stack variable which is unconditionally initialized to > +> NULL a few lines earlier. Checking for variable == NULL is always > +> going to be true and makes your 'optimization' just redundand. > > But we have loop there: > > local_wild = NULL; > [...] > LIST_FOREACH(...) { > [...] > local_wild = ; > [...] > } > > Isn't that possible that local_wild will be set few times? >From the loop as such it is. Normally the conditions leading to this code are that there is only one match. However you want to have the last match, not the first one. My statement in the first reply wasn't clear/correct enough I have to admit. ;-) The networking code is very tangled and obfuscated. The first thing we should do is to clean it up and make readable, self-consistent and logic again. This kind of micro-optimizations often open a can of worms and do not really improve things unless there true evidence (profiled) that this is a place where a lot of time is spent. > +> > While I'm here, I want to improve code readability a bit: > +> > > +> > http://people.freebsd.org/~pjd/patches/in_pcb.c.3.patch > +> > > +> > Is it ok? > +> > +> No. You change the logic of the 'if' statements to something totally > +> different. This ain't going to work in any way. > > Hmm, no: > > for (...) { > if (a == b && c == d) { > /* do something */ > } > /* nothing here */ > } > > is equivalent to: > > for (...) { > if (a != b || c != d) > continue; > /* do something */ > } > > isn't it? Well, from the second look it is indeed in this case. However it is obfusicated enough to be a show-stopper for this 'optimization'. The way it is now is far more logical and clearly expresses the intention of the check. Only do the following checks if 'a' and 'c' are true. Not the other way around. When someone is going to modify this loop later on I can virtually guarantee you that he'll fall into the trap with your changes. I probably would be baffled by the logic for the first moment and then I would curse you and revert it to be more obviously logic again... ;-) -- Andre From owner-freebsd-net@FreeBSD.ORG Thu May 20 15:14: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 88E1516A4CE for ; Thu, 20 May 2004 15:14:13 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C4A243D45 for ; Thu, 20 May 2004 15:14:13 -0700 (PDT) (envelope-from ddenissov@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Thu, 20 May 2004 18:14:12 -0400 Message-ID: From: Dmitri Denissov To: 'Julian Elischer' Date: Thu, 20 May 2004 18:14:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-net@freebsd.org Subject: RE: protecting netgraph calls from outside of the network context 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, 20 May 2004 22:14:13 -0000 This is kind of a bridge, connected to ng_ether interface nodes. Sometimes it queues received packets and later /on a timer call or a call from the user space/ it re-injects the packets using ng_send_data. > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Thursday, May 20, 2004 5:34 PM > > > Ha! funny you should ask that exactly now.. > I was just discussing this with Robert Watson.. > > The answer is "it depends on what you want to do". > > What DO you want to do and what does your node do? > netgraph has internal locking in 5.x that you need to > interact with but it should be pretty transparrent > depending on what you are doing.. > > > On Thu, 20 May 2004, Dmitri Denissov wrote: > > > Hi, > > > > Currently netgraph code uses splnet/splx to protect timeout calls. > > This doesn't work with 5.2 SMP kernel. What is the proper method > > here for a custom netgraph node? Is the Giant lock only the way? > > > > Thanks > > > > -- > > Dmitri From owner-freebsd-net@FreeBSD.ORG Thu May 20 15:14: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 E2EA916A4CE; Thu, 20 May 2004 15:14:53 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD9143D2F; Thu, 20 May 2004 15:14:53 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 7D9E0653AC; Thu, 20 May 2004 23:14:51 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08285-04-3; Thu, 20 May 2004 23:14:51 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id CF1F365381; Thu, 20 May 2004 23:14:50 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 5BF0D612E; Thu, 20 May 2004 23:14:48 +0100 (BST) Date: Thu, 20 May 2004 23:14:47 +0100 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20040520221447.GG86489@empiric.dek.spc.org> Mail-Followup-To: Andre Oppermann , Pawel Jakub Dawidek , Luigi Rizzo , freebsd-net@freebsd.org References: <20040518092439.GF845@darkness.comp.waw.pl> <20040518024346.A5068@xorpc.icir.org> <20040518100503.GG845@darkness.comp.waw.pl> <20040518034756.A9648@xorpc.icir.org> <20040520152127.GP845@darkness.comp.waw.pl> <40AD1B39.AAF75D9D@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40AD1B39.AAF75D9D@freebsd.org> cc: Luigi Rizzo cc: Pawel Jakub Dawidek cc: freebsd-net@freebsd.org Subject: Re: ia_netbroadcast 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, 20 May 2004 22:14:54 -0000 On Thu, May 20, 2004 at 10:55:21PM +0200, Andre Oppermann wrote: > However I'm not yet sure we (better I) understand all implications of > removing the things you do in your patch. Please hold off for a moment > until I've finished thinking and looking through the implications. I say can it. It appears to have outlived what little usefulness it might once have had. This is just based on a quick look over what it does in TCP/IP Illustrated Vol 2 and a look at where it's actually referenced within the kernel. If userland needs to see it, it can easily be served up on demand. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu May 20 15:21: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 C862016A4CE for ; Thu, 20 May 2004 15:21:28 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 880A143D41 for ; Thu, 20 May 2004 15:21:28 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004052022212701600aopm5e>; Thu, 20 May 2004 22:21:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA75602; Thu, 20 May 2004 15:21:25 -0700 (PDT) Date: Thu, 20 May 2004 15:21:24 -0700 (PDT) From: Julian Elischer To: Dmitri Denissov In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: RE: protecting netgraph calls from outside of the network context 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, 20 May 2004 22:21:28 -0000 On Thu, 20 May 2004, Dmitri Denissov wrote: > This is kind of a bridge, connected to ng_ether interface nodes. > Sometimes it queues received packets and later /on a timer call or a call > from the user space/ > it re-injects the packets using ng_send_data. > reinjects it to where? > > > From: Julian Elischer [mailto:julian@elischer.org] > > Sent: Thursday, May 20, 2004 5:34 PM > > > > > > Ha! funny you should ask that exactly now.. > > I was just discussing this with Robert Watson.. > > > > The answer is "it depends on what you want to do". > > > > What DO you want to do and what does your node do? > > netgraph has internal locking in 5.x that you need to > > interact with but it should be pretty transparrent > > depending on what you are doing.. > > > > > > On Thu, 20 May 2004, Dmitri Denissov wrote: > > > > > Hi, > > > > > > Currently netgraph code uses splnet/splx to protect timeout calls. > > > This doesn't work with 5.2 SMP kernel. What is the proper method > > > here for a custom netgraph node? Is the Giant lock only the way? > > > > > > Thanks > > > > > > -- > > > Dmitri > From owner-freebsd-net@FreeBSD.ORG Thu May 20 17:17: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 3276D16A4CE for ; Thu, 20 May 2004 17:17:10 -0700 (PDT) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BCE43D46 for ; Thu, 20 May 2004 17:17:10 -0700 (PDT) (envelope-from adam.mclaurin@gmx.net) Received: from 146-115-126-186.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([146.115.126.186] helo=jake) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #7) id 1BQxii-0002dH-00 for freebsd-net@freebsd.org; Thu, 20 May 2004 20:17:04 -0400 Date: Thu, 20 May 2004 20:16:57 -0400 From: Adam McLaurin To: freebsd-net@freebsd.org Message-Id: <20040520201657.56cb3ed8.adam.mclaurin@gmx.net> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.1; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Problems setting up Vonage VoIP with FreeBSD + ipfilter 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, 21 May 2004 00:17:10 -0000 So I got set up with Vonage VoIP, which I am really excited to have, but I am having a heck of a time getting it set up behind my FreeBSD box. My network configuration is as follows: Cable modem --> FreeBSD 5.2.1-R (ipf/ipnat) --> 8-port D-Link Switch --> Internal network The Vonage Voice Terminal (VT) is on port 8 of the switch So basically what I need to do is forward the following UDP ports to the VT (which I will be assigning 192.168.56.22). 53 69 5060-5061 10000-20000 So in my ipf.rules I added the following: pass in quick on dc0 proto udp from any to any port 9999 >< 20001 pass in quick on dc0 proto udp from any to any port = 53 pass in quick on dc0 proto udp from any to any port = 69 pass in quick on dc0 proto udp from any to any port = 5060 pass in quick on dc0 proto udp from any to any port = 5061 And in the ipnat.rules I added: rdr dc0 146.115.126.186/32 port 53 -> 192.168.56.22 port 53 udp rdr dc0 146.115.126.186/32 port 69 -> 192.168.56.22 port 69 udp rdr dc0 146.115.126.186/32 port 5060 -> 192.168.56.22 port 5060 udp rdr dc0 146.115.126.186/32 port 5061 -> 192.168.56.22 port 5061 udp Now, I'm not 100% certain the rdr's are correct (I'm not too comfortable with ipnat, and the docs confuse the hell out of me). However, I have absolutely no idea how to forward all UDP ports from 10000-20000 without manually writing a rule for each port (which seems to be a very bad idea just for the processing overhead on each incoming UDP packet). Can someone guide me through this? There aren't any Vonage How-To's for FreeBSD yet, so I'm pretty much flying blind. Thanks. -- Adam P.S. Please CC adam.mclaurin@gmx.net in your reply; I'm not actively subscribed to this list anymore From owner-freebsd-net@FreeBSD.ORG Thu May 20 18: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 C7B5F16A4CE for ; Thu, 20 May 2004 18:33:22 -0700 (PDT) Received: from phoenix.gargantuan.com (rrcs-se-24-73-171-238.biz.rr.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2681F43D1D for ; Thu, 20 May 2004 18:33:22 -0700 (PDT) (envelope-from michael@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 3571965; Thu, 20 May 2004 21:33:18 -0400 (EDT) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id B01091FF; Thu, 20 May 2004 21:32:40 -0400 (EDT) Date: Thu, 20 May 2004 21:32:40 -0400 From: "Michael W. Oliver" To: Adam McLaurin Message-ID: <20040521013240.GG4754@gargantuan.com> References: <20040520201657.56cb3ed8.adam.mclaurin@gmx.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <20040520201657.56cb3ed8.adam.mclaurin@gmx.net> User-Agent: Mutt/1.4.2.1i X-WWW-Site: http://michael.gargantuan.com X-PGP-Public-Key: $X-WWW-Site/gnupg/pubkey.asc X-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Home-Address0: 8008 Apache Lane X-Home-Address1: Lakeland, FL X-Home-Address2: 33810-2172 X-Home-Address3: United States of America X-Good-Question-Guide: http://www.catb.org/~esr/faqs/smart-questions.html X-Netiquette-Guidelines: http://www.ietf.org/rfc/rfc1855.txt X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, hits=-103.5 required=5.0 tests=AWL,BAYES_00, NO_DNS_FOR_FROM,USER_IN_WHITELIST autolearn=no version=2.63 cc: freebsd-net@freebsd.org Subject: Re: Problems setting up Vonage VoIP with FreeBSD + ipfilter 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, 21 May 2004 01:33:23 -0000 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-05-20T20:16:57-0400, Adam McLaurin wrote: > So I got set up with Vonage VoIP, which I am really excited to have, but > I am having a heck of a time getting it set up behind my FreeBSD box. >=20 > My network configuration is as follows: > Cable modem --> FreeBSD 5.2.1-R (ipf/ipnat) --> 8-port D-Link Switch --> > Internal network=20 >=20 > The Vonage Voice Terminal (VT) is on port 8 of the switch >=20 > So basically what I need to do is forward the following UDP ports to the > VT (which I will be assigning 192.168.56.22). > 53 > 69 > 5060-5061 > 10000-20000 Note that you don't need to allow incoming traffic to reach the VT on ports 53 or 69, you need to allow the VT to open outbound connections on those ports (DNS and TFTP, respectively). In addition, I had to open up outbound UDP on port 123 (NTP) as well, because even though I run NTP internally, the ATA's configuration is locked down and can't be changed (thanks Vonage :( ). > So in my ipf.rules I added the following: > pass in quick on dc0 proto udp from any to any port 9999 >< 20001 > pass in quick on dc0 proto udp from any to any port =3D 53 > pass in quick on dc0 proto udp from any to any port =3D 69 > pass in quick on dc0 proto udp from any to any port =3D 5060 > pass in quick on dc0 proto udp from any to any port =3D 5061 >=20 > And in the ipnat.rules I added: > rdr dc0 146.115.126.186/32 port 53 -> 192.168.56.22 port 53 udp > rdr dc0 146.115.126.186/32 port 69 -> 192.168.56.22 port 69 udp > rdr dc0 146.115.126.186/32 port 5060 -> 192.168.56.22 port 5060 udp > rdr dc0 146.115.126.186/32 port 5061 -> 192.168.56.22 port 5061 udp Also note that I am using IPFW2+NATD, but this looks ok (except for the 53 and 69, but we already talked about that :) > Now, I'm not 100% certain the rdr's are correct (I'm not too comfortable > with ipnat, and the docs confuse the hell out of me).=20 >=20 > However, I have absolutely no idea how to forward all UDP ports from > 10000-20000 without manually writing a rule for each port (which seems > to be a very bad idea just for the processing overhead on each incoming > UDP packet). Ok, I had the same problem, but I discovered that my ATA (I got mine when they sent out Cisco Analog Telephone Adapters, hence ATA) always uses port 10000, and the Vonage-side of the connection is always port 11000. I have been using the service for more than a year now and I haven't had a single occasion where the connection was anything other than what I just described. > Can someone guide me through this? There aren't any Vonage How-To's for > FreeBSD yet, so I'm pretty much flying blind. Like I said, I am using IPFW2+NATD, and the dummynet pipe/queue configuration works very well for giving my VoIP traffic plenty of bandwidth. I don't know if ipf has the same or similar facility, but it is worth looking into. I hope to soon be running pf+altq :D Hope this helps! --=20 Mike perl -e 'print unpack("u","88V]N=3D&%C=3D\"!I;F9O(&EN(&AE861E 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 A5C7E16A4CE; Thu, 20 May 2004 21:55:30 -0700 (PDT) Received: from mx3.mra.co.id (mx3.mra.co.id [202.138.254.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E2A43D46; Thu, 20 May 2004 21:55:27 -0700 (PDT) (envelope-from reza@mra.co.id) Received: from localhost (unknown [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id 8F5182E10C; Fri, 21 May 2004 12:06:00 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70617-25; Fri, 21 May 2004 12:04:45 +0700 (WIT) Received: from mail.mra.co.id (unknown [172.16.0.25]) by mx3.mra.co.id (Postfix) with ESMTP id 3D0FB2E159; Fri, 21 May 2004 12:04:45 +0700 (WIT) Received: from mra.co.id ([172.16.0.228]) by mail.mra.co.id with Microsoft SMTPSVC(5.0.2195.3779); Fri, 21 May 2004 11:52:04 +0700 Message-ID: <40AD8D44.5020508@mra.co.id> Date: Fri, 21 May 2004 12:01:56 +0700 From: Muhammad Reza User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2004 04:52:04.0108 (UTC) FILETIME=[5C5F6CC0:01C43EEF] X-Virus-Scanned: by amavisd-new at mra.co.id Subject: named in sandbox 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, 21 May 2004 04:55:30 -0000 dear All, I running named in sandbox as a secondary name server with FreeBSD-5.1.p17, Named log always complain: named-xfer exited with signal 6 and slave zone expired for every zone transfer. but, when it's running on default mode (no chroot sandbox) or as a primary server (with chroot sandbox). named work fine. please help me , how to make secondary zone transfer running in sandbox regards reza From owner-freebsd-net@FreeBSD.ORG Thu May 20 22:26: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 EB34C16A4CE for ; Thu, 20 May 2004 22:26:54 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6746043D39 for ; Thu, 20 May 2004 22:26:54 -0700 (PDT) (envelope-from ddenissov@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 May 2004 01:26:53 -0400 Message-ID: From: Dmitri Denissov To: 'Julian Elischer' , freebsd-net@freebsd.org Date: Fri, 21 May 2004 01:26:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: protecting netgraph calls from outside of the network context 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, 21 May 2004 05:26:55 -0000 On Thu, 20 May 2004, Julian Elischer wrote: > > This is kind of a bridge, connected to ng_ether interface nodes. > > Sometimes it queues received packets and later /on a timer > call or a call > > from the user space/ > > it re-injects the packets using ng_send_data. > > > > reinjects it to where? > To the adjacent ng_ether node connected via the lower hook. So the question is how to protect the ng_send_data() call originated from timer or user space context. > > > > > > From: Julian Elischer [mailto:julian@elischer.org] > > > Sent: Thursday, May 20, 2004 5:34 PM > > > > > > > > > Ha! funny you should ask that exactly now.. > > > I was just discussing this with Robert Watson.. > > > > > > The answer is "it depends on what you want to do". > > > > > > What DO you want to do and what does your node do? > > > netgraph has internal locking in 5.x that you need to > > > interact with but it should be pretty transparrent > > > depending on what you are doing.. > > > > > > > > > On Thu, 20 May 2004, Dmitri Denissov wrote: > > > > > > > Hi, > > > > > > > > Currently netgraph code uses splnet/splx to protect > timeout calls. > > > > This doesn't work with 5.2 SMP kernel. What is the > proper method > > > > here for a custom netgraph node? Is the Giant lock only the way? > > > > > > > > Thanks > > > > > > > > -- > > > > Dmitri > > > From owner-freebsd-net@FreeBSD.ORG Thu May 20 23:02: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 EC0EE16A4CE; Thu, 20 May 2004 23:02:55 -0700 (PDT) Received: from bigass1.bitblock.com (ns1.bitblock.com [66.199.170.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD2D43D41; Thu, 20 May 2004 23:02:55 -0700 (PDT) (envelope-from mitch@bitblock.com) Received: from a1200 ([24.83.187.201]) (AUTH: LOGIN mitch@bitblock.com) by bigass1.bitblock.com with esmtp; Fri, 21 May 2004 06:02:46 +0000 X-Abuse-Reports: Visit http://www.bitblock.com/abuse.php X-Abuse-Reports: and submit a copy of the message headers X-Abuse-Reports: or review our policies and procedures X-Abuse-Reports: ID= 40AD9B86.0000FBD3.bigass1.bitblock.com,dns; a1200 ([24.83.187.201]),AUTH: LOGIN mitch@bitblock.com From: "Mitch (bitblock)" To: "Muhammad Reza" , freebsd-net@freebsd.org, freebsd-questions@freebsd.org Date: Thu, 20 May 2004 23:02:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <40AD8D44.5020508@mra.co.id> Subject: RE: named in sandbox 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, 21 May 2004 06:02:56 -0000 You need to compile named-xfer as statically linked, or move it's dependant libraries into the chroot. Can't remember the details of how I did that, and I don't use named any more - but that's your problem. hope that helps. m/ > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Muhammad Reza > Sent: Thursday, May 20, 2004 10:02 PM > To: freebsd-net@freebsd.org; freebsd-questions@freebsd.org > Subject: named in sandbox > > > dear All, > > I running named in sandbox as a secondary name server with > FreeBSD-5.1.p17, > Named log always complain: > named-xfer exited with signal 6 and slave zone expired for every zone > transfer. > but, when it's running on default mode (no chroot sandbox) or as a > primary server (with chroot sandbox). named work fine. > please help me , how to make secondary zone transfer running in sandbox > > regards > reza > > _______________________________________________ > 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 20 23:44: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 D426E16A4CE for ; Thu, 20 May 2004 23:44:51 -0700 (PDT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C7143D54 for ; Thu, 20 May 2004 23:44:51 -0700 (PDT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-10-97.w81-248.abo.wanadoo.fr [81.248.120.97]) by www.citello.it (Postfix) with ESMTP id 255F916FA; Fri, 21 May 2004 08:44:49 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id 1778E4150; Fri, 21 May 2004 08:38:16 +0200 (CEST) Date: Fri, 21 May 2004 08:38:16 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Message-Id: <20040521083816.146b1169@localhost> In-Reply-To: <200405200836.31526.sam@errno.com> References: <40AC07DB.10509@ecr.mu.oz.au> <20040520111752.10417492@localhost> <200405200836.31526.sam@errno.com> 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 cc: Sam Leffler Subject: Re: 802.1x, HOSTAP, station association notifications 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, 21 May 2004 06:44:51 -0000 On Thu, 20 May 2004 Sam Leffler wrote: [..] > I pointed him at the madwifi project on sourceforge. It's a Linux > port of the net80211 layer that now includes an 802.1x authenticator > and soon will have WPA support too. Backporting to FreeBSD should be > straightforward. Sounds like the right approach :-) > For user-level notification I have some simple > additions to kqueue to define new events equivalent to the Linux > wireless extensions events (scan done, station associate, station > deauth, station join, station leave). This is exactly what I was interested in. Are you planning to commit this ? thanks marco From owner-freebsd-net@FreeBSD.ORG Fri May 21 00:04: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 D722016A4CE for ; Fri, 21 May 2004 00:04:52 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id D645F43D48 for ; Fri, 21 May 2004 00:04:50 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 22171 invoked from network); 21 May 2004 06:55:44 -0000 Received: from office.sbnd.net (HELO straylight.m.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 21 May 2004 06:55:42 -0000 Received: (qmail 5289 invoked by uid 1000); 21 May 2004 07:04:23 -0000 Date: Fri, 21 May 2004 10:04:23 +0300 From: Peter Pentchev To: Brooks Davis Message-ID: <20040521070422.GA1292@straylight.m.ringlet.net> References: <20040520162919.GA1971@straylight.m.ringlet.net> <20040520171833.GA22494@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <20040520171833.GA22494@Odin.AC.HMC.Edu> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: [RFC] ifconfig: match by link-level address 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, 21 May 2004 07:04:53 -0000 --XF85m9dhOBO43t/C Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 20, 2004 at 10:18:38AM -0700, Brooks Davis wrote: > On Thu, May 20, 2004 at 07:29:19PM +0300, Peter Pentchev wrote: > > Hi, > >=20 > > I found out recently that the Linux (or at least recent RedHat) startup > > scripts could be configured to not bring up an Ethernet interface unless > > it has a specified MAC address. This, combined with the wonderful > > interface renaming functionality recently committed to -CURRENT, led me > > to the idea of interface renaming on boot-up, by hardware addresses - > > something like 'I don't care how you detected this network card, or how > > many others like it are there, but the card with MAC address > > 00:03:0d:08:dc:a7 will be known as sis0int from now on'. > >=20 > > The main missing piece was the ability to find an interface by MAC > > address; hence the attached patch, also available at > > http://www.ringlet.net/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.pat= ch > > http://people.FreeBSD.org/~roam/bsd-patches/src5/sbin-ifconfig-hwmatch.= patch > >=20 > > It teaches ifconfig(8) to treat interface "names" beginning with 'hw-' > > as link-level addresses; ifconfig tries to find an interface with this > > address and behaves as if its name was specified on the command line: > >=20 > > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> ./ifconfig hw-00:03:0d:08= :dc:a7 > > sis0: flags=3D8843 mtu 1500 > > options=3D8 > > inet 10.0.8.129 netmask 0xffff0000 broadcast 10.0.255.255 > > inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255 > > ether 00:03:0d:08:dc:a7 > > media: Ethernet autoselect (100baseTX ) > > status: active > > [roam@straylight ~/fbsd/r/src/sbin/ifconfig]> > >=20 > > This could be the first step towards teaching rc.conf about something l= ike > > network_interfaces_rename=3D"hw-00:03:0d:08:dc:a7 sis0int" > >=20 > > I had initially written my own function for parsing the user-supplied > > address into a sequence of bytes instead of using ether_aton(); it would > > have the advantage of being able to specify 'hw-' to match lo0's empty > > link-level "address". However, the odds of somebody actually wishing to > > rename lo0 don't seem to be so high :) >=20 > I don't really like the idea of adding magic values to the interface > namespace that only work with ifconfig. If you want ifconfig to match > the lladdr, I'd suggest adding a flag that means match interface by > address instead of by name. That would be a fairly simple change to > your patch and seems like a potentialy useful feature. Agreed, I don't like the magic hw- too much either, but.. see below for more comments on this and interface renaming on startup. > FWIW, I've talked to Warner about automaticly renaming interfaces based > on things like their MAC address or their PCI slot and we think devd > will eventually be the place to do this. We're probably going to have > to rethink interface configuration for this to work though. Well, it turned out that adding basic interface renaming support to our startup scripts wasn't all that hard - the attached patch, also at http://www.ringlet.net/~roam/bsd-patches/src5/etc-iface-rename.patch http://people.FreeBSD.org/~roam/bsd-patches/src5/etc-iface-rename.patch seems to work for both 'sis0 ethlocal xl0 ethext' and 'hw-00:03:0d:08:dc:a7 ethlocal', since it just passes the interface name to ifconfig(8). If the link-level address matching should be done with a separate ifconfig(8) option, the interface renaming may need to be split into two stages controlled by two configuration variables - one specifying the 'source' interface by name, the other one by address, with the latter code using the new ifconfig option. Of course, this still leaves a problem with specifying the address for an interface that has not yet been 'found' - after all, we can't ifmaybeload() a driver on just the link-level address of the card. This is a case when devd might be a better solution indeed. However, I don't think that people who use interface renaming will depend on the system automatically discovering the *types* of network cards: if you know the MAC address of the card, you'll probably know just what brand and model it is, too :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn'= t! --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=windows-1251 Content-Disposition: attachment; filename="etc-iface-rename.patch" Content-Transfer-Encoding: quoted-printable Index: src/etc/defaults/rc.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.205 diff -u -r1.205 rc.conf --- src/etc/defaults/rc.conf 10 Apr 2004 22:13:27 -0000 1.205 +++ src/etc/defaults/rc.conf 20 May 2004 17:43:07 -0000 @@ -120,6 +120,7 @@ # NOTE: this violates the TCP specification icmp_drop_redirect=3D"NO" # Set to YES to ignore ICMP REDIRECT packets icmp_log_redirect=3D"NO" # Set to YES to log ICMP REDIRECT packets +network_interfaces_rename=3D"NO" # Network interface name pairs (or "NO") network_interfaces=3D"auto" # List of network interfaces (or "auto"). cloned_interfaces=3D"" # List of cloned network interfaces to create. #cloned_interfaces=3D"gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config. Index: src/etc/network.subr =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/etc/network.subr,v retrieving revision 1.153 diff -u -r1.153 network.subr --- src/etc/network.subr 11 Aug 2003 20:32:00 -0000 1.153 +++ src/etc/network.subr 21 May 2004 06:40:15 -0000 @@ -623,3 +623,35 @@ esac done } + +# Rename interfaces if the network_interfaces_rename variable is set +# to 'old new' pair(s), e.g. 'sis0 ethlocal xl0 ethext'. +rename_ifaces() +{ + echo -n 'Renaming interfaces: ' + case "${network_interfaces_rename}" in + [Nn][Oo] | '') + echo 'none' + ;; + + *) + if [ "$1" =3D 'stop' ]; then + set ${network_interfaces_rename} + _v=3D'' + while [ -n "$1" ]; do + _v=3D"$1 ${_v}" + shift + done + set ${_v} + else + set ${network_interfaces_rename} + fi + while [ -n "$2" ]; do + echo -n "$1 -> $2 " + ifconfig "$1" name "$2"=09 + shift 2 + done + echo 'done' + ;; + esac +} Index: src/etc/rc.d/netif =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/etc/rc.d/netif,v retrieving revision 1.7 diff -u -r1.7 netif --- src/etc/rc.d/netif 28 Apr 2004 13:20:15 -0000 1.7 +++ src/etc/rc.d/netif 21 May 2004 06:42:25 -0000 @@ -47,6 +47,9 @@ # We're operating as a general network start routine. # =20 + # Rename interfaces if requested + rename_ifaces start + # Create cloned interfaces clone_up =20 @@ -70,6 +73,9 @@ # Deconfigure the interface(s) network_common ifn_stop echo '.' +=09 + # Rename interfaces back if needed + rename_ifaces stop } =20 # network_common routine verbose Index: src/share/man/man5/rc.conf.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/share/man/man5/rc.conf.5,v retrieving revision 1.216 diff -u -r1.216 rc.conf.5 --- src/share/man/man5/rc.conf.5 28 Apr 2004 23:16:06 -0000 1.216 +++ src/share/man/man5/rc.conf.5 20 May 2004 17:54:22 -0000 @@ -860,6 +860,31 @@ Refer to .Xr ip 4 for more information. +.It Va network_interfaces_rename +.Pq Vt str +Set to a list of pairs of network interface names to rename on boot. +For example, if you want the +.Li sis0 +interface to be actually seen as +.Li ethlocal +and the +.Li xl0 +interface to be seen as +.Li ethext , +this could be set to +.Dq Li "sis0 ethlocal xl0 ethext" . +.Pp +Additionally, +.Xr ifconfig 8 +may allow specifying interfaces by link-level address by prefixing the +address with +.Dq hw- , +e.g. +.Dq Li hw-00:03:0d:08:dc:a7 . +In this case, you can set the +.Va network_interfaces_rename +variable to +.Dq Li "hw-00:03:0d:08:dc:a7 ethlocal" . .It Va network_interfaces .Pq Vt str Set to the list of network interfaces to configure on this host. --CE+1k2dSO48ffgeK-- --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAran27Ri2jRYZRVMRAi1QAKCiNo3BJvujhO3U8Hoa4gNs2mE2FACfdseW Cfk29nwRNk6FXB/GlH0uwc4= =x3b5 -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-net@FreeBSD.ORG Fri May 21 04:17: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 7DF7B16A4CE; Fri, 21 May 2004 04:17:04 -0700 (PDT) Received: from smtp.infracaninophile.co.uk (happy-idiot-talk.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0B4243D2D; Fri, 21 May 2004 04:17:03 -0700 (PDT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1])i4LBGiEn085763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2004 12:16:44 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)id i4LBGeee085758; Fri, 21 May 2004 12:16:40 +0100 (BST) (envelope-from matthew) Date: Fri, 21 May 2004 12:16:40 +0100 From: Matthew Seaman To: "Mitch (bitblock)" Message-ID: <20040521111640.GB31695@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: Matthew Seaman , "Mitch (bitblock)" , Muhammad Reza , freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <40AD8D44.5020508@mra.co.id> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20040504, clamav-milter version 0.70u X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on happy-idiot-talk.infracaninophile.co.uk cc: Muhammad Reza cc: freebsd-questions@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: named in sandbox 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, 21 May 2004 11:17:04 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org > > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Muhammad Reza > > I running named in sandbox as a secondary name server with > > FreeBSD-5.1.p17, > > Named log always complain: > > named-xfer exited with signal 6 and slave zone expired for every zone > > transfer. On Thu, May 20, 2004 at 11:02:46PM -0700, Mitch (bitblock) wrote: > You need to compile named-xfer as statically linked, or move it's dependa= nt > libraries into the chroot. Or switch to the BIND9 port which doesn't have a separate named-xfer executable -- the functionality is all rolled into the named binary, and that you don't have to copy into the chroot area in order to run chrooted. Look at this article for some pointers: http://othyro.freeshell.org/bind.html However, remember that's written netbsd-centrically, and you'll have to adapt the instructions for use under FreeBSD -- use ports instead of pkgsrc, and you'll need to investigate what to do to make devfs(8) create the requited device nodes under the chroot, rather than using mknod. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAreUYiD657aJF7eIRAqkqAJ9LUGk4S6szRs0biWMjaTgXPYmKnwCeLEVP 39ju5ox3uQd/wb+EBhR/G+Q= =FLFk -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-net@FreeBSD.ORG Fri May 21 04:22: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 A512A16A4CE for ; Fri, 21 May 2004 04:22:50 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 513BB43D3F for ; Fri, 21 May 2004 04:22:50 -0700 (PDT) (envelope-from louie@transsys.com) Received: from whizzo.transsys.com (localhost [127.0.0.1]) by whizzo.transsys.com (Postfix) with ESMTP id 615B220FFD; Fri, 21 May 2004 07:22:37 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Adam McLaurin Organization: Serendipity Scheduling & Management X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" References: <20040520201657.56cb3ed8.adam.mclaurin@gmx.net> In-reply-to: Your message of "Thu, 20 May 2004 20:16:57 EDT." <20040520201657.56cb3ed8.adam.mclaurin@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 May 2004 07:22:37 -0400 Sender: louie@transsys.com Message-Id: <20040521112237.615B220FFD@whizzo.transsys.com> cc: freebsd-net@freebsd.org Subject: Re: Problems setting up Vonage VoIP with FreeBSD + ipfilter 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, 21 May 2004 11:22:50 -0000 > So I got set up with Vonage VoIP, which I am really excited to have, but > I am having a heck of a time getting it set up behind my FreeBSD box. > > My network configuration is as follows: > Cable modem --> FreeBSD 5.2.1-R (ipf/ipnat) --> 8-port D-Link Switch --> > Internal network > > The Vonage Voice Terminal (VT) is on port 8 of the switch > > So basically what I need to do is forward the following UDP ports to the > VT (which I will be assigning 192.168.56.22). > 53 > 69 > 5060-5061 > 10000-20000 > > So in my ipf.rules I added the following: > pass in quick on dc0 proto udp from any to any port 9999 >< 20001 > pass in quick on dc0 proto udp from any to any port = 53 > pass in quick on dc0 proto udp from any to any port = 69 > pass in quick on dc0 proto udp from any to any port = 5060 > pass in quick on dc0 proto udp from any to any port = 5061 > > And in the ipnat.rules I added: > rdr dc0 146.115.126.186/32 port 53 -> 192.168.56.22 port 53 udp > rdr dc0 146.115.126.186/32 port 69 -> 192.168.56.22 port 69 udp > rdr dc0 146.115.126.186/32 port 5060 -> 192.168.56.22 port 5060 udp > rdr dc0 146.115.126.186/32 port 5061 -> 192.168.56.22 port 5061 udp > > Now, I'm not 100% certain the rdr's are correct (I'm not too comfortable > with ipnat, and the docs confuse the hell out of me). > > However, I have absolutely no idea how to forward all UDP ports from > 10000-20000 without manually writing a rule for each port (which seems > to be a very bad idea just for the processing overhead on each incoming > UDP packet). > > Can someone guide me through this? There aren't any Vonage How-To's for > FreeBSD yet, so I'm pretty much flying blind. I'm using a Vonage CPE device behind a FreeBSD firewall built with ifpw/natd. I did not have to add any inbound NAT mappings at all. Perhaps you should start with a simpler configuration? louie From owner-freebsd-net@FreeBSD.ORG Fri May 21 05:01: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 D109416A4D3 for ; Fri, 21 May 2004 05:01:04 -0700 (PDT) Received: from mail.8ball.co.za (8ball.co.za [196.22.201.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC66E43D39 for ; Fri, 21 May 2004 05:01:01 -0700 (PDT) (envelope-from nelis@8ball.co.za) Received: (qmail 13768 invoked by uid 89); 21 May 2004 12:00:53 -0000 Received: from unknown (HELO ?192.168.10.9?) (192.168.10.9) by 192.168.10.1 with SMTP; 21 May 2004 12:00:53 -0000 From: Nelis Lamprecht To: Matthew Seaman In-Reply-To: <20040521111640.GB31695@happy-idiot-talk.infracaninophile.co.uk> References: <40AD8D44.5020508@mra.co.id> <20040521111640.GB31695@happy-idiot-talk.infracaninophile.co.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fLOl6JKtQw0T/Uyc/HYr" Organization: 8ball Network Solutions Message-Id: <1085140854.7087.7.camel@nelis.brabys.co.za> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 21 May 2004 14:00:54 +0200 cc: Muhammad Reza cc: freebsd-questions@freebsd.org cc: "Mitch \(bitblock\)" cc: freebsd-net@freebsd.org Subject: Re: named in sandbox X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: nelis@8ball.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 12:01:05 -0000 --=-fLOl6JKtQw0T/Uyc/HYr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-05-21 at 13:16, Matthew Seaman wrote: > However, remember that's written netbsd-centrically, and you'll have > to adapt the instructions for use under FreeBSD -- use ports instead > of pkgsrc, and you'll need to investigate what to do to make devfs(8) > create the requited device nodes under the chroot, rather than using > mknod. >=20 You can simply symlink the device nodes: guardian# ls -la /var/chroot/named/dev/ total 4 drwxr-xr-x 2 bind bind 512 Mar 3 11:21 . drwx------ 5 bind bind 512 Mar 3 11:18 .. lrwxr-xr-x 1 root bind 9 Mar 3 11:21 null -> /dev/null lrwxr-xr-x 1 root bind 11 Mar 3 11:21 random -> /dev/random lrwxr-xr-x 1 root bind 9 Mar 3 11:21 zero -> /dev/zero Cheers, --=20 Nelis Lamprecht PGP: http://www.8ball.co.za/pgpkey/nelis.asc "Unix IS user friendly.. It's just selective about who its friends are." --=-fLOl6JKtQw0T/Uyc/HYr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAre92QfIMKiRMCrERAgDBAKCdVshSBeCj6UWDRoi7Kh7Trxk60ACdFqnX NklQnIHMGS986PkclnScAcI= =mV0v -----END PGP SIGNATURE----- --=-fLOl6JKtQw0T/Uyc/HYr-- From owner-freebsd-net@FreeBSD.ORG Fri May 21 06:36: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 4F78216A4CE for ; Fri, 21 May 2004 06:36:16 -0700 (PDT) Received: from relay.rinet.ru (relay.rinet.ru [195.54.192.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4725D43D2D for ; Fri, 21 May 2004 06:36:13 -0700 (PDT) (envelope-from flist@qqmore.rinet.ru) Received: from relay.rinet.ru (localhost [127.0.0.1]) by relay.rinet.ru (8.12.9p2/8.12.9) with ESMTP id i4LDZqYL038254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2004 17:35:53 +0400 (MSD) (envelope-from flist@qqmore.rinet.ru) Received: (from uucp@localhost)i4LDZqPF038253; Fri, 21 May 2004 17:35:52 +0400 (MSD) (envelope-from flist@qqmore.rinet.ru) Received: from qqmore.rinet.ru. (localhost.rinet.ru [127.0.0.1]) by qqmore.rinet.ru. (8.12.11/8.12.11) with ESMTP id i4LDZXxb003119; Fri, 21 May 2004 17:35:34 +0400 (MSD) (envelope-from flist@qqmore.rinet.ru) Received: (from flist@localhost) by qqmore.rinet.ru. (8.12.11/8.12.11/Submit) id i4LDZUf8003118; Fri, 21 May 2004 17:35:30 +0400 (MSD) (envelope-from flist) Date: Fri, 21 May 2004 17:35:30 +0400 From: Alex Semenyaka To: Brooks Davis Message-ID: <20040521133530.GA1403@qqmore.rinet.ru> Mail-Followup-To: Alex Semenyaka , Brooks Davis , Peter Pentchev , freebsd-net@freebsd.org References: <20040520162919.GA1971@straylight.m.ringlet.net> <20040520171833.GA22494@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040520171833.GA22494@Odin.AC.HMC.Edu> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: Peter Pentchev Subject: Re: [RFC] ifconfig: match by link-level address 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, 21 May 2004 13:36:16 -0000 On Thu, May 20, 2004 at 10:18:38AM -0700, Brooks Davis wrote: >> This could be the first step towards teaching rc.conf about something like >> network_interfaces_rename="hw-00:03:0d:08:dc:a7 sis0int" > I don't really like the idea of adding magic values to the interface > namespace that only work with ifconfig. If you want ifconfig to match I agree, but there is another option: make such things not ifconfig-specific. I mean that it could be done though renaming the interface into the some lladdr-dependent name with fixed format. For example, ifconfig fxp0 llname will rename fxp0 into hw-00-90-27-35-ca-0c. As far as we know the format and MAC-address we could then do ifconfig hw-00-90-27-35-ca-0c name pppoeint This could be implemented easely right now and then automated though /etc/rc* Actually the discussing feature is long time expected one, so it would be nice to have it implemented finally :) Sincerely, Alex Semenyaka From owner-freebsd-net@FreeBSD.ORG Fri May 21 06:58:09 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 0AAE016A4CF; Fri, 21 May 2004 06:58:09 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 331EF43D31; Fri, 21 May 2004 06:58:05 -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 i4LDw03F060447; Fri, 21 May 2004 17:58:00 +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 i4LDw04F060442; Fri, 21 May 2004 17:58:00 +0400 (MSD) (envelope-from yar) Date: Fri, 21 May 2004 17:58:00 +0400 From: Yar Tikhiy To: hackers@freebsd.org, net@freebsd.org Message-ID: <20040521135759.GE57132@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Bugfix for checksum offload in bge(4) 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, 21 May 2004 13:58:09 -0000 Hi folks, While sweeping network interface drivers for incorrect usage of the capabilities framework, I noticed some bugs in bge(4). Unfortunately, I have no such card and I don't know its internals. Therefore I made a patch fixing hw-independent bugs and marking some questionable spots. It would be nice if somebody possessing the knowledge on bge(4) reviewed this patch and used it to really fix the things. If nobody undertakes that, I'll just commit my change since it doesn't seem to affect the functionality while it brings the code into the shape. Thanks! The issues addressed by the patch are as follows: 1. The code responsible for initiating RX csum offload is ifdef'd out with a comment reading there were problems with that. Despite this fact, the RX csum offload is marked as supported and active in the if_cap* fields, and a user is allowed to toggle the bit, which is misleading. 2. The code for RX csum offload should not consult ifp->if_hwassist. The latter field is for informing the TCP/IP stack about available _TX_ offload features. The driver itself should use ifp->if_capenable to see which capabilities are active. 3. Presently bge(4) doesn't advertise its ability to compute the TCP/UDP checksum over a fragmented packet. However, there's code handling this case. Consequently, that code is ineffective. Since I knew nothing about the availability of the feature in bge(4), I just marked the spot with an XXX comment. 4. A network interface driver should keep if_hwassist in sync with if_capenable when the latter is altered through ioctl(); bge(4) fails to do so. -- Yar Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.63 diff -u -p -r1.63 if_bge.c --- if_bge.c 13 Jan 2004 11:31:09 -0000 1.63 +++ if_bge.c 21 May 2004 13:23:36 -0000 @@ -2371,7 +2371,8 @@ bge_attach(dev) ifp->if_mtu = ETHERMTU; ifp->if_snd.ifq_maxlen = BGE_TX_RING_CNT - 1; ifp->if_hwassist = BGE_CSUM_FEATURES; - ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | + /* XXX the code for RX csum offload is disabled for now */ + ifp->if_capabilities = IFCAP_TXCSUM | IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; ifp->if_capenable = ifp->if_capabilities; @@ -2722,7 +2723,7 @@ bge_rxeof(sc) m->m_pkthdr.rcvif = ifp; #if 0 /* currently broken for some packets, possibly related to TCP options */ - if (ifp->if_hwassist) { + if (ifp->if_capenable & IFCAP_RXCSUM) { m->m_pkthdr.csum_flags |= CSUM_IP_CHECKED; if ((cur_rx->bge_ip_csum ^ 0xffff) == 0) m->m_pkthdr.csum_flags |= CSUM_IP_VALID; @@ -3136,6 +3137,11 @@ bge_start_locked(ifp) /* * XXX + * The code inside the if() block is never reached since we + * must mark CSUM_IP_FRAGS in our if_hwassist to start getting + * requests to checksum TCP/UDP in a fragmented packet. + * + * XXX * safety overkill. If this is a fragmented packet chain * with delayed TCP/UDP checksums, then only encapsulate * it if we have enough descriptors to handle the entire @@ -3478,11 +3484,13 @@ bge_ioctl(ifp, command, data) break; case SIOCSIFCAP: mask = ifr->ifr_reqcap ^ ifp->if_capenable; - if (mask & IFCAP_HWCSUM) { - if (IFCAP_HWCSUM & ifp->if_capenable) - ifp->if_capenable &= ~IFCAP_HWCSUM; + /* XXX the code for RX csum offload is disabled for now */ + if (mask & IFCAP_TXCSUM) { + ifp->if_capenable ^= IFCAP_TXCSUM; + if (IFCAP_TXCSUM & ifp->if_capenable) + ifp->if_hwassist = BGE_CSUM_FEATURES; else - ifp->if_capenable |= IFCAP_HWCSUM; + ifp->if_hwassist = 0; } error = 0; break; From owner-freebsd-net@FreeBSD.ORG Fri May 21 07:26: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 DAE3C16A4CE; Fri, 21 May 2004 07:26:44 -0700 (PDT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EC0543D49; Fri, 21 May 2004 07:26:38 -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 i4LEQT3F062041; Fri, 21 May 2004 18:26:29 +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 i4LEQSns062040; Fri, 21 May 2004 18:26:29 +0400 (MSD) (envelope-from yar) Date: Fri, 21 May 2004 18:26:28 +0400 From: Yar Tikhiy To: "George V.Neville-Neil" Message-ID: <20040521142628.GA61458@comp.chem.msu.su> References: <20040521135759.GE57132@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: Bugfix for checksum offload in bge(4) 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, 21 May 2004 14:26:45 -0000 On Fri, May 21, 2004 at 11:11:41PM +0900, George V.Neville-Neil wrote: > > > > While sweeping network interface drivers for incorrect usage of the > > capabilities framework, I noticed some bugs in bge(4). Unfortunately, > > I have no such card and I don't know its internals. Therefore I > > made a patch fixing hw-independent bugs and marking some questionable > > spots. It would be nice if somebody possessing the knowledge on > > bge(4) reviewed this patch and used it to really fix the things. If > > nobody undertakes that, I'll just commit my change since it doesn't > > seem to affect the functionality while it brings the code into the shape. > > Thanks! > > I have such a card and can look into this. It may take a bit though, > perhaps a week or so. Thank you George, that would be great. A week is not a problem after it took me two months to spare time to make the patch :-) -- Yar From owner-freebsd-net@FreeBSD.ORG Fri May 21 07:47: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 D6FEE16A4CE; Fri, 21 May 2004 07:47:48 -0700 (PDT) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB38E43D2F; Fri, 21 May 2004 07:47:47 -0700 (PDT) (envelope-from andyh@hhbb.co.uk) Received: from [10.0.0.25] (hedgie1.gotadsl.co.uk [82.133.95.107]) by smtp.nildram.co.uk (Postfix) with ESMTP id 51D1C255DEB; Fri, 21 May 2004 15:47:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andy Holyer Date: Fri, 21 May 2004 15:47:25 +0100 To: net@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Wierd: double-header network card becomes quad header? 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, 21 May 2004 14:47:49 -0000 Our server has an twin-headed Intel Ether Express Gigabit ethernet adaptor. We've just upgraded the kernel to 5.2(RELEASE), and on reboot were unable to connect to the machine. My colleague is currently battling to repair the system over the phone to the tech up at telecity. What has happened is that in addition to the em0 and em1 devices we had before, there's now an em2 and an em3, which appear to be the active ones. Has anyone seen anything like this before? And yes, I had rebooted before, without proliferating interfaces... Here is the output of dmesg and ifconfig -a:: ------ Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-RELEASE #0: Thu May 20 22:08:26 BST 2004 joek@tiggywinkle.hhbb.co.uk:/usr/obj/home/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a34000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a3426c. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.40GHz (2400.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 1073479680 (1023 MB) avail memory = 1033322496 (985 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic1: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fc570 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pci1: on pcib1 em0: port 0xece0-0xecff mem 0xfe3e0000-0xfe3fffff irq 18 at device 1.0 on pci1 em0: Speed:N/A Duplex:N/A pcib2: at device 28.0 on pci0 pci2: on pcib2 em1: port 0xdcc0-0xdcff mem 0xfe1e0000-0xfe1fffff irq 24 at device 1.0 on pci2 em1: Speed:N/A Duplex:N/A em2: port 0xdc80-0xdcbf mem 0xfe1c0000-0xfe1dffff irq 25 at device 1.1 on pci2 em2: Speed:N/A Duplex:N/A uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 29.4 (no driver attached) pci0: at device 29.5 (no driver attached) pci0: at device 29.7 (no driver attached) pcib3: at device 30.0 on pci0 pci3: on pcib3 em3: port 0xccc0-0xccff mem 0xfdee0000-0xfdefffff irq 21 at device 2.0 on pci3 em3: Speed:N/A Duplex:N/A pci3: at device 14.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xfea0-0xfeaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.2 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A acpi_cpu1: on acpi0 device_probe_and_attach: acpi_cpu1 attach returned 6 orm0: