--------
Recognising the audiences are not the same, I'm posting this to two lists -
Guinness because RHL 7 is involved (and the system not working), and devel
because it's also a development matter and I suspect there's not a lot of
people who understand this anyway. Certainly the HOWTOs and the NAG don't help.
I have two computers; dugite and possum. Their primary IP addresses are 192.168.1.1
and 192.168.1.6.
Dugite is running Red Hat Linux 6.2, kernel 2.4.1 and its requisite software.
Dugite is the server - possum's /home is nfs-mounted from dugite.
Possum has Red Hat Linux 7.0 plus updates plus kernel 2.4.2.
I have a program, user-mode-linux, which creates a slip device out of the air
(there is no real serial interface, but we can pretend there is), sl0. What is
happening is equivalent to someone calling in and establishing a SLIP connexion.
The program runs a script to configure the host interface; the host script generates
these commands:
/sbin/ifconfig sl0 192.168.1.1 pointopoint 192.168.1.253 up
/sbin/arp -s 192.168.1.253 -D eth0 -i eth0 pub
When the program has started up and configured itself and run these commands,
then I can reach 192.168.1.253 from possum with ping, telnet, ssh and so on.
This is what I expect.
Here is the arp table on possum before it discovers the guest.
[root@possum /root]# arp
Address HWtype HWaddress Flags Mask Iface
emu.os2.ami.com.au ether 00:E0:29:07:13:95 C eth0
dugite.os2.ami.com.au ether 00:00:21:01:1D:12 C eth0
Then I ping (the times are quite respectable, aren't they?)
[root@possum /root]# ping -c3 192.168.1.253
PING 192.168.1.253 (192.168.1.253) from 192.168.1.6 : 56(84) bytes of data.
64 bytes from 192.168.1.253: icmp_seq=0 ttl=254 time=578.403 msec
64 bytes from 192.168.1.253: icmp_seq=1 ttl=254 time=627 usec
64 bytes from 192.168.1.253: icmp_seq=2 ttl=254 time=775 usec
--- 192.168.1.253 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.627/193.268/578.403/272.331 ms
Then we check the tables again; there's a new entry.
[root@dugite /root]# arp
Address HWtype HWaddress Flags Mask Iface
possum.os2.ami.com.au ether 00:E0:29:07:3B:1B C eth0
emu.os2.ami.com.au ether 00:E0:29:07:13:95 C eth0
bilby.os2.ami.com.au (incomplete) eth0
[root@dugite /root]# ping -c2 192.168.1.253
PING 192.168.1.253 (192.168.1.253) from 192.168.1.1 : 56(84) bytes of data.
--- 192.168.1.253 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
[root@dugite /root]# arp
Address HWtype HWaddress Flags Mask Iface
possum.os2.ami.com.au ether 00:E0:29:07:3B:1B C eth0
emu.os2.ami.com.au ether 00:E0:29:07:13:95 C eth0
bilby.os2.ami.com.au (incomplete) eth0
[root@dugite /root]#
[root@possum /root]# arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.253 ether 00:00:21:01:1D:12 C eth0
emu.os2.ami.com.au ether 00:E0:29:07:13:95 C eth0
dugite.os2.ami.com.au ether 00:00:21:01:1D:12 C eth0
[root@possum /root]#
If I do precisely the same thing on possum (and it's easy to do precisely the
same thing because all relevant files are shared), then I am unable to reach the
IP address 192.168.1.253 from dugite.
Now, trying to resolve this I've engaged in much head scratching and
1) Installed the same version of arp on possum as dugite has - no difference
2) Built a 2.4.1 kernel for possum - no difference.
I don't think it's a matter of routing - possum and dugite chat very happily to
each other and to two other computers also on the LAN and that I've not
mentioned.
Nor do I use subnetting of my class C address range.
I can only surmise the packets are going out on the wire from dugite and not being
recognised by possum.
I have gone to Dugite's keyboard and watched the lights on my hub, but I really
can't tell just what's happening - I cant tell any certain diference between
pinging emu (another machine on the same LAN) or possum.
I've no doubt that I can come up with a working configuration involving
subnetting or a different address range, but that's not acceptable to the
target environment.
Any ideas anyone?
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
