Re: Simple network config problem?

From: Mitch Zollinger (ztanuki_at_netscape.net)
Date: 09/03/03 

Date: Wed, 03 Sep 2003 11:25:25 -0700

Hi,

Thanks for all the input.

>The linux setup worked with the same hardware or did you change >anything?
>Did you change any network cabling?

Yes, the linux setup worked with the exact same cabling & hardware.
Nothing has changed.

>Also check with tcpdump if you can see any packets coming in or going
>out.
>Something like
>
> tcpdump -nes 1500 -i dc0

If I do this from the server (I'm at work & can't access the internal
client right now), I do see packets:

$ tcpdump -nes 1500 -i dc0 &
$ ping 192.168.1.7
06:39:47.028301 0:a0:cc:61:d4:b8 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.1.7 tell 192.168.1.100
06:39:48.030206 0:a0:cc:61:d4:b8 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.1.7 tell 192.168.1.100
06:39:49.040159 0:a0:cc:61:d4:b8 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
192.168.1.7 tell 192.168.1.100
--- 192.168.1.7 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

I've done as you both suggested and tried to isolate the problem. I've
completely turned off the packet filter in rc.conf and removed the
bridgename.bridge0 file. Now I just have two ethernet interfaces.

If I do a 'netstat -rnf inet' after rebooting the machine:
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 12.234.88.1 UGS 0 2 - ne3
12.234.88/23 link#2 UC 0 0 - ne3
12.234.88.1 0:a:8b:6d:90:54 UHL 1 0 - ne3
12.234.89.65 127.0.0.1 UGHS 0 0 33224 lo0
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 0 33224 lo0
192.168.1/24 link#1 UC 0 0 - dc0
224/4 127.0.0.1 URS 0 0 33224 lo0

There is no route information for the internal LAN NIC (192.168.1.100)
even though it's reported by ifconfig -a:

dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         address: 00:a0:cc:61:d4:b8
         media: Ethernet autoselect (100baseTX)
         status: active
         inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
         inet6 fe80::2a0:ccff:fe61:d4b8%dc0 prefixlen 64 scopeid 0x1
ne3: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         address: 00:e0:29:38:55:27
         media: Ethernet autoselect (10baseT)
         inet6 fe80::2e0:29ff:fe38:5527%ne3 prefixlen 64 scopeid 0x2
         inet 12.234.89.65 netmask 0xfffffe00 broadcast 255.255.255.255

Now, if I ping an internal host (192.168.1.7), the ping fails, but the
routing table changes to:

Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 12.234.88.1 UGS 0 2 - ne3
12.234.88/23 link#2 UC 0 0 - ne3
12.234.88.1 0:a:8b:6d:90:54 UHL 1 0 - ne3
12.234.89.65 127.0.0.1 UGHS 0 0 33224 lo0
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 2 0 33224 lo0
192.168.1/24 link#1 UC 0 0 - dc0
192.168.1.7 link#1 UHL 0 1 - dc0
224/4 127.0.0.1 URS 0 0 33224 lo0

(Note the entry for 192.168.1.7) I'm interpreting this to mean that
there is no layer2 problem, but there is a layer3 problem with
sending/receiving the ICMP packets.

I've also tried deleting the 192.168.1/24 route and adding the route
with 192.168.1.100 as the gateway, but when I ping I get an arpresolv error:

$ route delete -net 192.168.1
$ route add -net 192.168.1 192.168.1.100
$ ping 192.168.1.7
arpresolv: can't allocate llinfo (in blue reverse text)

And if I ping 192.168.1.100 (the OpenBSD server) from the linux client,
the server throws the following error on the console:

arplookup: unable to enter address for 192.168.1.7 (in blue reverse
text: one message for every ping packet)

I also checked out my /etc/hosts file:

::1 localhost.attbi.com localhost
127.0.0.1 localhost.attbi.com localhost
::1 tanuki.attbi.com tanuki
127.0.0.1 tanuki.attbi.com tanuki
127.0.0.1 outside.attbi.com outside
192.168.1.100 inside.attbi.com inside

I tried commenting out the last line, but that didn't change things.

Any additional ideas?

Thanks again,
zolli

jpd wrote:
> In article <1062535426.233919@sj-nntpcache-5>, Mitch Zollinger wrote:
>
>>I just replaced Linux with OpenBSD 3.3 on my home NAT server / firewall.
>> I'm having some difficulty getting a basic 2 NIC setup to work
>>properly.
>
>
> The linux setup worked with the same hardware or did you change anything?
> Did you change any network cabling?
>
> [snip]
>
>>If I try to ping the OpenBSD firewall (192.168.1.100) from an internal
>>client, I get no return packets; if I try to ping an internal client
>>from the BSD box, I also receive no return packets.
>
>
> Then it might be a firewall problem, that is, turn off all firewalling
> (and NAT and whatnot) rules and see if you can make dc0 work with the
> internal network first. Oh, and pull the ne3 plug for the time being.
>
> Once you have a connection there, you can continue with setting up NAT.
>
> Also check with tcpdump if you can see any packets coming in or going out.
> Something like
>
> tcpdump -nes 1500 -i dc0
>
> should tell you if there's anything going on. Try on both sides.
>
>
>
>> It doesn't appear
>>to be a hardware problem, since I receive no error messages and I can
>>see the NIC & hub lights flashing appropriately.
>
>
> You still might have a hardware problem: maybe one of the network interfaces
> on either end of the cable has a broken tx or rx unit. Or maybe your cabling
> is /slightly/ wrong. Check for correct wiring _for ethernet_. Using the wrong
> pairs might get you lights but no connection. Or maybe a connection but lots
> of late colisions or it just won't sync right on 100BaseTX. Just check. :-)
>
>

Relevant Pages

  • Re: Problem with my NIC
    ... Alex Harsch wrote: ... sniffer while I try to ping another machine. ... packets, but there are some outgoing ARP packets asking "who has ... 192.168.10.10" (this tells me the packets never get to the hardware) ...
    (comp.os.linux.setup)
  • [PATCH NET-NEXT 03/10] net: new user space API for time stamping of incoming and outgoing packet
    ... User space can request hardware and/or software time stamping. ... approximate send time stamp by receiving the looped ... +stamps can be generated and returned for arbitrary packets and much ...
    (Linux-Kernel)
  • [PATCH NET-NEXT 03/10] net: new user space API for time stamping of incoming and outgoing packet
    ... User space can request hardware and/or software time stamping. ... approximate send time stamp by receiving the looped ... +stamps can be generated and returned for arbitrary packets and much ...
    (Linux-Kernel)
  • Netgear MA401 stopped working
    ... the host, seem to be sending packets, but never receive anything back. ... PING 192.168.112.1: 56 data bytes ... I, on the other hand, suspect a hardware problem with the card. ... pci_cfgintr: 0:2 INTA BIOS irq 11 ...
    (freebsd-net)
  • Re: Hornby Elite DCC - some comments
    ... No, you don't need to know exactly what "packets" are, but as in all ... understand what "NMRA compliant" means, ... A DCC decoder is a small computer. ... to make any hardware they wanted to make. ...
    (uk.rec.models.rail)