From owner-freebsd-atm Wed Jan 26 18:39:43 2000 Delivered-To: freebsd-atm@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id B5CE5154F4 for ; Wed, 26 Jan 2000 18:39:39 -0800 (PST) (envelope-from sschrode@pacbell.net) Received: from pacbell.net ([63.200.49.43]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FOZ00FZ83697U@mta1.snfc21.pbi.net> for freebsd-atm@freebsd.org; Wed, 26 Jan 2000 18:34:57 -0800 (PST) Date: Wed, 26 Jan 2000 18:34:57 -0800 From: Stephen Schroder Subject: Modem Driver To: freebsd-atm@freebsd.org Message-id: <388FAED1.EEE7A8AF@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm currently using Windows 98, but would like to install freeBSD to another partition. Problem: My modem is an Efficient Networks SpeedStream 4060 ADSL USB modem. Does anybody know of a driver for this modem? Apparently this newsgroup operates from a list server, and I don't subscribe. So please reply directly. Murray Stokely at support@cdrom.com suggested I run this question by you. Thank you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message From owner-freebsd-atm Sat Jan 29 0: 1:44 2000 Delivered-To: freebsd-atm@freebsd.org Received: from etri.re.kr (mail.etri.re.kr [129.254.113.113]) by hub.freebsd.org (Postfix) with ESMTP id 1BC58157F8 for ; Sat, 29 Jan 2000 00:01:38 -0800 (PST) (envelope-from kimch@etri.re.kr) Received: from etri.re.kr (kimch.etri.re.kr [129.254.191.142]) by etri.re.kr (8.9.3/8.9.3) with ESMTP id QAA27407; Sat, 29 Jan 2000 16:59:35 +0900 (KST) Message-ID: <38929E61.E524CD88@etri.re.kr> Date: Sat, 29 Jan 2000 17:01:37 +0900 From: Changhoon Kim X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: ko,en MIME-Version: 1.0 To: harp-bugs@magic.net Cc: FreeBSD ATM , hschoi@etri.re.kr Subject: Shielding Mechanisms in ATMARP module of HARP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, there. I've been using HARP on FreeBSD Release 3.x since last May. And I think, for the most part, the performance and the reliablity of HARP is quite satisfactory. Thank you. But, recently, I've experienced a frustrating situation on my FreeBSD boxes. The situation can be described as followings. We have 4 FreeBSD boxes in a CLIP LIS which is composed of a Fore ASX200-WG switch and several (fifteen or more) ATM end hosts. At the end host, we use one of four different kinds of ATM NICs: ENI-155p, PCA200E, ForeRunnerLE-25(25 Mbps), and VIRATA LINK (25 Mbps). Since we have some more ATM LISs, at first, we had used a Linux box as an IP router to connect the LIS with others. But, because the stability and the reliability of the ATM over Linux didn't meet our expectation, we changed the router's OS to FreeBSD Release 3.4 about two weeks ago. The machine that we chose to make a new router had been used in the LIS as an end host for about 6 months without any problems. Of course, we didn't do anyting but editting /etc/rc.conf to change the machine's configuration. However !! The new FreeBSD router couldn't last barely twenty minutes before collapsing by a kernel panic. And the message printed on a console at the kernel panic was "m_copydata". OK... time to plunge into kernel codes. On the basis of the "m_copydata" message, I tried to locate the original place where the panic stemmed from. And I found that "uniarp_cpcs_data( )" function which is implemented in "/sys/netatm/uni/uniarp_input.c" draws the kernel panic. As you know, "uniarp_cpcs_data( )" process ATMARP input data such as ATMARP_REQUEST, REPLY, InATMARP_REQUEST, REPLY etc. Specifically, at the line 161 of uniarp_input.c, KB_COPYDATA macro calls m_copydata( ) implemented in /sys/kern/uipc_mbuf.c, and at the third panic( ) in m_copydata( ) was the place where my kernel collapsed. To verify why the KB_COPYDATA results in a panic at the end, I printed the contents of mbuffs which were transferred to the KB_COPYDATA( ) at the line 161, and finally I could catch an ATMARP packet which eventually caused the kernel panic. Following is the contents of the ATMARP packet header. "00 13 08 00 00 00 00 08 04 00 00 00" (in hexadecimal, 12 bytes long) According to RFC 1577 and RFC 2225, the first four bytes and 7th and 8th bytes are correct, because 0x0013 in the first two bytes denotes ATM Forum's address family, 0x0800 in the 3th and 4th bytes denotes IP's protocol type, and 0x0008 in the 7th and 8th bytes denotes InARP_REQUEST's operation code. But, consequent 0x00s in the 5th and the 6th bytes is IMPOSSIBLE as far as I know, because the 5th byte is the type & length field for source ATM address, and the 6th is for source ATM subaddress. Every InATMARP_REQUEST have to fill the ARP packet's source ATM address field with either E.164 or NSAP address. Moreover, the length (m->m_len) of the InATMARP_REQUEST packet was only just 14 bytes ! It means that, excluding the common header (12 bytes), the payload of the ATMARP packet was just 2 bytes length. God ! I suspected that the absurd ATMARP packet might be generated by a poorly written CLIP driver which is supplied with one of the NICs which we used. So I checked from which SVC the problematic ATMARP packets were received. After a couple of hours monitoring, I found that the packet is generated by VIRATA LINK ATM NICs. (I've heard that VIRATA has stopped producing ATM NICs since '97.) Anyway, let's concentrate on just HARP. I believe that, although this problem was resulted from an errorneous behavior of the third party manufacturer's equipments (Yes, I know I can not assert yet.), FreeBSD kernel have to be safe enough not to be collapsed by this kind of subtle bug. This time, I just solved this problem by modifying uniarp_input.c as shown in the appendix of this mail. But, I think we need more secure shielding mechanisms in ATMARP module of HARP in order to protect a kernel adequately. In my humble opinion, if an OS could be called a decent one, the crash of the kernel have to be occurred just by hardware errors. And, most of all, I want to believe that FreeBSD is one of the most stable and reliable OS running on a PC. Thanks for reading this long mail. Regards. Changhoon. ********************** Appendix *************************** "uniarp_input.c" is the modified file to protect kernel from panic, and "uniarp_input.c.old" is the original file. ********************************************************** [root@tbani-er4:/sys/netatm/uni 101 ]diff -urN ./uniarp_input.c ./uniarp_input.c.old --- ./uniarp_input.c Tue Jan 25 17:20:13 2000 +++ ./uniarp_input.c.old Sat Jan 29 15:10:25 2000 @@ -88,10 +88,6 @@ struct atmarp_hdr *ahp; KBuffer *n; int len, plen = sizeof(struct atmarp_hdr); - /* CHKIM */ - char buf[50]; - unsigned short int i; - /* CHKIM */ #ifdef DIAGNOSTIC if (uniarp_print) @@ -160,18 +156,6 @@ } if (len = ahp->ah_spln) { - /* CHKIM */ - if ((satmsub.address_length == 0) && - (satm.address_length == 0)) { - printf("BAD ATMARP HDR DETECTED !!!\nATMARP Header : "); - KB_COPYDATA(m, 0, 12, buf); - for(i=0; i<12; i++) { - printf("%lx ",buf[i]); - } - printf("\n"); - goto bad; /* Just Discarding the problematic ATMARP packet ! */ - } - /* CHKIM */ if (len != sizeof(struct in_addr)) goto bad; if (KB_COPYDATA(m, plen, len, (caddr_t)&sip)) -- =========================================================== Changhoon Kim Internet Technology Research Dept. Switching & Transmission Technology Lab. Electronics and Telecommunications Research Institute(ETRI) 161 Kajong-dong, Yusong-gu, Taejon, 305-350, KOREA Tel: (Office) +82-42-860-5801, (Cell) +82-19-226-6305 E-mail: kimch@etri.re.kr * All Smiles, Everywhere and Everytime ! =========================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message From owner-freebsd-atm Sat Jan 29 16:56:10 2000 Delivered-To: freebsd-atm@freebsd.org Received: from marcos.networkcs.com (marcos.networkcs.com [137.66.16.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B95A15617 for ; Sat, 29 Jan 2000 16:56:05 -0800 (PST) (envelope-from mks@us.networkcs.com) Received: from us.networkcs.com (us.networkcs.com [137.66.11.15]) by marcos.networkcs.com (8.9.3/8.9.3) with ESMTP id SAA52508; Sat, 29 Jan 2000 18:55:56 -0600 (CST) (envelope-from mks@us.networkcs.com) Received: (from mks@localhost) by us.networkcs.com (8.9.2/8.9.2) id SAA35392; Sat, 29 Jan 2000 18:55:55 -0600 (CST) (envelope-from mks) From: Mike Spengler Message-Id: <200001300055.SAA35392@us.networkcs.com> Subject: Re: Shielding Mechanisms in ATMARP module of HARP To: kimch@etri.re.kr (Changhoon Kim) Date: Sat, 29 Jan 2000 18:55:55 -0600 (CST) Cc: harp-bugs@magic.net, FreeBSD-ATM@FreeBSD.ORG (FreeBSD ATM), hschoi@etri.re.kr In-Reply-To: <38929E61.E524CD88@etri.re.kr> from "Changhoon Kim" at Jan 29, 2000 05:01:37 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-atm@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Changhoon Kim claims: > > The new FreeBSD router couldn't last barely twenty minutes before > collapsing by a kernel panic. > And the message printed on a console at the kernel panic was > "m_copydata". > > OK... time to plunge into kernel codes. > [nice analysis of the problem deleted...] Thanks for digging into the problem - your analysis is right on! > > Anyway, let's concentrate on just HARP. > I believe that, although this problem was resulted from an errorneous > behavior of the third party manufacturer's equipments (Yes, I know I can > not assert yet.), FreeBSD kernel have to be safe enough not to be > collapsed by this kind of subtle bug. > Yes, the kernel code must protect itself from badly/illegally formed packets. > This time, I just solved this problem by modifying uniarp_input.c as > shown in the appendix of this mail. But, I think we need more secure > shielding mechanisms in ATMARP module of HARP in order to protect a > kernel adequately. > The basic problem here is that the semantics of m_copydata() don't exactly match those expected by the KB_COPYDATA() macro. The macro is designed to notify the caller if all the data requested to be copied was not all present in the mbuf chain - m_copydata() assumes the caller already knows the data is present. I will have to rewrite the KB_COPYDATA() macro to DTRT. > In my humble opinion, if an OS could be called a decent one, the crash > of the kernel have to be occurred just by hardware errors. And, most of > all, I want to believe that FreeBSD is one of the most stable and > reliable OS running on a PC. > No argument here!! Thanks again for the problem report. -- Mike Spengler Network Computing Services, Inc. Email: mks@networkcs.com 1200 Washington Ave. So. Phone: +1 612 337 3557 Minneapolis MN 55415 FAX: +1 612 337 3400 (aka Minnesota Supercomputer Center) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-atm" in the body of the message