Re: Degradation of TCP connection

Bill,

I continue to appreciate your knowledgeable assistance on this
problem! You have been so helpful. To address the points you brought
up:

I'm pretty sure the network driver you have was
not written by Wind River, though I don't know if it was done by
Curtiss-Wright or Marvell. If I had to bet, I'd say that at least some
of the code was provided by Marvell.

You're absolutely right. To quote one of our contacts at Curtiss-
Wright,

"Each of our boards will have an ethernet driver specific
for the chip and the board. For the 124 board, the driver would have
been based on code from Marvell (the manufacturer of the Discovery III
bridge), and as updated by Curtiss Wright Controls Embedded Computing/
Dy
4 Systems."

So that answers that.

- When your application and LabView stop communicating, can you still
ping the target from the Windows XP machine? If yes, the ethernet
driver and the IP layer of the stack are still working, at least to
some extent, and it's something at the TCP layer that's gone wrong. If
no, then it could be the driver, or a serious problem in the stack.

We have not tried this yet, but it's on our (now much longer) list of
things to try once the problem comes up again.

- You say that it looks like the VxWorks target stops receiving
traffic from LabView. How did you determine this? I usually check for
receive operation by adding the target shell and the INCLUDE_IFCONFIG
component.

We had Wireshark running on a separate machine that was watching all
the traffic on the network. Each time this anomaly happens, it starts
when the VxWorks box stops ACKing packets sent from the Windows box.
To be precise, the ACK number on the "VxWorks --> Windows" packets
stop increasing. Soon, the Windows box, noticing that the VxWorks box
is reporting the same ACK number, begins retransmitting packets.
However, the VxWorks box still does not increment its ACK number. At
the same time, the VxWorks box begins retransmitting data to the
Windows box, as though it didn't hear the incrementing ACKs that the
Windows box was sending to VxWorks.

In short, we deduced it from a bunch of Wireshark data. Do you think
this is a valid conclusion?

We feel much more prepared for the next anomaly, though. We have
enabled ifconfig() in our kernel and are running on the bench with our
fingers crossed.

Per your several suggestions, we'll try
1. Pinging the VxWorks box from another machine on the network
2. Pinging xxx.xxx.xxx.255 from the VxWorks box and seeing what
happens in Wireshark
3. Calling ifconfig() to see what the "Rx packets" and "Tx packets"
counters are doing.

- The board should have at least two ethernet ports (three, if Curtiss-
Wright wired up all 3 MACs). As a test, I would enable a second port
on the target and cable it to another machine. For example,

[snip]

You are correct, Curtiss-Wright did wire up another NIC, but
unfortunately we've had a problem enabling it. Another group of my
coworkers is tackling that problem. If they get it working we'll try
setting up another machine on a two-node network, the way you
suggested.

Thanks again for all your help. We've been in contact with Curtiss-
Wright support and Wind River support, but this thread has provided us
with the most help so far. In fact, our Wind River support contact
provided a cornucopia of advice, almost all of which he copied from
your last post. He omitted to include phrases which would point to a
fault of Wind River's, like your phrase "a serious problem with the
stack." Blah.

Warm regards,
Justin
.

Relevant Pages

  • Re: weird network problems on i386 vxworks 5.4
    ... similar vintage vxWorks. ... tNetTask crashes in tcp_reass ... The task calling ftpXfer blocks forever in the socket readcall. ... I've yet to have anything reproducible enough to send to Wind River. ...
    (comp.os.vxworks)
  • Re: Unicode Font for non windows system
    ... operating system VxWorks. ... Windows system will be transferred to the VxWork environment. ... I'll try to find a License agreement to proof what I said, and if I'm wrong, ... I'm looking for a Unicode font with a big range of different charsets ...
    (comp.fonts)
  • Re: microkernel task scheduler -> RTOS scheduler info
    ... task-driven operational flight program from an ancient processor (Z8000 ... in ASM) to a modern language that will run on a PowerPC processor. ... Wind River or Green Hills. ... VxWorks from Wind River has a steep learning curve coming from your ...
    (comp.arch.embedded)
  • Re: Mars Rover Controlled By Java
    ... > created by JPL which execute on the VxWorks real-time operating system ... > worked for Wind River until recently. ... nearly all embedded control systems using the Intel ... Their VxWorks RTOS package is really slick...I know this because I was ...
    (comp.lang.java)
  • Re: Mars Rover Controlled By Java
    ... > created by JPL which execute on the VxWorks real-time operating system ... > worked for Wind River until recently. ... nearly all embedded control systems using the Intel ... Their VxWorks RTOS package is really slick...I know this because I was ...
    (comp.programming)