NicheStack TCP Client not working with some servers

[Altera_Forum]

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? 

[Altera_Forum]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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!

[Altera_Forum]

You can always use another camera ;) 

But as I said, the MAC already filters packets that don't have the correct MAC destination address in the Ethernet header, so in theory the only ARP packets that should arrive to this function are broadcasts and the replies specifically destined to you. So I don't think you'll have an increase in processed ARP packets if you do this. But I agree you shouldn't have to modify your TCP/IP stack to cope with bad equipment...

[Altera_Forum]

The camera people, Arecont Vision in this case, excepted the problem was with their firmware and issued us a fix within 2 weeks. We checked out the fix and all is ok - the ARP response is formatted correctly. How's that for service!:)

[Altera_Forum]

That's good to know! I'm glad you could get this fixed.