[Openswan Users] kernel 2.4.26 + Openswan 2.1.4 + net-snmp-5.1 = Kernel Oops

[Ted Kaczmarek]

On Sun, 2004-08-01 at 06:27, Martin Bene wrote:
> Martin Bene wrote:
> 
> Looked at this some more; Not restricted to Openswan 2.1.4, also happens 
> with 2.2.0dr2 and with current strongswan release.
> 
> 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
> 
> 
Would it be possible to get more info as to where this stands?
Maybe the Openswan maintainers can touch base with the Net-snmp
maintainers and work this out or vice versa. 

Ted