From owner-freebsd-hackers Fri May 24 00:16:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA04874 for hackers-outgoing; Fri, 24 May 1996 00:16:13 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA04821; Fri, 24 May 1996 00:15:27 -0700 (PDT) Received: (from rbezuide@localhost) by zibbi.mikom.csir.co.za (8.7.5/8.7.3) id JAA13069; Fri, 24 May 1996 09:15:19 +0200 (SAT) From: R Bezuidenhout Message-Id: <199605240715.JAA13069@zibbi.mikom.csir.co.za> Subject: Panic: route add -net !! To: hackers@freebsd.org Date: Fri, 24 May 1996 09:15:18 +0200 (SAT) Cc: wollman@freebsd.org X-Mailer: ELM [version 2.4ME+ PL16 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all One of our customers tried the following on a machine running 2.1-STABLE and got a kernel panic. I also tried this on a local machine, which fictious IP numbers :) and got the same result: /etc/hosts 12.12.12.12 ddd.csir.co.za ddd 13.13.13.0 ccc.csir.co.za ccc Now!! duzi# route add -net ccc ddd This causes the system to panic. I know that the 13.13.13.0 entry should actually be in the /etc/networks file, I have tested that and that seems to work fine, no panic. I know that putting the network entry in the hosts file is wrong, but I think it should not cause a kernel panic. If you use exactly the same command, but substitute the IP numbers e.g. route add -net 13.13.13.0 12.12.12.12 then it works fine. I traced the problem through /sbin/route and saw that the problem occurs in the following section: /usr/src/sbin/route/route.c line 137: NEXTADDR(RTA_IFP, so_ifp); NEXTADDR(RTA_IFA, so_ifa); rtm.rtm_msglen = l = cp - (char *)&m_rtmsg; if (verbose) print_rtmsg(&rtm, l); if (debugonly) return (0); if ((rlen = write(s, (char *)&m_rtmsg, l)) < 0) { perror("writing to routing socket"); return (-1); } When the write(s, (char *)&m_rtmsg, l)) is done it causes the panic. I've compared it with the one using IP numbers instead of aliases and there seems to be a netmask entry missing in &rtm (the verbose printing) I traced this to /usr/src/sbin/route/route.c line 852 if (((val = inet_addr(s)) != -1) && (which != RTA_DST || forcenet == 0)) { su->sin.sin_addr.s_addr = val; if (inet_lnaof(su->sin.sin_addr) != INADDR_ANY) return (1); else { val = ntohl(val); goto netdone; } } if ((val = inet_network(s)) != -1 || ((np = getnetbyname(s)) != NULL && (val = np->n_net) != 0)) { netdone: if (which == RTA_DST) inet_makenetandmask(val, &su->sin); return (0); } hp = gethostbyname(s); if (hp) { *hpp = hp; su->sin.sin_family = hp->h_addrtype; bcopy(hp->h_addr, (char *)&su->sin.sin_addr, hp->h_length); return (1); When using aliases the first two if statements fail and ends up at hp = gethostbyname(s); ... the call works fine but no netmask is added like in the second if with inet_makenetandmask(val, &su->sin); When using IP numbers the second if is true and inet_makenetandmask(val, &su->sin); is executed and a netmask added. If I use the aliases BUT add -netmask 255.255.255.0 at the end, the call succeeds and there is no panic. I'm not sure if this should be fixed in /sbin/route or a check added in the kernel. Next follows the panic log written by the kernel: May 23 15:24:39 duzi /kernel: Fatal trap 12: page fault while in kernel mode May 23 15:24:41 duzi /kernel: fault virtual address = 0x4 May 23 15:24:42 duzi /kernel: fault code = supervisor read, page not present May 23 15:24:42 duzi /kernel: instruction pointer = 0x8:0xf0133523 May 23 15:24:43 duzi /kernel: code segment = base 0x0, limit 0xffff f, type 0x1b May 23 15:24:43 duzi /kernel: = DPL 0, pres 1, def32 1, gran 1 May 23 15:24:44 duzi /kernel: processor eflags = interrupt enabled, resume, IOP L = 0 May 23 15:24:44 duzi /kernel: current process = 13407 (route) May 23 15:24:45 duzi /kernel: interrupt mask = May 23 15:24:45 duzi /kernel: panic: page fault May 23 15:24:45 duzi /kernel: And with nm /kernel earch_m f013265c T _rn_refines f01326f0 T _rn_lookup f0132744 t _rn_satsifies_leaf f01327b4 T _rn_match f0132924 T _rn_newpair f013297c T _rn_insert f0132ac8 T _rn_addmask f0132d10 t _rn_lexobetter f0132d70 t _rn_new_radix_mask f0132e1c T _rn_addroute f0133184 T _rn_delete f01334ec T _rn_walktree_from ***** looks like this is it !!! f01335f8 T _rn_walktree f01336a0 T _rn_inithead f01337a4 T _rn_init f0133880 F raw_cb.o f0133880 T _raw_attach f01338ec T _raw_detach f013392c T _raw_disconnect f0133950 F raw_usrreq.o f0133950 T _raw_init f013396c T _raw_input f0133ab8 T _raw_ctlinput f0133ac8 T _raw_usrreq Thanx Reinier ######################################################################## # # # Reinier Bezuidenhout Company: Mikomtek CSIR, ZA # # # # Network Engineer - NetSec development team # # # # Current Projects: NetSec - Secure Platform firewall system # # http://www.mikom.csir.co.za # # # # E-mail: rbezuide@mikom.csir.co.za # # # ########################################################################