I've got a machine that is just driving me nuts here... it's a RedHat 7.2
machine, upgraded to a 2.4.17 kernel (no kernel patches, just standard
kernel). The machine has an ethernet interface for it's local network, and a
ppp interface (using RedHat's pppd-2.4.1 RPM) to connect it to the corporate
WAN.
The machine runs fine, and other nodes on the local network (i.e. using the
ethernet interface) can communicate with it just fine. I can also bring up
the ppp link, and communicate with everything on the corporate WAN without
trouble. I can communicate _through_ this machine from nodes on the local
network to the corporate WAN just fine. But...
What I _cannnot_ do is initiate a connection from a node on the other side
of the ppp link (the corporate side) to this machine. There are at least
three daemon processes on this system I've tried to connect to: xinetd (for
telnet), bind and exim. None of these are using tcp_wrappers. The symptoms
are that the TCP SYN packet (to open the connection) arrives at the ppp0
interface (verified by using tcpdump on the ppp0 interface), but then is not
delivered to the waiting process on its open socket.
So far, I have done the following:
- reproduced the problem with iptables statically compiled, modular
compiiled and not included at all
- strace'd the daemon process(es) to see that they are stuck on a select()
(expected), and that the select() does not return when the packet arrives
- put in iptables rules to show when the packets get ACCEPTed (and they do,
the counters increase)
- watched the packets leave from the source machine with tcpdump on the
outbound interface, and the packets arrive intact at the problem machine
with tcpdump on the ppp interface
- disabled all sysctl settings that I had previously set
- rebooted countless times to try other variations :-)
Anyone have any idea where to proceed here? I'm sure it's something stupid
I've missed, as this is a pretty basic thing to not have working properly,
but I can't seem to find it.
On Thu, Jan 03, 2002 at 09:38:50PM -0700, Kevin P. Fleming wrote:
> I've got a machine that is just driving me nuts here... it's a RedHat 7.2
> machine, upgraded to a 2.4.17 kernel (no kernel patches, just standard
> kernel). The machine has an ethernet interface for it's local network, and a
> ppp interface (using RedHat's pppd-2.4.1 RPM) to connect it to the corporate
> WAN.
Does your problem depend on kernel version?
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
> - watched the packets leave from the source machine with tcpdump on
> the outbound interface, and the packets arrive intact at the problem
> machine with tcpdump on the ppp interface
Have you dumped the complete packet on both ends, and checked that it
arrives really unchanged? (except the IP checksum and the ttl).
IIRC the option should be -x -s 1500
Perhaps some traffic shaper/firewall corrupts incomming SYN packets?
--
Manfred
I haven't tried an _older_ kernel yet, but did have the same problem on
2.4.17 and 2.4.17-rc1. I'll try something older tomorrow and see what
happens.
----- Original Message -----
From: "bert hubert" <[email protected]>
To: "Kevin P. Fleming" <[email protected]>
Cc: <[email protected]>
Sent: Friday, January 04, 2002 4:00 PM
Subject: Re: How to debug very strange packet delivery problem?
> On Thu, Jan 03, 2002 at 09:38:50PM -0700, Kevin P. Fleming wrote:
> > I've got a machine that is just driving me nuts here... it's a RedHat
7.2
> > machine, upgraded to a 2.4.17 kernel (no kernel patches, just standard
> > kernel). The machine has an ethernet interface for it's local network,
and a
> > ppp interface (using RedHat's pppd-2.4.1 RPM) to connect it to the
corporate
> > WAN.
>
> Does your problem depend on kernel version?
>
> Regards,
>
> bert
>
> --
> http://www.PowerDNS.com Versatile DNS Software & Services
> http://www.tk the dot in .tk
> Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
> Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
>
>
>
Hadn't gone that far yet, no. Luckily at this time the machines are actually
located in the same office, so this shouldn't be too hard to do. Once the
problem machine is relocated to 30+ miles away, it would be a bit more
difficult :-)
----- Original Message -----
From: "Manfred Spraul" <[email protected]>
To: ""Kevin P. Fleming"" <[email protected]>
Cc: <[email protected]>
Sent: Friday, January 04, 2002 4:17 PM
Subject: Re: How to debug very strange packet delivery problem?
> > - watched the packets leave from the source machine with tcpdump on
> > the outbound interface, and the packets arrive intact at the problem
> > machine with tcpdump on the ppp interface
>
> Have you dumped the complete packet on both ends, and checked that it
> arrives really unchanged? (except the IP checksum and the ttl).
> IIRC the option should be -x -s 1500
>
> Perhaps some traffic shaper/firewall corrupts incomming SYN packets?
>
> --
> Manfred
>
>
>
>
"Kevin P. Fleming" wrote:
> The machine runs fine, and other nodes on the local network (i.e. using the
> ethernet interface) can communicate with it just fine. I can also bring up
> the ppp link, and communicate with everything on the corporate WAN without
> trouble. I can communicate _through_ this machine from nodes on the local
> network to the corporate WAN just fine. But...
>
> What I _cannnot_ do is initiate a connection from a node on the other side
> of the ppp link (the corporate side) to this machine. There are at least
> three daemon processes on this system I've tried to connect to: xinetd (for
> telnet), bind and exim. None of these are using tcp_wrappers. The symptoms
> are that the TCP SYN packet (to open the connection) arrives at the ppp0
> interface (verified by using tcpdump on the ppp0 interface), but then is not
> delivered to the waiting process on its open socket.
Hi Kevin,
You seem to know what you're doing there, but it would still help if you
could provide some details of your routing configuration and servers,
e.g. output of ifconfig, route -n, and netstat -anot, iptables -L
(provided that the company security policy allows you to share this
info, of course :-). Are you doing NAT between the local net and the
corporate WAN or are you sharing a subnet? Are you sure that it's the
SYN getting lost rather than the SYN-ACK from the server? Even though
your machine is forwarding fine it might still be a routing problem of
some kind.
Cheers,
MikaL