Re: Degradation of TCP connection

On Aug 7, 3:13 am, James Cunnane <james.cunnane+ag...@xxxxxxxxx>
wrote:
On Tue, 5 Aug 2008 16:07:34 -0700 (PDT), justin.pear...@xxxxxxxxx
wrote:

Oh, and I just remembered another piece of the puzzle: The VxWorks
machine is also exchanging data with another box on the network over
UDP. We have timers in the VxWorks app that make it panic if it stops
receiving UDP packets. It appears that during each of these anomalies,
the VxWorks box continues to receive UDP packets just fine. That is,
it appears as though it stops hearing from the TCP stream, but
continues to receive UDP packets as normal.

Perhaps your ARP cache has become corrupt. I had a system which after
about 26 days of continuous connection would respond to ping but not
to telnet; it turned out that the ARP cache had become corrupted by a
nanosecond timer overflow. The mechanism of corruption is probably
not timer-related in your case but the end result seems similar. Can
you devise ARP diagnostics that can run periodically on the sending
device, both before and after the TCP fail?

Hmm... In your case you said the system would respond to ping, but
not telnet. It's hard to classify that as a problem with the ARP
cache, _if_ you tried to ping the target from the same host that you
also tried to telnet to it from. If you can ping target A from host
B, then ARP resolution between A and B is working (or at least, the
ARP entries haven't timed out yet). Ping (ICMP over IP) and telnet
(TCP over IP) both rely on ARP, so if it worked for one, it should
have worked for the other.

However, if you tried to ping target A from host B, and that worked,
but trying to telnet to target A from host C did not work, that could
be an ARP problem. (The target still had an unexpired ARP entry for
host B, but was unable to perform ARP resolution for the previously
unknown host C.)

In Justin's case, he said once his app got into its error state, he
could see the target still sending TCP segments to his Windows host
using Wireshark (but not responding to ACKs from the Windows host).
This implies the target's ARP entry for the Windows host was still
valid (otherwise it would have started sending ARP "who has" requests
instead).

-Bill

Regards

James Cunnane

.

Relevant Pages

  • Re: XPc Taget From File
    ... My goal is to load a file for reading by the target in real time. ... I've set up the program to read data over the UDP, ... > dedicated Ethernet port on your host. ... My xPC target has no hard drive and is ...
    (comp.soft-sys.matlab)
  • A problem of ENE , ping and UDP
    ... My TARGET is pc486 with a ENE ethernet interface, host with Tornado ... Now I want to send some message to my host through UDP. ...
    (comp.os.vxworks)
  • RE: mac to ip address tools
    ... Say host A on your net is trying to communicate with host B. Host A ... needs to know the MAC address for host B (or the MAC address for the ... ARP replies are no good for you - those are ... About 100 machines using the same MAC address: ...
    (Pen-Test)
  • Re: [2.4 PATCH] bugfix: ARP respond on all devices
    ... >ARP is designed to find the next hop on a LAN. ... If the host has an IP ... >to have a default gateway configured. ... >would anyone know where the packet came from since the network is not ...
    (Linux-Kernel)
  • RE: Using ARP to map a network
    ... destination IP hosts are on the same L2, and by definition, L3 network. ... host ARP table on NET X should only show entries for those machines on its ... same subnet the host had conversations with. ... Cisco's recommendation (from a security point of view) is to disable proxy ...
    (Pen-Test)