Problem with Gratuitous ARP when trying to send UDP


#1

First, I am using the W5200 with a PIC24FJ256GB210 and the HW TCPIP Library Driver ver.1.2 with the microchip_solutions_v2013-06-15. I am trying the setup a class one EIP connection which requires opening and closing a UDP socket at port 2222. I am getting Gratuitous ARPs whenever my device tries to send a UDP message. From what I have read, the UDP needs to send out an ARP to know where it is going, I don’t believe this is happening correctly. I was able to get it working by inputing the MAC of my computer directly into the registers then using the MAC_SEND version. However, since I can’t hardcode the desination MAC for other computers this is not a viable solution. I cannot find where the W5200_UDP.c version assembles the header information compared to the Microchip stack version in UDP.c UDPFlush(). The W5200 version of UDPFlush() only puts them in the Sn_DIPR0 reg, it doesn’t add it to the TX buffer.

I will attach the wireshark trace to help clarify.

Thanks in advance for your help.

Kevin Weiss
Firmware Engineer for Powell Industries
EIPARPProblem.rar (1.18 KB)


#2

Hi,

Did you implement PIC’s software TCP/IP stack on W5200’s MACRAW mode?
WIZnet TCP/IP chip can’t send gratuitous ARP packet to any peer.

The gratuitous ARP is often used for detection of IP conflict.
According to wireshark capture file, becase sender ip address is equal to target ip address, the captured APRs is shown as gratutious ARP.

Anyway, I don’t know how to work PIC’s software TCP/IP and I don’t understand how to communicate between two IP address with different subnet mask.
Is your device used as gateway? and which IP address is yours?


#3

My device is connected directly into my CPU via ethernet cable. My device IP is 169.254.1.1 and my CPU is 128.1.1.25. I will look into deeper in the stack, maybe the MACRAW mode isn’t being implemented correctly. If anyone has gotten these stacks to work together let me know (and the versions).


#4

Hi,
I wonder what value is your subnet mask?
As you said that each devices are directly connected via ethernet cable, There was no any router or any gateway.
Without a router or a gateway, you can’t communicate with your CPU normaly.

I think you’d better modify your device ip to x.x.x.x for belonging in same your CPU network network.

For IPv4 subnetting, refer to http://en.wikipedia.org/wiki/IPv4_subnetting_reference


#5

The subnet Mask is 255.255.0.0. The results are the same through a router or not. The TCP is working fine. The program with the CPU claims an address (the LAN 128.1.1.25 in this case) for transmission.


#6

I have managed to get everything working and have a few notes for anyone interested.

The HW TCPIP Library Driver ver.1.2 that was used did not allow UDP to work with my microchip product

The SW TCPIP Library Driver ver.1.4 had a fault (the orginal reason I switch to the HW TCPIP library) which would cause an occasional packet to be improperly sent… This caused a unpreventable timeout in my software.

The reason for this timeout was in

SW TCPIP Library Driver ver.1.4
W5200.c
void MACPutArray()

if( RealTXPAddress.Val + len > TXEND ){

that line should be;
if( RealTXPAddress.Val + len >= TXEND ){

The problem would truncate the length of the sent packet only if RealTXPAddress.Val + len == TXEND
Since my packets are around 100 bytes and my buffer size was 4k

there is a 1 in about (100*4k) 400000 chance of getting this error.

Hopefully this helps other people, also please update stack to fix this. This cost a lot of unnessasary time.

Kevin Weiss


#7

Thanks for your sugguestion.
You will help anybody for any software TCP/IP stack.

Anyway, I will be still wonder how to communicate between 164.254.1.1 and 128.1.1.125 on 255.255.0.0 subnet.
As I know, The two IP address have the result of subnet mask.

Thank you.


#8

Hi Kevin
I am currently developing an EIP layer using a PIC24 too. I would be interested in what you are using for the EIP layer? Is it bought or is it your own? If it is third party I would be very interested in details. If it is a working home brew I would be also interested in a code share.
Mark