The Networking Saga Continues...

The Networking Saga Continues...

Post by Bruc » Wed, 31 Dec 1997 04:00:00



All,

Ok, its not RedHat 5.0, PPP or DIALD thats causing the
crabs but IPAUTOFW.  I use IP_AUTOFW to allow my Win95
LAN users (ie. my wife, Theresa ;) to be able to communicate
to the outside world using ICQ and SpeakFreely.

[No, I am not going to try to force her onto Linux as
her sole system,  thank you.]

It seems (to me) that the ephemeral ports being allocated
by Linux are initially less than the start of the ip forward
block, but after some time, the port numbers ratchet up to
this range.  It seems that when this happens, the connect
library call times-out with no client socket.  I have not
tested this by writing a client application (which I will
do - wheres Stevens?) but by disabling the IP_AUTOFW,
telnet's and TCP's start working again.  Also using strace
allows me to confirm that the ephemeral port number is
indeed in the IP_AUTOFW block.

Does anyone know definitively if this is the case?  Can it
be remedied by NOT hacking at the kernel?

Bruce McDonald.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQCNAzRkEEYAAAEEALDHLCpZ0iXz3fmlQNncUvhR1LtpBfhq7yNvVunV/2LlZnPH
2xu8E459JSwXNvruKPGbPS7QAqP6WXaYL0kLSzAKRnaJlzs53n4IRHfkc7ycKHcb
EUQxdZ2EyGLt80voGUO8uNH/gpBJkHhHU2g4h+URxfRlQ4n5QvzDGlDoSrYhAAUR
tC1CcnVjZSBKLiBNY0RvbmFsZCA8YnJ1Y2VtY2RAYmVsbGF0bGFudGljLm5ldD6J
AJUDBRA0ZkGo/MMaUOhKtiEBAetEA/9+wZR3S+3STLbOL2A6IdmF6q00ilj49tzK
Ge9xfsMthUyIWF+BgZf5ZYzyXIH2eQhRFj0TlGTpQd+37sTvh2UGQKAwpG6IWXRw
onQvG507FJ6RcYLCou/L6odaUHlR449chu/C8WmUvuPZa6VZNZgI7N79p4dCgdN6
yIZRdBpZBLQoQnJ1Y2UgSi4gTWNEb25hbGQgPGJydWNlbWNkQGhvdG1haWwuY29t
PokAlQMFEDRkEEb8wxpQ6Eq2IQEBCWMD+wbJ8LQcoJAcFDQEQYjsuLUnXrPU3Fev
J72JzGhNdYK4o8VdQ+L3CWDR8FxgY7u/3Fm+rQWcQm2xnrc/Nw/CfHqJ2bckZmNX
8lY+nA2BPyQNTeHR0yDXoQN7qBMer9svm2Gva3s0QI4HWxrGSLj3uqPvXg583k3/
Be45CPEmVVxy
=xkor
-----END PGP PUBLIC KEY BLOCK-----

 
 
 

The Networking Saga Continues...

Post by Bruc » Wed, 31 Dec 1997 04:00:00



> All,

> Ok, its not RedHat 5.0, PPP or DIALD thats causing the
> crabs but IPAUTOFW.  I use IP_AUTOFW to allow my Win95
> LAN users (ie. my wife, Theresa ;) to be able to communicate
> to the outside world using ICQ and SpeakFreely.

> [No, I am not going to try to force her onto Linux as
> her sole system,  thank you.]

> It seems (to me) that the ephemeral ports being allocated
> by Linux are initially less than the start of the ip forward
> block, but after some time, the port numbers ratchet up to
> this range.  It seems that when this happens, the connect
> library call times-out with no client socket.  I have not
> tested this by writing a client application (which I will
> do - wheres Stevens?) but by disabling the IP_AUTOFW,
> telnet's and TCP's start working again.  Also using strace
> allows me to confirm that the ephemeral port number is
> indeed in the IP_AUTOFW block.

Ok, its confirmed.  I wrote a little sock client/server program
that connects to itself and prints the ephemeral port number.
With the ipautofw enabled, as in:

 /sbin/ipautofw -A -r udp 2074 2075 -c udp 2075

the TCP ephemeral port numbers are returned fine as long as they
are below 2000.  As soon as the portnumber rises above 2000 - the
client hangs on the connect and the server on accept.  If I turn
off the ipautofw, like such:

 /sbin/ipautofw -F

then the little program works fine, allocating ports like mad.

Quote:> Does anyone know definitively if this is the case?  Can it
> be remedied by NOT hacking at the kernel?

Well, the next step is to determine if the fault is in the
application ipautofw or the way in which the kernel assigns
sockets.  Wish me luck...

Quote:> Bruce McDonald.

--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQCNAzRkEEYAAAEEALDHLCpZ0iXz3fmlQNncUvhR1LtpBfhq7yNvVunV/2LlZnPH
2xu8E459JSwXNvruKPGbPS7QAqP6WXaYL0kLSzAKRnaJlzs53n4IRHfkc7ycKHcb
EUQxdZ2EyGLt80voGUO8uNH/gpBJkHhHU2g4h+URxfRlQ4n5QvzDGlDoSrYhAAUR
tC1CcnVjZSBKLiBNY0RvbmFsZCA8YnJ1Y2VtY2RAYmVsbGF0bGFudGljLm5ldD6J
AJUDBRA0ZkGo/MMaUOhKtiEBAetEA/9+wZR3S+3STLbOL2A6IdmF6q00ilj49tzK
Ge9xfsMthUyIWF+BgZf5ZYzyXIH2eQhRFj0TlGTpQd+37sTvh2UGQKAwpG6IWXRw
onQvG507FJ6RcYLCou/L6odaUHlR449chu/C8WmUvuPZa6VZNZgI7N79p4dCgdN6
yIZRdBpZBLQoQnJ1Y2UgSi4gTWNEb25hbGQgPGJydWNlbWNkQGhvdG1haWwuY29t
PokAlQMFEDRkEEb8wxpQ6Eq2IQEBCWMD+wbJ8LQcoJAcFDQEQYjsuLUnXrPU3Fev
J72JzGhNdYK4o8VdQ+L3CWDR8FxgY7u/3Fm+rQWcQm2xnrc/Nw/CfHqJ2bckZmNX
8lY+nA2BPyQNTeHR0yDXoQN7qBMer9svm2Gva3s0QI4HWxrGSLj3uqPvXg583k3/
Be45CPEmVVxy
=xkor
-----END PGP PUBLIC KEY BLOCK-----

 
 
 

1. Installing xfce: the saga continues (or I'm too stupid for Linux)

<vent>
Installing anything in Linux is ***so hard*** !!!  There's not a
chance in hell that Linux will ever compete with Windows.  Installing
xfce has been eating up all my free time for the past week or so, and
I've gotten nowhere.  Hours and hours and hours, and that's just one
program...  At this rate it will be weeks before I have a working
system...  Now I can see why far smarter people than me avoid Linux
like the plague.  Even with my less-than-stellar hourly wage, the time
wasted getting Linux to work far outweighs the alleged monetary
savings of free software.  Very demoralizing.
</vent>

In the xfce build directory, when I run

    # ./configure --prefix=/usr/local --datadir=\/usr/local/share --sysconfdir=/etc/X11

as suggested by the installation instructions, it ends with the error:

  checking for glib-config... no
  checking for GLIB - version >= 1.2.6... no
  *** The glib-config script installed by GLIB could not be found
  *** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
  *** your path, or set the GLIB_CONFIG environment variable to the
  *** full path to glib-config.
  configure: error: Cannot find GLIB: Is glib-config in path?

Indeed, I have no glib-config anywhere (though I do have glib-1.2.7
installed).

So I tried to reinstall glib-1.2.7, but I get a huge mess of errors.
First, ./configure for glib-1.2.7 gives:

  *** Warning: the command libtool uses to detect shared libraries,
  *** /usr/bin/file, produces output that libtool cannot recognize.
  *** The result is that libtool may fail to recognize shared libraries
  *** as such.  This will affect the creation of libtool libraries that
  *** depend on shared libraries, but programs linked with such libtool
  *** libraries will work regardless of this problem.  Nevertheless, you
  *** may want to report the problem to your system manager and/or to

OK, so I don't have libtool, so now I try to install libtool.  I find
libtool, download it, but when I try to install it (using dpkg) I get
exactly the same error as above:

  *** Warning: the command libtool uses to detect shared libraries,
  *** /usr/bin/file, produces output that libtool cannot recognize.
  *** <etc>

This makes no sense!  I'm *installing* libtool.  How can libtool be
used to install libtool?  Is dpkg *that* stupid?

What is one supposed to do???

2. Newbie nedds help w/ xDSL (BellSouth)

3. The PPP Saga Continues

4. Tcsh vs. Csh -- Advantages List

5. PS/2 mouse: Day 2, the Saga continues ... please help!

6. Can't POP3 as root

7. HA... the saga continues (found a binary)

8. QIC-117 standard: where?

9. RH6.0 installs, but won't boot - saga continues

10. The SAR saga continues

11. The Mosaic saga continues ....

12. RH 7.2 kernel recompile problems - the saga continues...

13. Linux Password Saga Continues