pppd bug in TCP/IP 4.25?

Hello all.

I’m using QNX 4.24 with tcp/ip 4.25 to run a PPP link to another host.

[TCP client]ethernet[Router]ethernet[QNX PC]PPP[TCPServer/PPP peer]

I’ve found that if the TCP client attempts to connect before the PPP link is established (due to the server taking a while to start up), then even once the link is up, the client annot communicate with the server.

The QNX host and the server can freely ping each other, but no traffic from the router will get through (though packet sniffing confirms it is reaching the QNX PC).
Here’s the twist: if the PPP peer sends any IP traffic through the QNX PC (e.g. pings the router), then the situation all clears up, and the TCP Client can now connect to the TCPServer.

I’m using PPP in the following manner on the QNX host:

pppd passive proxyarp persist <local_ip>:<TCPServer_ip> <baudrate> <serial port>

The TCP Server is responsible for initiating the ppp connection, but is a server at the TCP layer.

Has anyone else seen this? Better yet: seen it and come up with a solution?
I can’t have the TCPServer sending packets, as it’s third-party equipment and outwith my control.


It sounds like the proxyarp is not working properly? Try these.

  1. on [TCP client], do “ping -n -c1 [QNX PC’s IP]”, is this works?

  2. on [TCP client], do “ping -n -c1 [TCPServer/PPP peer’s IP]”, is this works? If not:

    1. on [TCP client], do “arp -na”, what is it looks like?
    2. on [QNX PC], do “arp -na”, what is it looks like?


TCPClient to QNX = Ping 100% Success
TCPClient to PPP Peer = Ping 100% Failure

ARP on TCP Client just shows (correctly) the IP and MAC of the router port (as a normal temporary entry)

ARP on the QNX PC shows the IP/MAC of the router port as a normal temporary entry. It also lists the IP of the PPP Peer with the MAC of the QNX host as a permanent published entry.

Wireshark captures from the QNX - Router link show ARP is functioning correctly. I’ve even set permanent ARP entries with the correct details across all hosts with no success.

If I change the PPP link to a different subnet to the QNX-Router network,
and change the router to route PPP Peer IP to the QNX Host (i.e. it should ARP for the QNX box as a gateway, not the PPP Peer as a host), I get a TTL Expired message returned to the TCPClient ping.

It appears that the router sends the ping to the QNX box. QNX then ignores the PPP interface (which is now up and indicating the correct Subnet/IP as a local interface) and sends the packet back to the default gateway. Which then routes back, and packet tennis continues until TTL expires.

The workaround I have just now is to use traceroute to spoof a message to the PPP peer from the router.

traceroute -m 2 -n -q 1 -w 2 -s <routerIP>  <PPP Peer IP>

This sends a UDP datagram from the QNX box to the PPP Peer. The PPP Peer responds “Unreachable Port” to the Router, and this uplink packet through the QNX box seems to unblock the link and TCPClient can now ing the PPP Peer. Obviously it’s ugly as sin and relies on me guessing an unused port on the black-box PPP Peer equipment, but it’s the only solution I have at the moment.