From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 10:42:00 2003 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 5D71A16A4B3 for ; Wed, 22 Oct 2003 10:42:00 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62FE143F3F for ; Wed, 22 Oct 2003 10:41:59 -0700 (PDT) (envelope-from gnagelhout@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <4CQ6N5GP>; Wed, 22 Oct 2003 13:41:58 -0400 Message-ID: From: Gerrit Nagelhout To: freebsd-net@freebsd.org Date: Wed, 22 Oct 2003 13:41:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Non-contiguous ifIndex problems with ifMib sysctl 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, 22 Oct 2003 17:42:00 -0000 Hi, I am trying to debug a crash (null pointer access) in sysctl_ifdata (in if_mib.c). What I have noticed is that if interfaces (in this case vlans) are created and destroyed dynamically, it is possible to create "holes" in the ifnet_addrs structure. For example, if I start with the following interfaces: 1 em0 2 em1 3 lo0 and then do: ifconfig vlan1 create ifconfig vlan2 create ifconfig vlan1 destroy I end up with: 1 em0 2 em1 3 lo0 4 0 5 vlan2 In this case, the net.link.generic.system.ifcount is set to 4. If an application (like slurm) then calls sysctl on net.link.generic.ifdata., and loops from 1 to 5 for ifIndex, it will crash when it gets to 4 because there are no checks for these holes, and 4 is less than if_index. I have also noticed that an snmpwalk to a system like this will have the proper interface count, but will only show the interfaces before the hole. It's easy enough to add the null check in sysctl_ifdata, and just return ENOENT, but that won't fix the snmpwalk problem. How should applications generally deal with this? Thanks, Gerrit