I’m using W6100.
As written in section 2.1.1 of RFC5227, I am sending an ARP Probe from the W6100 to check for address conflicts.
When I receive an ARP Probe from another device while checking for conflicts (waiting for timeout), the IPCONF bit in the IR register is set even though the TargetIpAddress is different.
Each device should set SenderIpAddress to 0.0.0.0 when sending ARP Probe. Is the IPCONF bit set when the SenderIpAddress is the same (0.0.0.0)?
Is it possible to determine whether or not an ARP Probe with the same TargetIpAddress is received, as described in RFC5227 section 2.1.1, “In addition, …”?
Hi,
The image is a wireshark capture with two devices and a DHCP server.
The firmware is designed to send a DHCP Decline when IPCONF is set.
In the image, the TargetDevice is sending a DHCP Decline due to the IPCONF being set by the OtherDevice issuing an ARPProbe.
The desired behavior is to send a DHCP Decline only when an ARPProbe with an IP address equal to the W6100’s own IP address is received.
Should it send ARP response saying that IP address is occupied? Sending DHCP decline, at least as on the picture you provided, is broken process, because DHCP ACK was already sent and received in previous packet, and DHCP process has completed.
When in this packet exchange you have IPCONF bit set? In the packet 11 - someone else (12:00:07) asking if anyone on the network is having 192.168.2.206? What is your (W6100) IP address at the time when packet 11 is received?
For the DHCP sequence, we check for IP address conflicts by sending ARPProbes according to Sections 3.1 clause 5 of RFC2131.
In addition, according to section 2.1.1 of RFC5227, we check for ARP Probe or ARPResponse reception from other devices for 1 second after sending ARPProbe.
If there is no reception for 1 second, the probe is repeated three times in total, and if there is no reception, it is determined that there is no conflict.
I will explain the packet of the image.
In packets 1 through 4, W6100 (12:00:06) is leased an IP address of 192.168.2.204 from the DHCP server.
In packets 5-6, the W6100 just sent an ARPProbe twice to see if anyone on the network has 192.168.2.204.
The other device (12:00:07) gets IP address 192.168.2.206 in packets 7-10.
In packets 11 and 13-14, 12:00:07 is asking if someone on the network has 192.168.2.206.
The W6100 sets the IPCONF bit when it receives packet 11.
Sounds really strange. The next step would be - as soon as you get this interrupt from conflicting IP addresses (and before doing anything else), perform dump of all the common and all the socket registers and post here. Let’s see what regs have at the time of event.
The first thing I want to know is the conditions under which the IPCONF bit is set. It doesn’t seem to be written in the datasheet.
All ARP Probe packets have a Sender IP address field of 0.0.0.0, so both packets sent by the W6100 (12:00:07) and received from other devices (12:00:06) will be 0.0.0.0. .
The IP address you want to search for is indicated in the Target IP Address field.
If IPCONF is set only by matching the Sender IP address field of the packet sent by the W6100 and received by the W6100, IPCONF will be set even if the target IP address fields are different.
In section 2.1.1 of RFC5227 it says:
“In addition, if during this period the host receives any ARP Probe where the packet’s ‘target IP address’ is the address being probed for, and the packet’s ‘sender hardware address’ is not the hardware address of any of the host’s interfaces, then the host SHOULD similarly treat this as an address conflict and signal an error to the configuring agent as above.”
Therefore, once again, when detecting conflicts with ARPProbe, it is necessary to determine if the Target IP address matches and the Sender MAC address does not match for received ARP packets.
If the IPCONF bit do not meet this condition, it seems necessary to check in firmware using a register that can obtain the value of each field of the received ARP packet.
Manual states “IPCONF: 1 : IPv4 Address Conflict occurred”.
If you do not provide data for consideration, no one will be able to help. First of all we must prove that your W6100 is in proper state when “issue” happens. For this I asked for register dump.
Manual states “IPCONF: 1 : IPv4 Address Conflict occurred”.
I would like to know how the W6100 chip determines when an IPv4 address conflict occurs.
If you do not provide data for consideration, no one will be able to help. First of all we must prove that your W6100 is in proper state when “issue” happens. For this I asked for register dump.
I got a dump of the registers after IPCONF was 1 as below.
IR=0x04 -> IPv4 address conflict
IMR=0x02 -> IPCONF bit is 0! (only port unreachable interrut is enabled)
SIR=0x010 -> socket 4 interrupt occured
SIMR=0x00 -> no socket interrupts are enabled!
SLDIPR =0xC0A802C9 -> destination IP address set to 192.1698.2.201
SLDHAR =0x000000000000 -> destination hardware address, not set
Socket4:
UDP4 mode
received data
max MSS=0x5c0
source port=0x44
detstination hardware reg =0xffffffffffff
destination IP address=0xffffffff
destination oprt reg=0x43
TX_WR macthes TX_RD
RX_WR matched RX_RD
You have IP address conflict bit set, but you have only port unreachable interrupt enable bit set.
You have socket 4 interrupt pending. At the same time socket interrupts are not enabled, must not cause hardware interrupt.
Socket4 is in UDP mode, having source port 0x44 and source MAC address 00:00:00:12:00:06, destination port 0x43, and destination MAC address and IP address unresolved. No new data to be sent, all data read.
Source of interrupt for socket4 is clear: something was received on the socket. RD and WR pointers are same means you have read the data, but most probably forgot to clear the interrupt flag. As soon as SENDOK bit is not set, assume you did not send anything onto the socket4 yet (or you cleared the flag).
Now let’s again look at the picture you provided at the beginning.
W6100 asks for IP address, sending from 0.0.0.0 to broadcast ff.ff.ff.ff. Server replies to c0.a8.02.cc, however the response must have been given to ff.ff.ff.ff (broadcast) with W6100 MAC address in the payload. IMHO DHCP server does wrong assuming 192.169.2.204 before DHCP process completes. Maybe because this address has already been leased to the W6100 before.
Then, after accepting DHCP leased IP address, W6100 asks two times if someone has the same IP address.
Shortly another device starts DHCP process, obtains 192.168.2.206, and after completion of DHCP process sends request if anyone else ahs this IP address.
And you say when this packet is received by the W6100, it raises IP address conflict bit.
And you set W6100 to send DHCP decline as soon as this bit gets set.
Right?
You have IPCONF-related interrupt disabled, this means you perform polling of this bit and not (almost immediately) reacting its state change. Are you sure that this IPCONF status bit is being polled regularly and that your W6100 driver notices the change promptly? May be this bit being set earlier than reception of that ARP packet from 12:00:07? Are you sure you see all the packets being transferred on the network in the capture?
As you posted, I am sending the ARPProbe using a socket-less command.
This is based on the W6100 datasheet section 6.6.1.
After transmission, we poll the IPCONF bit in the IR register in addition to the ARP4 and TOUT bits in the socketless interrupt register SLIR.
The software flow is shown below.
//-----------------------------
setIRCLR(IR_IPCONF);
setSLRCR(2);// max 3 times
setSLRTR(10000);// timeout=1 second
setSLDIP4R(OfferedIp);
setSLCR(SLCR_ARP4);// send ARP Probe
while(getSLCR()){
osDelay(1);
}
while(((tmp = getSLIR()) & 0xC0) == 0x00){ // break when ARP4 or TOUT
if((tmp = getIR() & 0x04) == 0x04){
break;// break when IPCONF
}
osDelay(1);
}
// check tmp value
// if ARP4 or IPCONF → Detect Conflict, send DHCPDECLINE
// if TOUT → No conflict, continue.
//-----------------------------
At this timing, there is DHCP broadcast packet communication between 12:00:07 and the DHCP server, but IPCONF was not set.
Then 12:00:07 sends an ARPProbe and the W6100’s IPCONF is set.If the ARPProbe from 12:00:07 does not come, the IPCONF bit will not be set.
According to wireshark, no other packets were flowing during this period.
UDP socket 4 was used for previous DHCP communication (broadcast transmission), and the register value remained. As a test, I closed socket 4 before sending the ARPProbe, and the IPCONF bit was set without any effect.
12:00:07 sends ARP request, not ARP response, therefore 12:00:06 must not react to it. This source does not use this mechanism, thus no explicit proof of using this functionality.
If code breaks in break then you get IPCONF set without receiving the ARP reply and within timeout interval. But note that you assign same tmp variable in both locations, and it is important how you check tmp. Assignment syntax differs a little (in while you get tmp assigned to SLIR[7:0], in if - only bit 2 of IR). You may have designed (optimized) this intentionally, but it looks unusual in the debugging environment. Imagine getSLIR() return 0x84 for some reason, would your checks you did not disclose be reliable?
Read IR register just before you send ARP, and check its bit 2 to ensure it is reset.
12:00:07 sends ARP request, not ARP response, therefore 12:00:06 must not react to it. This source does not use this mechanism, thus no explicit proof of using this functionality.
We believe that source code is insufficient to meet the requirements of section 2.1.1 of RFC5227.
The source code can detect conflicts by someone’s ARP reply, but it cannot detect conflicts when someone does an ARP probe with the same IP address.
I expected that by monitoring the IPCONF bit, I could check for ARP probes for the same IP address that someone sent. However, the IPCONF bit can be set not only by ARP probes with the same IP address, but also with different IP addresses.
Read IR register just before you send ARP, and check its bit 2 to ensure it is reset.
I checked the IP register just before sending the ARP probe and the IPCONF bit is reset (0).
Therefore, we are certain that the IPCONF bit was set (1) by the ARP probe from 12:00:07.
Your registerdump i quite useless here - we would need dumps right before and after every packet to really now, whats going on here.
You are right, sadly theres no information about when the IPCONF-bit is set.
BUT its name is “IP” - you can only have IP-conflicts when having an IP packet. ARP-packets ARE NO IP PACKETS! DHCP-Packets are IP packets!
ARP-Packets are under the IP-Layer in the MAC-layer therefore wireshark is displaying MAC addresses as source and destination.
If so, W6100 has to differ between an ARP and “normal” IP packets. I don’t think it does.
Just change your test setup - i suggest doing the following to reverse engeneer the IPCONF-bit.
Simulate a “real” IP conflict (you need two ethernet chips for that). You have to ensure there is no other traffic on the network!
Simulation one: two CHIPs send IP-packets with the same IP
reset IPCONF-bits in all chips
CHIP1 send any IP-Packet with IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 0)
check CHIP2s IPCONF-flag (should be 0)
CHIP2 send any IP-Packet with IP 192.168.0.11 (same as CHIP1)
check CHIP1s IPCONF-flag (should be 1)
check CHIP2s IPCONF-flag (should be 1)
Simluation two: IP-Address = 0.0.0.0
reset IPCONF-bits in all chips
CHIP1 send any IP-Packet (e.g. DCHP OFFER) with IP 0.0.0.0
check CHIP1s IPCONF-flag (should be 0) <<< if NOT, wiznet chip is telling you, that ip 0.0.0.0 is “uncommon”
check CHIP2s IPCONF-flag (should be 0)
CHIP2 send any IP-Packet (e.g. DCHP OFFER) with IP 0.0.0.0 (same as CHIP1)
check CHIP1s IPCONF-flag (should be 1) <<< because a DCHP-OFFER is UDP-> therefore it works including the IP-Layer
check CHIP2s IPCONF-flag (should be 1)
Simulation three: both CHIPs ARPing different IP-Addresses:
reset IPCONF-bits in all chips
CHIP1 send an ARP-request for IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?
check CHIP2s IPCONF-flag (should be 0) and ARP-Error flag = no error?
CHIP2 send an ARP-request for IP e.g. 192.168.0.12
check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = no error?
check CHIP2s IPCONF-flag (should be 1) and ARP-Error flag = no error?
Simulation four: both CHIPs ARPing SAME IP-Addresses:
reset IPCONF-bits in all chips
CHIP1 send an ARP-request for IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?
check CHIP2s IPCONF-flag (should be 0) and ARP-Error flag = no error?
CHIP2 send an ARP-request for IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = no error?
check CHIP2s IPCONF-flag (should be 1) and ARP-Error flag = no error?
We expect no error here, because there is no answer to the ARP? (forgot what RFC says here)
Simulation five: CHIP1 ARPing - CHIP2 responding:
reset IPCONF-bits in all chips
CHIP1 send an ARP-request for IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?
check CHIP2s IPCONF-flag (should be 0)
CHIP2 send an ARP-respond for IP e.g. 192.168.0.11
check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = ERROR?
IP Conflict
It is set as ‘1’, when there is ARP request with same IP address as Source IP address. This bit is cleared to ‘0’ by writing ‘1’ to this bit.
IP Conflict
It is set as ‘1’, when there is ARP request with same IP address as Source IP address. This bit is cleared to ‘0’ by writing ‘1’ to this bit.
To my experience all the chips are based on the same “engine”, therefore if there’s no explicitly defined difference we may assume same behavior.
But we see here… them talking about Source IP address! But ARP packet does NOT have source IP address in the header, there’s target IP address in the payload. Anyway now it looks not only behaving incorrectly, but also being documented incorrectly…
Right, and these are two different locations in the data packet - source IP address goes in header of IP packet, and ARP IP address goes in Ethernet frame payload.
