[Openswan Users] BUG with Freeswan/Openswan and SNMPD

[Martin Bene]

> > > 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

interfaces:

<agent/mibgroup/mibII/interfaces.c>
...
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

purpose.

ipsec however uses SIOCDEVPRIVATE completely differently:

/* attach a virtual ipsec? device to a physical device */
#define IPSEC_SET_DEV (SIOCDEVPRIVATE)


==> 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
ipsec.

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