| Newsgroups |
gmane.comp.hardware.rabbit-semiconductor |
| Message-ID |
<[email protected]> |
Steve,
Looks like an ARP bug. Have you patched your 9.62 with the updated libraries? I don't know if the patch addresses anything ARP-related, but visit http://www.digi.com/support/productdetail?pid=5053 and click on Development Software. Download the patch and review the read me to see if anything seems related.
Could it be that you have a bunch of network traffic -- maybe connection attempts -- that cause the Rabbit to initiate ARP lookups for some reason? And all of those ARP requests force a drop of the cached entry for the PC it's talking to?
An ARP shouldn't be required if the socket is active. Is it possible you have some code that's overwriting a buffer and changing the socket kflags value? Maybe monitor that stuct member and dump to STDOUT if the TCP_KF_NOARP flag is set, perhaps dumping the current value at the same time. Maybe it's getting jumbled with a bunch of other flags set as well...
-Tom
On Apr 17, 2015, at 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
>
>
>
>
>
>