Dropping Ethernet Connections

"seecwriter-/[email protected] [rabbit-semi]" <[email protected]>
Newsgroups gmane.comp.hardware.rabbit-semiconductor
Message-ID <[email protected]>
I'm using an RCM3900 and DC v9.62. I have a Windows app that connects to the Rabbit via tcp/ip and sends status request messages to the Rabbit every 500msec. The request message is 11-bytes of data, the Rabbit response is 63-bytes of data.  After operating about 1-10 minutes the Rabbit terminates the connection.
 

 I collected packet data with wireshark, and didn't find anything unusual.  It shows normal traffic going back and forth, and then suddenly the Rabbit closing the connection.  I then turned on various verbose switches in the DC tcp/ip libraries, and put some of my debug statements in the libraries, and what I found is that ARP is terminating the connection.
 

 In library tcp.lib, in function tcp_Retransmitter(), there is a for loop that checks each socket to see if it has data to be retransmitted. In this function is the following snippet of code:
 

       if (s->kflags & TCP_KF_NOARP) {
       // This socket waiting for ARP resolve.
       ath = _rs_arpresolve_check(s->sath, s->hisaddr);
       if (ath > 0) {
        // Resolved OK.
        s->kflags &= ~TCP_KF_NOARP;
        tcp_send(s, 105);
          UNLOCK_SOCK(s);
          continue;
         }
   // Not yet resolved.
   if (ath != ATH_AGAIN) {
    printf("tcp abort 1: %08lX, ath=%d \r\n", s->hisaddr, ath );  // My debug statement.
     // Got an error.
    _rs_sock_msg(s, NETERR_NOHOST_ARP);
    _rs_tcp_abort(s);
     }
         UNLOCK_SOCK(s);
         continue;
   }
 

 What happens is that rs_arpresolve_check() is called for the open socket and it sets "ath" to ATH_OBSOLETE which causes it to abort the socket.  
 

 Looking through the verbose output of arp.lib, the rabbit is constantly calling rs_arpresolve_check() for various IP addresses, which have nothing to do with the Rabbit, but maybe that's normal. One of the IP addresses it's constantly resolving is the address of the PC it's connected to, which is 10.250.7.104 (0AFA0768). The Rabbit is at IP address 10.250.7.235 (0AFA07EB).
 Here are some typical verbose outputs after running for several minutes and just before the disconnect:
 

 ARP: created new entry 1 (for 0AFA0768 on i/f 0)        <----- There are many of these at different entry #'s.
ARP: who has 0AFA0768? (on i/f 0)

 ...
 ARP: 0AFA0768 replying to 0AFA07EB  i/f 0
ARP: reloading because his IP address in cache        <----- Why would a reload be necessary? It didn't change.
ARP: loaded entry:
 1 35 0 10.250.7.104    CC:52:AF:4B:76:7F  0 OK

 ...
 ARP: arpresolve_start for IP 0AFA0768  i/f 0...
 ...
 tcp abort 1: 0AFA0768 ath= -8
 

 Are there any clues here to explain why the Rabbit aborts?
 

 For the record, I've tried different PCs, different Rabbit modules, different Ethernet switches. No difference.
 

 Steve
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.