| Newsgroups |
gmane.comp.hardware.rabbit-semiconductor |
| Organization |
Quest Controls |
| Message-ID |
<[email protected]> |
You could really break some rules and make yourself a permanent entry in
the arp cache. Search for ATE_PERMANENT. Maybe everyone will leave it
alone...
On 4/17/2015 2:47 PM, seecwriter-/[email protected] [rabbit-semi] wrote:
>
> 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
>
>
>
>