Re: linux-ipsec: Latest snapshot and 2.0.35

From: Michael H. Warfield <mhw(at)alcove.wittsend.com>
Date: Sat Aug 01 1998 - 16:41:06 EDT

        I'm back again...

Henry Spencer enscribed thusly:

> > ...I just tried switching the freeswan
> > lib routines from  to  and from  to
> >  and that covered all three problems, the htonl, the ntohl,
> > and the strcpy...

> Okay, the library has been updated to sort this out, and to build a
> separate kernel version accordingly.  The kernel version builds cleanly

> under RH4.2, with no unwanted external references; with any luck it will > do the same under RH5.1. New snapshot in half an hour or so.

        'Fraid not... Just got around to testing both the July31 and the Aug1 snapshots and they are seriously messed up under RedHat 5.1. They compile fine under 4.2 but this is just the start of the errors I'm seeing under 5.1:

] make[2]: Entering directory `/usr/src/freeswan-snap1998Aug1/lib/ktmp'

        This goes on for several screens worth of errors...

        I've only spent a little bit of time rooting around but it seems like we've ended up missing some symbols which SHOULD have come over, ultimately, from <asm/posix_types.h> but I'm not totally sure yet. I'm not even close to getting this one to compile yet. It may be something really simple, and probably is, but I haven't been able to nail it yet...

        I now have noticed another REALLY STRANGE problem over on the 4.2 system. Actually, it seems that I've had this problem for a while, I just didn't realize it. I noticed that the snapshots are dumping all of the utilities into /usr/local/lib/ipsec now. I still had pluto, tncfg, spi, et al in /usr/local/sbin and that's what I had been running, thinking they had been getting updated.

        When I realized the mistake, I removed all of the utilities from /usr/local/sbin and tried to use the ones in /usr/local/lib/ipsec. Guess what... They didn't work... First thing that I noticed was that pluto silently exits without doing anything. No pluto process, no syslog messages, no nothing... If I compile him with debug, he does at least come up and stay up... If I compile him without debug, he exits. And I'm not mistaking his "daemon" fork for an exit... There is no pluto process running after I get the prompt back...

        Next problem I noticed was that tncfg is also not working! I ran the old syntax "tncfg attach ipsec0 eth0" and got informed of the new syntax (first red letter warning that I had NOT been running the new utilities prior to this!). When I ran tncfg with the new syntax I got the following error:

] wittsend:/usr/local/lib/ipsec# ./tncfg --attach --virtual ipsec0 --physical eht0
] ./tncfg: Socket ioctl failed on attach -- No such device. Is the ipsec module linked into the kernel or loaded as a module?
] wittsend:/usr/local/lib/ipsec#

        Strange that the old (0.85) tncfg did't give me this error...

        Note: ipsec is loaded and the ipsec dev does exist...

] wittsend:/usr/local/lib/ipsec# lsmod
] Module Pages Used by
] ipsec 18 0
] wittsend:/usr/local/lib/ipsec# ls /proc/net/
] alias_types ip_forward ipsec_eroute ipsec_version sockstat
] aliases ip_input ipsec_spi raw tcp
] arp ip_masq_app ipsec_spigrp route udp
] dev ip_masquerade ipsec_spinew rt_cache unix
] ip_acct ip_output ipsec_tncfg snmp
] wittsend:/usr/local/lib/ipsec# ls -l /dev/ipsec
] crw-r--r-- 1 root root 36, 10 Feb 15 23:33 /dev/ipsec
] wittsend:/usr/local/lib/ipsec#

        Also, before anyone asks, in recognition of the past problems with unloading the ipsec module, I have rebooted the wittsend system several times to start from scratch and load everything clean. No go... I have NOT tried this with the hard linked ipsec module yet, but that next on my list of things to do.

        It could be that I'm following old instructions with new utilities, but I can't get this sucker to cook on the 4.x system. Compile, yes... Run... Not...

        Questions... Should the newer module interoperate with the older utilities?

        If so, what does the fact that the old utilities appeared to run and the new ones failed indicated?

        Should I be able to unload the ipsec module? I know we use to NOT be able to do this. Even if the ultimate objective is to get to hard linked subsystems for the production systems, being able to load and unload the modules does facilitate testing and updating, without rebuilding an entire system each time.

> Also, per Richard's long-standing request, atoaddr (and hence anything
> which calls it) now checks /etc/networks as well as DNS.  I've made one
> small compromise:  this is done only if gethostbyname() fails.  (Richard,
> let me know if this causes trouble for you.)

>                                                           Henry Spencer
>                                                        henry@spsystems.net
>                                                      (henry@zoo.toronto.edu)

	Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  
http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Received on Sat Aug 1 16:42:23 1998