[2486] in SIPB-AFS-requests

home help back first fref pref prev next nref lref last post

Re: can anyone get Sun patch 101790-01?

daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Sep 27 11:11:45 1996

Date: Fri, 27 Sep 1996 11:10:30 -0400
To: mhpower@MIT.EDU
Cc: rtfm-maintainers@MIT.EDU, usenet@MIT.EDU, sipb-afsreq@MIT.EDU
In-Reply-To: "[2485] in SIPB-AFS-requests"
From: John Hawkinson <jhawk@MIT.EDU>

> Evidently there's a problem using new versions of sendmail on
> SunOS 4.1.3_U1 if sendmail is compiled with IP_SRCROUTE defined (which
> it is in the standard configuration). The 8.7.6 src/READ_ME says:

Yup. This was one of my contributions to sendmail. Let us make all
those cruddy Sun operating systems crash! Sigh...

> (daemon.c now has a call to getsockopt; it didn't in sendmail 8.6.13.)

Yup.

> 101790-01 wasn't available at ftp://sunsolve.sun.com/pub/patches/. Can
> anyone obtain it from a reliable location (i.e., Sun or a server known
> to have the copy distributed by Sun)? I am aware that searching the
> web for 101790-01 can locate files purporting to contain this patch.

I have downloaded a copy from sunsolve.sun.com and placed it in
/afs/sipb/project/kernel/sunos.414/patches/101790-01.tar.Z. 101790-01 appears
to be the latest revision of 101790.

> Incidentally, the copy I found on the web includes a new version of
> tcp_usrreq.o -- this happens to be one of the object files replaced by
> the patches I mentioned relating to dealing with SYN attacks. In other
> words, if we someday need to get a new version of tcp_usrreq.o for the
> SYN-attack problem, we'll probably also need to make sure it includes
> the fix for the getsockopt problem.

Once again, I do not think it would be a good idea to apply Avi's patches
in binary form. If we truly need this, someone with SunOS source access
should apply source-form patches and rebuild the affected modules.

Of course, if we do not have source patches for 101790 this may
be more difficult.

If hard pressed, I believe I could obtain source diffs for 101790-01,
should the need arise. A better solution would be to upgrade to a
4.1.4 kernel, however, a cursory (no dev cell tokens) inspection of
/afs/dev/reference/ suggests we may not have source for 4.1.4, either
(whereas such an inspection implies we have source for 4.1.3_U1).

--jhawk

home help back first fref pref prev next nref lref last post