On Thu, 22 Jun 2000, Andreas Meyer wrote:
> On 21-Jun-00, Fred Wright wrote:
[...]
> This is what I get:
> miamitcpdump: listening on eth0
> ;unicastping from PC to 192.168.1.1
> 12:35:22.780001 arp who-has 192.168.1.1 tell 192.168.1.2 (0:e0:7d:7d:2c:38)
> 12:35:22.780006 arp reply 192.168.1.1 is-at 52:54:40:26:79:ca (0:e0:7d:7d:2c:38)
> 12:35:24.260001 arp who-has 192.168.1.1 tell 192.168.1.2 (0:e0:7d:7d:2c:38)
> 12:35:24.260006 arp reply 192.168.1.1 is-at 52:54:40:26:79:ca (0:e0:7d:7d:2c:38)
> 12:35:25.280001 arp who-has 192.168.1.1 tell 192.168.1.2 (0:e0:7d:7d:2c:38)
> 12:35:25.280006 arp reply 192.168.1.1 is-at 52:54:40:26:79:ca (0:e0:7d:7d:2c:38)
> 12:35:26.300000 arp who-has 192.168.1.1 tell 192.168.1.2 (0:e0:7d:7d:2c:38)
> 12:35:26.300005 arp reply 192.168.1.1 is-at 52:54:40:26:79:ca (0:e0:7d:7d:2c:38)
> ;broadcastping from PC to 192.168.1.255
> 12:35:54.780000 192.168.1.2 > 192.168.1.255: icmp: echo request
> 12:35:54.780005 192.168.1.1 > 192.168.1.2: icmp: echo reply
> 12:35:56.240000 192.168.1.2 > 192.168.1.255: icmp: echo request
> 12:35:56.240005 192.168.1.1 > 192.168.1.2: icmp: echo reply
> 12:35:57.260001 192.168.1.2 > 192.168.1.255: icmp: echo request
> 12:35:57.260006 192.168.1.1 > 192.168.1.2: icmp: echo reply
> 12:35:58.260001 192.168.1.2 > 192.168.1.255: icmp: echo request
> 12:35:58.280001 192.168.1.1 > 192.168.1.2: icmp: echo reply
> 12:36:08.100000 192.168.1.2.138 > 192.168.1.255.138: udp 209
>  
> > Unfortunately this looks more like a hardware problem with the NIC
> > on one of the two machines, where unicasts from PC to Amiga aren't
> > working (the other direction is unknown, although you might look to
> > see if the PC's hub LED flashes when you ping from the Amiga).
> 
> NIC? No, the PC hub-leds aren�t flashing when I ping from the Amiga.

As I mentioned in a later post than the one you're answering here, I think
what's happening is that Amiga->PC traffic isn't getting through at all.
This is more likely hardware, but could be a software problem as well.  If
you had (or could borrow) a third machine to try you could narrow it down.

> >>>> Subnet-mask 255.255.255.0
> >>>> Gateway 192.168.0.2
> >> 
> >> Is the PC really supposed to be a gateway to somewhere? If not,
> >> this is incorrect. In any case, it's unneeded for local pings.
> 
> I added both, the Amiga-ID and the PC-ID in the Gateway-entry on
> PC-side. This is what is recommended in the X-Surf maunual. "All
> computers on the network have to be added here".

Assuming you haven't misinterpreted it, that's a load of crap.  A pure LAN
setup doesn't require any gateway entries anywhere.  It's only when a
machine is used as a means to route traffic to a different network that it
needs to be seen by others as a gateway.

The inconsistent use of the term "gateway" for point-to-point links adds
to the confusion.  In MiamiDx you define the remote end of a P2P link as a
"gateway" even when it isn't, just as a way to specify the remote IP.  On
an Ethernet, the "remote IP" is a whole block of addresses as defined by
the local IP and the netmask, and no non-gateway "gateway" definition is
needed.

> > True, just be careful you're not sharing your files with every
> > cracker on the net. They like nothing better than to look for open
> > shares or shares with easily guessable passwords.
> 
> So if I ever go to the Internet with the PC and Amiga as gateway I
> disable filesharing? I have the firewall enabled in MiamiDx; not now
> as long as I�m testing the LAN.

The automatic firewall in MiamiDx will protect you fine unless you
explicitly configure holes in it for MS networking.  The manual firewall
is also potentially safe, but you need to configure it correctly.  Even
without the firewall enabled, MSN traffic wouldn't get to the PC unless
you set up IP-NAT redirection for it.  The problem is that if you ever
connect the PC to the net *directly* you should think carefully before
allowing MSN.  Unfortunately, in its typical fashion, Windoze requires a
reboot to change the setting.

Enabling the firewall in MiamiDx should have no effect on the LAN as long
as the LAN is defined as "LAN" rather than "Internet".  But I agree it's
best to leave it off to simplify things during basic testing.  I'd leave
IP-NAT and SOCKS initially disabled as well.

                                        Fred Wright

-- 

To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".


Reply via email to