[Openswan Users] BUG with Freeswan/Openswan and SNMPD

Martin Bene martin.bene at icomedias.com
Tue Aug 10 19:44:38 CEST 2004

> > > I can reproduce it on a new machine:
> > > 
> > > 1. Install Fedora Core 1
> > > 2. Install apt-get and do a full update of the system.
> > > 3. Install the openswan kernel from atrpms.net
> > > 4. Install openswan userland tools from atrpms.net
> > > 5. Start snmpd and do the interface statistic with CACTI
> > > -> After some minutes I get the kernel oops.
> > Paul
> This is on a RH9 with Openswan 2.1.4-1  and net-snmp-5.0.9-2.90.1.

Problem occurs when snmpd tries to figure out transmission speed for the


if (ioctl(fd, 0x8947, &ifr) >= 0) {
     new_ioctl_nums = 1;
} else if (ioctl(fd, SIOCDEVPRIVATE, &ifr) >= 0) {
     new_ioctl_nums = 0;

So, it first tries SIOCGMIIREG ioctl; if that doesn't work, it falls 
back to SIOCDEVPRIVATE which seems to have been previously used for this


ipsec however uses SIOCDEVPRIVATE completely differently:

/* attach a virtual ipsec? device to a physical device */

==> Result: ipsec bombs out trying to handle SIOCDEVPRIVATE ioctl for 
(already configured) ipsec0.

which leaves us with the question: what's the right fix?
	a) remove the fallback SIOCDEVPRIVATE call from snmpd
	b) add a SIOCGMIIREG ioctl to ipsec
	c) handle the spurious SIOCDEVPRIVATE ioctl more gracefully in

I've just verified that removing the fallback to SIOCDEVPRIVATE from 
snmp works as a fix, no more problems with openswan+snmp daemon. What I 
can't say if this might impact snmpd functionality when used with older 
kernels/drivers that implement only SIOCDEVPRIVATE.

Bye, Martin

More information about the Users mailing list