From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Wed 02 Jul 2003 - 19:39:24 BST
On Wed, Jul 02, 2003 at 12:48:35AM +1000, Fernando Serto wrote:
>
> ----- Original Message -----
> From: "Herbert Poetzl" <herbert_at_13thfloor.at>
> To: <vserver_at_solucorp.qc.ca>
> Sent: Tuesday, July 01, 2003 10:45 PM
> Subject: Re: [vserver] update: problem connecting FROM vserver to other box
> on the LAN
>
>
> > On Tue, Jul 01, 2003 at 06:34:15PM +1000, Fernando Serto wrote:
> > > I forgot to mention that I'm running RedHat 8 here... I have the same
> > > configuration at home, but running on a slackware 9 and it works!
> >
> > I realy doubt that, I assume you have a similar
> > configuration _without_ vserver ctx-17 running
> > at home and it works ;)
>
> what do you mean?
> my box at home:
> root_at_skywalker:~# uname -a
> Linux skywalker 2.4.20ctx-17 #4 Sat Jun 14 22:53:07 EST 2003 i686 unknown
> root_at_skywalker:~#
>
> box at work:
> [root_at_fenestra root]# uname -a
> Linux fenestra 2.4.20ctx-17 #10 Thu Jun 26 16:13:01 EST 2003 i686 i686 i386
> GNU/Linux
> [root_at_fenestra root]#
>
> skywalker is a slackware 9 and fenestra is a redhat 8. both of them with the
> ctx17 patch applied. and the vserver packages, I compiled and installed the
> same source tarball... I tried the rpms, but as I was having problems, I
> decided to remove them and use the same files... sorry for my stupidity!
what about the network configuration?
is this also equivalent or at least compareable?
> > > > eth1:cart Link encap:Ethernet HWaddr 00:90:27:75:FC:66
> > > > inet addr:192.168.10.101 Bcast:61.8.29.127
> Mask:255.255.255.0
> > ^^^^^^^^^^^^^^^^
> > looks like a badly configured network/broadcast ....
>
> how would I set this up? isn't it automatic? in my box at home, the
> broadcast is from eth0 (external), but it's still working...
look, the linux ip stack is very powerful, the
_usual_ interface utilities are from 2.0.x ...
you'll have to use iproute2 to unleash all the
features ...
In addition to that complexity, the ctx-17 network
code seems to do some things wrong (or at least in
a very strange way ...)
> > > > why the hell is it trying to connect using the external ip?
> > > > is this the problem?
> >
> > yes that is the problem ...
> >
> > you could try using chbind --ip 192.168.x.x ... and
> > you probably will succeed ...
>
> you were right...
> [root_at_fenestra root]# chbind --ip 192.168.10.111 ping 192.168.10.1
> ipv4root is now 192.168.10.111
> PING 192.168.10.1 (192.168.10.1) from 192.168.10.111 : 56(84) bytes of data.
> 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.899 ms
> 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.437 ms
>
> --- 192.168.10.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% loss, time 1007ms
> rtt min/avg/max/mdev = 0.437/0.668/0.899/0.231 ms
>
> > same problem ...
> >
> > HTH,
> I was hoping that it would help, as well... :o) but it didn't...
> can you clarify that for me?
I'll try:
if you attach a packet logger (eg tcpdump), you'll see that
for example a ping to an aliased interface, will result in
packages with 'wrong' source addresses leaving the 'right'
interface ...
as far as I know (didn't investigate yet) this is _not_ an issue
of the kernel. ping simply uses the first address of an interface
if no -I <address> is specified ...
so if the alias interface is configured correctly, you'll
still need to specify -I 192.168.10.111 for ping to do the
'right' thing ...
from within a vserver this is not required, because the
virtual server only 'sees' the aliased interface, so ping
does what you expect ...
hth,
Herbert