Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

NicheStack TCP Client not working with some servers

I've been trying to talk to an Arecont IP camera via a TCP socket client on a BeMicro Nios2 app.

The connection to the camera always failed to establish, although it was ok if I substituted the camera for a TCP server on a Windows PC.

After lots of debug, I noted that the ARP reply from the camera did not have the correct Target Protocol (IP) Address (TPA); it actually contained the camera's IP address. It should have the originating client IP address.

Investigation revealed that the NicheStack ARP receiver code filters the ARP messages using the Target IP Address (TPA).

The code is as follows:

{bsp}/iniche/src/ip/et_arp.c

int

arprcv(PACKET pkt)

{

...

/* check ARP's target IP against our net's: */

#ifdef IP_MULTICAST

if ((arphdr->ar_tpa != pkt->net->n_ipaddr) && /* if it's not for me.... */

(!IN_MULTICAST(ntohl(arphdr->ar_tpa))))

#else

if (arphdr->ar_tpa != pkt->net->n_ipaddr)

#endif/* IP_MULTICAST */

{

LOCK_NET_RESOURCE(FREEQ_RESID);

pk_free(pkt); /* not for us, dump & ret (proxy here later?) */

UNLOCK_NET_RESOURCE(FREEQ_RESID);

return (ENP_NOT_MINE);

}

As the Target IP Address does not match the client IP address, ARP discards the camera response. A connection timeout results.

Whilst the code to filter the ARP responses can be commented out, it exposes the stack to much higher traffic and buffer errors can result.

Question? Is the camera in error by not setting the ARP reply Target IP Address (TPA) correctly or is the NicheStack in error by filtering on it?

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Since the ARP packets are sent only once/twice (maybe a few times more, but not much), the buffers get overflow due to camera traffic. Enable all optimizations, but nichestack is very VERY slow regarding such streams.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    This is probably not the ARP reply, but a gratuitous announcement. When a link is established, each partner can send such a packet to announce their MAC and IP on the network. What is the destination MAC address (in the Ethernet header)? If it's all FFs then it is a gratuitous announcement, and not a reply to an ARP request.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The destination MAC address is the correct address for my client (unicast not broadcast), so I'm happy that this is the ARP reply (opcode 2) of my ARP request.

    I would add a WireShark capture here to show this but it seems I can't add images to posts!!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ok, here's the WireShark capture of the ARP reply:

    Ethernet II, Src: ArecontV_06:cc:49 (00:1a:07:06:cc:49), Dst: IntelCor_26:63:f9 (00:15:17:26:63:f9)

    Destination: IntelCor_26:63:f9 (00:15:17:26:63:f9)

    Address: IntelCor_26:63:f9 (00:15:17:26:63:f9)

    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

    Source: ArecontV_06:cc:49 (00:1a:07:06:cc:49)

    Address: ArecontV_06:cc:49 (00:1a:07:06:cc:49)

    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

    Type: ARP (0x0806)

    Trailer: 000000000000000000000000000000000000

    Address Resolution Protocol (reply/gratuitous ARP)

    Hardware type: Ethernet (1)

    Protocol type: IP (0x0800)

    Hardware size: 6

    Protocol size: 4

    Opcode: reply (2)

    [Is gratuitous: True]

    Sender MAC address: ArecontV_06:cc:49 (00:1a:07:06:cc:49)

    Sender IP address: 172.18.11.10 (172.18.11.10)

    Target MAC address: IntelCor_26:63:f9 (00:15:17:26:63:f9)

    Target IP address: 172.18.11.10 (172.18.11.10)

    Note the 'Sender IP address' = 'Target IP address' in the ARP reply from the camera.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Yes indeed it looks like a bug in the camera. But I think that you can modify the Interniche source code and remove the ip address test. ARP answers addressed to other nodes on the network will have another MAC destination address and will be filtered by the MAC anyway.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    It's just a bit odd that a Windows PC talks to the camera ok. Winsock doesn't seem to mind about the incorrectly set TPA.

    Also I'm not particularly familar with the various RFC's on this subject, so I'm not sure what is mandatory and/or optional for an ARP request/reply. I cant decide where to lay the blame! Camera or stack.

    So going back to my initial question:

    Is the camera in error by not setting the ARP reply Target IP Address (TPA) correctly or is the NicheStack in error by filtering on it?

    Should I raise a support case for Altera/InterNiche to look at?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The camera is definitely to blame. It took me 5 seconds to search "arp rfc" on google and an additionnal 10 seconds to find the relevant paragraph ;) 

    Packet Reception:
-----------------
When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  
  ?Do I speak the protocol in ar$pro?
  Yes:
    
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

    Windows is know to be tolerant with lots of non conformities, which cause a lot of problems when hardware manufacturers test their equipment only with Windows.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks very much Daixiwen for your prompt replies.

    The RFC makes sense to me now.

    I've raised a support query with the camera people so hopefully they can help me out.

    Thanks again.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Good luck with that one.....

    You stand about as much chance of success as when I complained about a CF card that gave an incorrectly formatted response to the ATA 'identify' command (or just locked up! 2 cards, 2 faults).

    Cards were returned with a nice, shiny new MBR in sector one!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hmmm..... point taken.

    I've been looking for a work-around for this one.

    Just commenting out the TPA check code allows the camera to talk but I'm bothered about the amount of packets hitting the ARP table; since packets not for me are no longer being discarded.

    I did try replacing with an own MAC address check against THA instead, but that didn't appear to work at all for some reason!!!!

    And I really don't like special cases in the code for 'dodgy' equipment!!

    Still, mustn't grumble. Much!