[CCP14 Home: (Frames | No Frames)]
CCP14 Mirrors: [UK] | [CA] | [US] | [AU]

(This Webpage Page in No Frames Mode)

Collaborative Computational Project Number 14

for Single Crystal and Powder Diffraction

CCP14

SGI IRIX and Internet Applications including Proftpd, Secure Shell and Apache 1.3.x Web Server - getting lots of 255.255.255.255 in the server logs and related program failures due to not logging the correct IP address

The CCP14 Homepage is at http://www.ccp14.ac.uk

[Back to CCP14 Web/Config Main Page] [Back to Compiling Apache 1.3.x Page]

Please read all the threads below as a variety of opinions and options are described

Summary: Is a nuance in the gcc 2.8.x compiler and IRIX. A few options exist.

"From: l.cranswick@dl.ac.uk (Lachlan Cranswick)
Newsgroups: comp.infosystems.www.servers.unix
Subject: Re: 255.255.255.255 in the server log
Date: Wed, 26 May 1999 16:50:11 LOCAL
Organization: Daresbury Laboratory, UK
Lines: 44
Xref: daresbury comp.infosystems.www.servers.unix:64198



>I am trying to run apache server (v 1.3.6) on SGI (IRIX 6.5). If I
>set the "HostnameLookups" to "On" in the config file, the access log
>can display client hostname properly. But if I turn it "Off", the log
>always display 255.255.255.255 instead of the client IP address.
>Anyone can help me fix this problem.
>Thanks 
>david

Possible nuance of gcc being used to compiled up Apache?
I used to get this problem and think I got a response from
the newsgroup on how to fix it.

One fix was using the standard SGI cc compiler.   Another was
to use an older version of the gcc compiler.

(I did not try going back to gcc 2.7.2 as I made the
decision to rely on the SGI IRIX cc compiler which was
doing the job very well)

---

Another suggestion is to patch up your system to the latest IRIX 6.5.4 - make 
sure you have the NSD (NDS hostname lookup) bug patch as well.

Lachlan.

====================
Lachlan M. D. Cranswick

Collaborative Computational Project No 14 (CCP14)
    for Single Crystal and Powder Diffraction
Daresbury Laboratory, Warrington, WA4 4AD U.K
Tel: +44-1925-603703  Fax: +44-1925-603124
E-mail: l.cranswick@dl.ac.uk  Ext: 3703  Room C14
NEW CCP14 Web Domain (Under heavy construction):
                           http://www.ccp14.ac.uk


From: Vic Pulver [vpulver@my-deja.com]
Newsgroups: comp.infosystems.www.servers.unix,comp.sys.sgi.admin
Subject: Re: REMOTE_ADDR ENV var giving 255.255.255.255
Date: Tue, 21 Sep 1999 06:14:49 GMT
Organization: Deja.com - Share what you know. Learn what you don't.
Xref: daresbury comp.infosystems.www.servers.unix:70433 comp.sys.sgi.admin:85166


There's an incompatability between gcc 2.8.1 and irix libraries,
particularly those which convert internet addresses. It affects apache,
ssh, and other programs (search sgi 255.255.255.255 on deja.com).

You can either compile with cc, or download an earlier version of gcc.
I don't remember which gcc we are using to compile apache, but it is
the one which supports -o32; the newer ones (which have the problem
with the libraries) support -n32 but not -o32.

For more info, see
http://toolbox.sgi.com/TasteOfDT/public/freeware/1999Aug/Installable/gcc-2.8.1-sgipl2.html :

Gcc does not correctly pass/return structures which are smaller than 16
bytes and which are not 8 bytes. The problem is very involved and
difficult to fix. It affects a number of other targets also, but irix6
is affected the most, because it is a 64 bit target, and 4 byte
structures are common. The exact problem is that structures are being
padded at the wrong end, e.g. a 4 byte structure is loaded into the
lower 4 bytes of the register when it should be loaded into the upper 4
bytes of the register.

Gcc is consistent with itself, but not consistent with the SGI C
compiler [and the SGI supplied runtime libraries], so the only failures
that can happen are when there are library functions that take/return
such structures. There are very few such library functions. I can only
recall seeing a few of them: inet_ntoa, inet_aton, inet_lnaof,
inet_netof, and semctl.

In article [37E28002.1CD1E7CA@ldr.com],
  Richard Robinson [richardr@ldr.com] wrote:
> We have one machine (an SGI box, IRIX 6.x, I believe) on our network
> that is running Apache 1.3.6.
>
> For some reason, the REMOTE_ADDR variable is always returning
> 255.255.255.255, instead of the real remote address of user/browser
> connecting.
>

> --
> Richard Robinson
> Web Administrator
> Litho Development & Research
> richardr@ldr.com
> 503-255-5800 x172
>
>

--
Internet Developer, Los Angeles Times
http://www.latimes.com
http://www.calendarlive.com
victor.pulver@latimes.com

From: dfevans@bcr4.uwaterloo.ca (David Evans)
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: 22 Apr 2000 01:11:34 GMT
Organization: University of Waterloo
Lines: 22

In article [3900F4D3.E60531AF@saturn.med.nyu.edu],
J Hart  ["You can't email here"@saturn.med.nyu.edu] wrote:
>
>and if I get a connection from anywhere other than the local host, the
>lines I get all start with
>255.255.255.255 -- [ ...
>

  This is the classic gcc "structure-in-a-register" bug.  It bit me
last fall and I asked here, generating a flurry of responses.  The
specific symptom is buggering of the input to inet_ntoa().

  If you want the logging to work you could either write your own
version of inet_ntoa(), build it with gcc, and ensure that it's
sucked up at link time.  Or you could just use your binary made on the
machine with MIPSPro.

-- 
David Evans          (NeXTMail/MIME OK)             dfevans@bbcr.uwaterloo.ca
PhD Student, Computer/Synth Junkie         http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer

From: Tom Mitchell [mitchNOSPAM@NOSPAMcsd.sgi.com]
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: Mon, 24 Apr 2000 10:44:38 -0700
Organization: Silicon Graphics Computer Systems
Lines: 33


On 22 Apr 2000, David Evans wrote:
> >
> >and if I get a connection from anywhere other than the local host, the
> >lines I get all start with
> >255.255.255.255 -- [ ...
> >
> 
>   This is the classic gcc "structure-in-a-register" bug.  It bit me
> last fall and I asked here, generating a flurry of responses.  The
> specific symptom is buggering of the input to inet_ntoa().

Could be.  Look also at varargs (variable argument list).

Simply adding an
        #include <varargs.h>
can clean up problems with some programs.

Too many subroutines were written with 'subtle' expectations
in the procedure calling routines. Even the classic printf()
calls can get in trouble. As optimizations increase there is
more trust that the author used the language correctly (thus
reducing optimization can sometimes help (hide the problem)).

See also stdarg(5)

>   If you want the logging to work you could either write your own
> version of inet_ntoa(), build it with gcc, and ensure that it's
> sucked up at link time.  Or you could just use your binary made on the
> machine with MIPSPro.
> 
> 

From: Lauri Jesmin 
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: 6 May 2000 14:23:56 GMT
Lines: 52

David Evans [dfevans@bcr4.uwaterloo.ca] wrote:
>   This is the classic gcc "structure-in-a-register" bug.  It bit me
> last fall and I asked here, generating a flurry of responses.  The
> specific symptom is buggering of the input to inet_ntoa().

>   If you want the logging to work you could either write your own
> version of inet_ntoa(), build it with gcc, and ensure that it's
> sucked up at link time.  Or you could just use your binary made on the
> machine with MIPSPro.
I wrote inet_ntoa and inet_aton functions by myself and linked them
into programs where needed. It works form me.. postfix
(mail server) now works :) 
This is what is looks like: 

#include <stdio.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/socket.h>
#include <varargs.h>
char *inet_ntoa(struct in_addr kaka) {
        char *vastus;
        struct hostent *he;
        unsigned int u;

        he=gethostbyaddr(&kaka.s_addr,sizeof(struct in_addr),AF_INET);
        if (!he) return NULL;
        return strdup(he->h_name);
}

int inet_aton(const char *nimi , struct in_addr *kaka) {
                struct hostent *he;
                struct in_addr *kamm;

                he=gethostbyname(nimi);
                if (!he) return 0;
                kamm=he->h_addr;
                kaka->s_addr=kamm->s_addr;
                return 1;
}

> -- 
> David Evans          (NeXTMail/MIME OK)             dfevans@bbcr.uwaterloo.ca
> PhD Student, Computer/Synth Junkie         http://bbcr.uwaterloo.ca/~dfevans/
> University of Waterloo         "Default is the value selected by the composer
> Ontario, Canada           overridden by your command." - Roland TR-707 Manual

-- 
Lauri Jesmin (doom@my-host-name-is-longer-than-yours.tkwcy.ee)
Et oma ridu sisseimbuva kahtlase elemendi eest hoida,tuleb iga nädal

Date: Mon, 07 Aug 2000 11:58:45 +0200
From: Alexis Cousein [al@brussels.sgi.com]
Newsgroups: comp.sys.sgi.admin
Subject: Re: gcc 2.95.2 on Irix 6.5.8

jthornton@my-deja.com wrote:
>
> Even if you are able to compile SSH with gcc 2.95.2, you will soon hit
> another snag.
>
> The gcc libraries that convert internet addresses are broken. This
> effects Apache and SSH.

That is incorrect. The problem is that these installations rely on the
standard libc() routines, and there's a bug in the N32 implementation of
the MIPS ABI by gcc -- so the bug is that there aren't "gcc libraries"
(as libraries compiled with gcc are interoperable with gcc binaries in
this respect -- they both implement the same ABI conventions, albeit not
the official MIPS N32 ABI conventions).

There are several workarounds -- do an archive search on i n e t _ n t o
a to find some pointers.

[BTW, the reason that gcc 2.7.2 doesn't encounter this problem is simply
that it uses an different, older O32 ABI]

--
[standard disclaimer: these are my personal views, not SGI's]
Alexis Cousein                  al@brussels.sgi.com
Systems Engineer                SGI Belgium/Luxemburg

From: http://w3.physics.uiuc.edu/~menscher/vfemmes.html

This document outlines steps to compile a recent version of Sendmail for IRIX 6.2 without resorting to SGI's native cc compiler.

  • if you don't already have it, download the latest version of gcc from freeware.sgi.com
  • download Sendmail from www.sendmail.org
  • in devtools/OS/IRIX.6.x modify the compiler to be /usr/freeware/bin/gcc
  • download the latest version of inn (available from ftp.tin.org:/pub/news/servers/inn-snapshot)
  • copy the files inet_aton.c and inet_ntoa.c from the lib directory of inn into the libmilter and sendmail directories of sendmail
  • modify those files to remove the reference to #include "config.h"
  • modify the Makefile.m4 in those directories to add these two new files to the bldSOURCES list
  • go to the main sendmail directory and type ./Build
  • while it is compiling, go to www.qmail.org and start a download of qmail (this is to scare sendmail into working)
  • assuming you've made it this far, you can create your sendmail.cf file and do a ./Build install

Why was all of this necessary?

Ordinarily you would like to just build sendmail with the native cc compiler. But if you don't have licenses for it, you will be forced to use gcc. Unfortunately, gcc and Irix 6.2 are both broken, and as a result the functions inet_aton and inet_ntoa don't work correctly. As a result, when sendmail attempts to resolve an IP address, it always gets the value 255.255.255.255. This makes sendmail think that every machine on the net is the same one -- the one with IP 255.255.255.255. Of course, this means that it can't distinguish between itself and others, and therefore relays for everyone. Given that open relays are a spammer's delight, this is not acceptable. Fortunately, inn comes with a public domain replacement for these broken functions, which we can use to our advantage.

Damian Menscher menscher@uiuc.edu July 2000


[CCP14 Home: (Frames | No Frames)]
CCP14 Mirrors: [UK] | [CA] | [US] | [AU]

(This Webpage Page in No Frames Mode)

If you have any queries or comments, please feel free to contact the CCP14