Date: Sat, 29 Jan 2000 17:01:37 +0900 From: Changhoon Kim <kimch@etri.re.kr> To: harp-bugs@magic.net Cc: FreeBSD ATM <FreeBSD-ATM@FreeBSD.ORG>, hschoi@etri.re.kr Subject: Shielding Mechanisms in ATMARP module of HARP Message-ID: <38929E61.E524CD88@etri.re.kr>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38929E61.E524CD88>