debugging routing problem

Something has gone wrong with my home network routing and I'm looking
for some guidance on how to debug this.

The setup is that I have a linux box (machine A) as the firewall/router
connected to the DSL line. This machine runs iptables and does
masquerading of the computers on my home network.

I just added a wireless router/hub onto the internal network. After
doing this, the internal machines (wired or wireless) cannot access the
external network. If I run tcpdump on machine A, I can see the
internal machines sending out requests, but no replies coming back.
The internal machines can all see machine A.

machine A can ping machine B and the wireless router, but on a
broadcast ping, only the wireless router shows up.
machine B can ping machine A but not the wireless router.
machine C is off, and I'm at work, so I can't tell if I can go from B
to C.
machine A can see the internet, but the internal machines can't.

I'll definitely take the wireless router offline when I get home and
see what happens, but in the meantime, can someone suggest how I can
best follow the packets and see where they are going astray? My
knowledge of tcpdump has only taken me this far.


Thanks.
Gene

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


gene wrote:
> Something has gone wrong with my home network routing and I'm looking
> for some guidance on how to debug this.
>
> The setup is that I have a linux box (machine A) as the firewall/router
> connected to the DSL line. This machine runs iptables and does
> masquerading of the computers on my home network.
>
> I just added a wireless router/hub onto the internal network. After
> doing this, the internal machines (wired or wireless) cannot access the
> external network. If I run tcpdump on machine A, I can see the
> internal machines sending out requests, but no replies coming back.
> The internal machines can all see machine A.
[snip]

I'd suspect that your wireless router has somehow munged the routing
tables or network addresses on your LAN-connected machines, but it's
hard to tell with the sketchy description you've given.

So, how about telling us
1) how each machine's TCP/IP stack is configured (static IP vs DHCP,
routing table entries, etc)
2) what IP addresses, netmasks each machine uses
3) the routing table entries on each machine
4) the actual results of ping and traceroute on each machine
5) the firewall rules you have installed on each machine

That's enough for a start.

- --
Lew Pitcher

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFEmtWTagVFX4UWr64RAvVjAJ9Q5TGmLvFLsDa0q7lnt/JuoBh4DgCg1Tc+
1gDQC6o4Ajcji49CS4MAfbs=
=PC/u
-----END PGP SIGNATURE-----

On 21 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<1150918805.178471.68580@r2g2000cwb.googlegroups.c om>, gene wrote:

>I just added a wireless router/hub onto the internal network. After
>doing this, the internal machines (wired or wireless) cannot access the
>external network. If I run tcpdump on machine A, I can see the
>internal machines sending out requests, but no replies coming back.
>The internal machines can all see machine A.

The description isn't very clear. Things to check - the routing tables
and error messages when trying to connect. Routing tables means that
each host has to know how to reach all others - including the fact that
they may need to direct the packets to another intermediate host (router
or bridge) when the peer is not _directly_attached_ to the NIC (direct
meaning a hub, switch, or cross-over cable) No replies coming back could
mean that the remote has no idea how to route the packets back to the
original source. You say the internal machines sending out are requests
but are these ARP packets, DNS queries, or SYN packets trying to start
the connection. What specific error message do the clients report?

Old guy