---
title: "W6100 IPCONF is set by other device's ARP Probe"
url: "https://maker.wiznet.io/forum/14617"
markdown_url: "https://maker.wiznet.io/forum/14617/md"
type: "Forum topic"
category: "Ethernet Chips"
author: "tom3"
created: "2022-08-18T08:12:17+09:00"
last_activity: "2022-09-01T05:43:00+09:00"
language: "en"
views: 1023
replies: 42
source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)"
---

# W6100 IPCONF is set by other device's ARP Probe

## Question

Asked by tom3 on 2022-08-18 in Ethernet Chips.

Hello,

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, …”?

Thanks,

## Replies

### Reply 1 by Eugeny, 2022-08-18

Post contents of the packets being exchanged on the network - either binary or as a Wireshark pictures.

### Reply 2 by tom3, 2022-08-19 (in reply to reply 1)

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.

[![ArpProbing](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/2b8e4bb1b99f3e1ca4e040a728ed0f03997aa6b4.gif) ArpProbing1125×856 383 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/2b8e4bb1b99f3e1ca4e040a728ed0f03997aa6b4.gif)

Thanks,

### Reply 3 by Eugeny, 2022-08-19

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> The firmware is designed to send a DHCP Decline when IPCONF is set.

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?

### Reply 4 by tom3, 2022-08-19

Thank you for your reply.

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.

Thanks,

### Reply 5 by Eugeny, 2022-08-19

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.

### Reply 6 by tom3, 2022-08-19

Thank you for your help.

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.

thanks,

### Reply 7 by tom3, 2022-08-19

Sorry. There was a typo.

*W6100(12:00:07) → (12:00:06)
*Other device(12:00:06) → (12:00:07)

### Reply 8 by Eugeny, 2022-08-19 (in reply to reply 7)

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> Sorry. There was a typo.
>
> *W6100(12:00:07) → (12:00:06)
> *Other device(12:00:06) → (12:00:07)

You can edit your earlier posts.

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> 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.

Manual states “IPCONF: 1 : IPv4 Address Conflict occurred”.

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> If IPCONF

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> it is necessary to determine if

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> If the IPCONF

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.

### Reply 9 by tom3, 2022-08-22

Thank you for your advice.

> 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.

–W6100 Dump common Registers.
CIDR =0x6100
VER =0x4661
SYSR =0xE1
SYCR1 =0x80
TCNTR =0x52C9
IR =0x04
SIR =0x10
SLIR =0x00
IMR =0x02
SIMR =0x00
SLIMR =0x00
SLPSR =0x00
SLCR =0x00
PHYSR =0x05
PHYRAR =0x00
PHYDOR =0x0000
PHYACR =0x00
PHYDIVR=0x01
PHYCR1 =0x40
NET4MR =0x00
NET6MR =0x00
NETMR =0x02
NETMR2 =0x00
PTMR =0x28
PMNR =0x00
PHAR =0x000000000000
PSIDR =0x0000
PMRUR =0xFFFF
SHAR =0x000000120006
GAR =0x00000000
SUBR =0x00000000
SIPR =0x00000000
LLAR =0xFE80000000000000040000FFFE120006
GUAR =0x20000000000000000000000000000000
SUB6R =0x00000000000000000000000000000000
GA6R =0x00000000000000000000000000000000
SLDIP6R=0x000000000000000000000000C0A802C9
SLDIPR =0xC0A802C9
SLDHAR =0x000000000000
PINGIDR =0x6100
PINGSEQR=0x0000
UIPR =0x00000000
UPORTR =0x0000
UIP6R =0x00000000000000000000000000000000
UPORT6R=0x0000
INTPTMR=0x0000
PLR =0x00
PFR =0x00
VLTR =0x00000000
PLTR =0x00000000
PAR =0x00000000000000000000000000000000
ICMP6BLKR=0x00
RTR =0x07D0
RCR =0x07
SLRTR =0x2710
SLRCR =0x02
SLHOPR =0x80
–W6100 Dump Socket 0 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 1 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 2 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 3 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 4 Registers–
Sn_MR =0x02
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x04
Sn_IMR =0xFF
Sn_SR =0x22
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x05C0
Sn_PORTR =0x0044
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0xFFFFFFFF
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0043
Sn_MR2 =0x00
Sn_RTR =0x07D0
Sn_RCR =0x07
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0258
Sn_TX_WR =0x0258
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0458
Sn_RX_WR =0x0458
–W6100 Dump Socket 5 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 6 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000
–W6100 Dump Socket 7 Registers–
Sn_MR =0x00
Sn_PSR =0x00
Sn_CR =0x00
Sn_IR =0x00
Sn_IMR =0xFF
Sn_SR =0x00
Sn_ESR =0x00
Sn_PNR =0x00
Sn_TOSR =0x00
Sn_TTLR =0x80
Sn_FRGR =0x4000
Sn_MSSR =0x0000
Sn_PORTR =0x0000
Sn_DHAR =0xFFFFFFFFFFFF
Sn_DIPR =0x00000000
Sn_DIP6R =0x00000000000000000000000000000000
Sn_DPORTR =0x0000
Sn_MR2 =0x00
Sn_RTR =0x0000
Sn_RCR =0x00
Sn_KPALVTR=0x00
Sn_TX_BSR =0x02
Sn_TX_FSR =0x0800
Sn_TX_RD =0x0000
Sn_TX_WR =0x0000
Sn_RX_BSR =0x02
Sn_RX_RSR =0x0000
Sn_RX_RD =0x0000
Sn_RX_WR =0x0000

Please tell me if there is anything strange.

Thanks,

### Reply 10 by Eugeny, 2022-08-22

So what we see here:

```
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?

### Reply 11 by tom3, 2022-08-23

Thank you for your detailed analysis.

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.

Thanks,

### Reply 12 by Eugeny, 2022-08-23

12:00:07 sends ARP request, not ARP response, therefore 12:00:06 must not react to it. [This source](https://github.com/Wiznet/io6Library/blob/master/Ethernet/wizchip_conf.c#L757) does not use this mechanism, thus no explicit proof of using this functionality.

```
while(((tmp = getSLIR()) & 0xC0) == 0x00)
{
 if((tmp = getIR() & 0x04) == 0x04)
 {
   break;
 }
 osDelay(1);
}
```

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.

### Reply 13 by tom3, 2022-08-24

Thank you for your advice.

> 12:00:07 sends ARP request, not ARP response, therefore 12:00:06 must not react to it. [This source](https://github.com/Wiznet/io6Library/blob/master/Ethernet/wizchip_conf.c#L757) does not use this mechanism, thus no explicit proof of using this functionality.

We believe [that source](https://github.com/Wiznet/io6Library/blob/master/Ethernet/wizchip_conf.c#L757) 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.

Thanks,

### Reply 14 by Welocs, 2022-08-24

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

1. reset IPCONF-bits in all chips

2. CHIP1 send any IP-Packet with IP e.g. 192.168.0.11

3. check CHIP1s IPCONF-flag (should be 0)

4. check CHIP2s IPCONF-flag (should be 0)

5. CHIP2 send any IP-Packet with IP 192.168.0.11 (same as CHIP1)

6. check CHIP1s IPCONF-flag (should be 1)

7. check CHIP2s IPCONF-flag (should be 1)

**Simluation two: IP-Address = 0.0.0.0**

1. reset IPCONF-bits in all chips

2. CHIP1 send any IP-Packet (e.g. DCHP OFFER) with IP 0.0.0.0

3. check CHIP1s IPCONF-flag (should be 0) <<< if NOT, wiznet chip is telling you, that ip 0.0.0.0 is “uncommon”

4. check CHIP2s IPCONF-flag (should be 0)

5. CHIP2 send any IP-Packet (e.g. DCHP OFFER) with IP 0.0.0.0 (same as CHIP1)

6. check CHIP1s IPCONF-flag (should be 1) <<< because a DCHP-OFFER is UDP-> therefore it works including the IP-Layer

7. check CHIP2s IPCONF-flag (should be 1)

**Simulation three: both CHIPs ARPing different IP-Addresses:**

1. reset IPCONF-bits in all chips

2. CHIP1 send an ARP-request for IP e.g. 192.168.0.11

3. check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?

4. check CHIP2s IPCONF-flag (should be 0) and ARP-Error flag = no error?

5. CHIP2 send an ARP-request for IP e.g. 192.168.0.12

6. check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = no error?

7. check CHIP2s IPCONF-flag (should be 1) and ARP-Error flag = no error?

**Simulation four: both CHIPs ARPing SAME IP-Addresses:**

1. reset IPCONF-bits in all chips

2. CHIP1 send an ARP-request for IP e.g. 192.168.0.11

3. check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?

4. check CHIP2s IPCONF-flag (should be 0) and ARP-Error flag = no error?

5. CHIP2 send an ARP-request for IP e.g. 192.168.0.11

6. check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = no error?

7. 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:**

1. reset IPCONF-bits in all chips

2. CHIP1 send an ARP-request for IP e.g. 192.168.0.11

3. check CHIP1s IPCONF-flag (should be 0) and ARP-Error flag = no error?

4. check CHIP2s IPCONF-flag (should be 0)

5. CHIP2 send an ARP-respond for IP e.g. 192.168.0.11

6. check CHIP1s IPCONF-flag (should be 1) and ARP-Error flag = ERROR?

7. check CHIP2s IPCONF-flag (should be 1)

I wondering the results^^

Regards

### Reply 15 by Eugeny, 2022-08-24

![](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/48.png) Welocs:

> Your registerdump i quite useless here - we would need dumps right before and after every packet to really now, whats going on here.

Possible for outgoing packets, for incoming not because they are asynchronous.

![](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/48.png) Welocs:

> You are right, sadly theres no information about when the IPCONF-bit is set.

[W5500 datasheet](https://docs.wiznet.io/img/products/w5500/w5500_ds_v109e.pdf):

> IP Conflict
> Bit is set as ‘1’ when own source IP address is same with the sender IP address **in the received ARP request**.

[W5100 datasheet](https://www.wiznet.io/wp-content/uploads/wiznethome/Chip/W5100/Document/W5100_DS_V128E.pdf):

> 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.

[W3150+ datasheet](http://wiznethome.cafe24.com/wp-content/uploads/wiznethome/Chip/W3150A_Plus/Documents/W3150A+_DS_V206E.pdf):

> 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…

### Reply 16 by Welocs, 2022-08-24

Eugeny:

> To my experience all the chips are based on the same “engine”

This MAY be true - until i am not shure (unless the W6100s engeneer tells me) i don’t count 100% on that.

Eugeny:

> 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…

Your confused, let me explain:
W5500: “own source IP address” == SIPR
" IP address in the received ARP request." == Wireshark “How has IP …?”

“Source IP address” == IP address of the Wiznets Chip set in “SIPR”.
“ARP request with same IP” == Wireshark “Who has IP…?”

Eugeny:

> Possible for outgoing packets, for incoming not because they are asynchronous.

Then use wireshark to “syncronize”.

### Reply 17 by Eugeny, 2022-08-24

![](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/48.png) Welocs:

> “Source IP address” == IP address of the Wiznets Chip set in “SIPR”.
> “ARP request with same IP” == Wireshark “Who has IP…?”

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.

### Reply 18 by Welocs, 2022-08-24

If the requested IP-Address in the ARP packet (from anther peer) == own source IP ->>> ERROR

### Reply 19 by Eugeny, 2022-08-24

![](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/48.png) Welocs:

> If the requested IP-Address in the ARP packet (from anther peer) == own source IP ->>> ERROR

Agreed, seems I did not read it properly ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12)

Then it seems that chip does not work as expected…

[@tom3](https://maker.wiznet.io/u/tom3) try to contact WIZnet support using email and point them to this thread. Optionally write to sales address to ensure to get attention.

### Reply 20 by Welocs, 2022-08-24

[@tom3](https://maker.wiznet.io/u/tom3) OK some very weired is going on here.
I tried out the same thing as you except the DHCP packets.

I configured one W6100 to send two ARP packet for an IP.
The second W6100 was quiet the same code, ARPing IP+1 (as in your example).
And i get the IPCONF-flag set as well!!! o.O!!
And here comes a really more weired thing: if i set both MAC addresses equal (W6100_1_MAC = W6100_2_MAC), i GET NO IPCONF-FLAG!!! o.OOOO!!

You can really ignore the IPCONF-flag as its information is not trustful.

These are really bad news, because intentionally i like the W6100 hard-TCP stack idea very much. But there are some things which would lead me into not using this chip. I really hope there will be some reactions from the delvelopers to it.

I am trying to get more detailed informations about this bug via wireshark - i tell you if i find something.

[@Eugeny](https://maker.wiznet.io/u/eugeny) do you have the possibility to try this error out this some W5500 or W5100 chips? Would be interesting.

Regards

### Reply 21 by Welocs, 2022-08-24

ok i found out some more stuff:

when trying to get ANY ip adress with my windows PC, while ARPing with W6100, the W6100 will get the IPCONF-bit set.
Also the ARP-Packet from the W6100 is different to windows’ in that way, that it appends the ARP-Packet with padding 0x00 bytes, so the packet has a minimum size of 60 Bytes.
As you can find in the datasheet, this function is used to appear in MACRAW on socket 0 (see datasheet page 116 on the bottom)

> “Data smaller than 60 bytes becomes 60 bytes with zero padding.”

Windows sends only ARP packets without padding bytes, so the total ARP packet size is 42 bytes…

The result of this is, that a W6100s is NOT RESPONDING to an ARP packet from another W6100s chip with padding bytes.
But the W6100 chip is responding to a windows “normal” ARP packet beeing 42 bytes without padding bytes…
We may have found a step more to the W6100s bug.

So even when trying ARPing yourself with a MACRAW rocket, this might be not possible?!
I don’t think so, because the windows’ chip is responding to the W6100s’ 60-byte ARP.

### Reply 22 by Welocs, 2022-08-24

[@Eugeny](https://maker.wiznet.io/u/eugeny) if you have a W5500, could you find out, if in MACRAW mode, it also appends padding bytes, so the macraw payload is at least 60 bytes?
Is there a way how to ARP manually with the W5500?

It is a really serious issue here, because the W6100 not responing to 60 byte arp packet makes DHCP for many W6100 in the same network IMPOSSIBLE! I won’t work with MACRAW mode either (because of the 60bytes) wondering how the W5500 did send an ARP.

### Reply 23 by Eugeny, 2022-08-24

[@Welocs](https://maker.wiznet.io/u/welocs) I have W5100, but can not commit to testing anything shortly. W5500 and W5100 do not have info about these 60 byte padding.

![](https://avatars.discourse-cdn.com/v4/letter/w/b9bd4f/48.png) Welocs:

> The result of this is, that a W6100s is NOT RESPONDING to an ARP packet from another W6100s chip with padding bytes.

You mean automatically? Are you able to receive ARP packet in MACRAW mode and then respond manually? But in general it does not make much sense because operating chips in MACRAW mode, in my opinion, is nonsense, they are built especially for higher level networking stack access.

Let me make a guess… When W6100 receives [ARP](http://www.tcpipguide.com/free/t_ARPMessageFormat.htm) with padding, it thinks that there’s more than one SHA/SPA/THA/TPA set, and as padding is all zeroes, it compares “second” set of addresses to its current address, which is 0.0.0.0, and sets IP address conflict bit. This does not help the issue [@tom3](https://maker.wiznet.io/u/tom3) is having, as his W6100 is having valid IP address already set (right?) which is not zero, when receiving padded ARP request.

As you have test bench set up, try sending ARP packet with data padded with some other value than zeroes, let’s say, padded with 0x01.

### Reply 24 by Welocs, 2022-08-24

**Sorry**, i got a mistake. I forgot that, if one W6100s answering the APR of another W6100, i don’t see this in wireshark. Reading out the SLHAR i get the right MAC read. And the ARP4 flag is set in the SLIR.

Eugeny:

> As you have test bench set up, try sending ARP packet with data padded with some other value than zeroes, let’s say, padded with 0x01.

No, because the windows network is not sending padding and the W6100 will the IPCONF bit.
I suggest the IPCONF bit is not suitable to the ARP-Probe packets - you have to ignore this bit when using ARP with IP = 0.0.0.0
**BECAUSE**
When using ARP with any IP-preset like 192.168.0.3 - there will be no IPCONF error.

**AND** - although having the IPCONF bit set, when theres someone with the IP you are ARPing, the ARP4-bit will set.
So conlusion is: IPCONF has NO functionality when ARPing someone elses IP address!

### Reply 25 by Welocs, 2022-08-24

If you set the IP Addresses e.g. 192.168.0.3 at both Chips and you ARP this address, then you get an ARP repsonse AND IPCONF set
(IR = 0x04
SLIR = 0x40) so in this case, you could detect an IP conflict.

I think there may be some other cases, where IPCONF would set, but stop debugging here, because DHCP is really possible - wow i am so glad ![:sweat_smile:](https://emoji.discourse-cdn.com/twitter/sweat_smile.png?v=12)

What i saw on wireshark was, that, when i set the W6100 IP to the windows IP, there were some packets from the W6100 waring for an IP conflict.

For me, this problem is kind of solved?

Regards

### Reply 26 by tom3, 2022-08-25

Thanks to Eugeny and Welocs for some trials.

I tried the IPCONF bit behavior during ARP probing.

When receiving an ARP probe from another device after sending an ARP probe from the W6100…

result:
IPCONF=1 when the received packet is an ARP probe with a different MAC address in the Ethernet frame. It doesn’t seem to depend on the Target IP address and Sender MAC address in the ARP frame.

The explanations in the datasheets for the W5500 and W5100 posted by Mr. Eugeny are helpful, but I would like an explanation for conflict detection by ARP probing in the datasheets.
When sending ARP probes, the W6100’s SIPR register is set to 0.0.0.0. The Sender IP address of the other device’s ARP Probe is 0.0.0.0, so it seems likely that this address match is detected.
However, even in this case, if the MAC address in the Ethernet frame of the received ARP probe is the same as itself (W6100), the IPCONF bit will not be set. We believe this is the correct behavior for the purpose of excluding echoing back of own packets as described in the “NOTE:…” paragraph of RFC5227 Section 2.1.1.

Similar to the Welcos test, the W6100 receives an ARP reply and sets the ARP4 bit in the SLIR register, correctly detecting conflicts when someone else has the same IP address.

I’ll try emailing WIZNET support about the IPCONF bit in the ARP probe, as Eugeny advised.
I couldn’t find the email address for support on the WIZNET website.
Do you have an email address or URL for support?

Unfortunately, the conclusion is that the W6100 does not comply with RFC5227 Section 2.1.1, “In addition,…” paragraph, "When multiple devices probe the same IP address at the same time, it determines that there is a conflict. " may not be possible.

Thanks,

### Reply 27 by Welocs, 2022-08-25

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> When sending ARP probes, the W6100’s SIPR register is set to 0.0.0.0. The Sender IP address of the other device’s ARP Probe is 0.0.0.0, so it seems likely that this address match is detected

I would strongly recommend NOT to compare the different datasheets that much!! I think the W6100 got some serious updates here, as e.g. the CABLEOFF bit literly doesn’t exist at W5500 or W5100. If the IPCONF would have the exact same behavior has in the older chips, i think they would have copy-pasted it.
If you forget, what is written in the W5500s datasheet - than this bit does really what it is named after === detecting an IP address conflict (which is INDEPENDENT from ARPs, right?) So that this bit is getting set, really makes sense to me.
My recommandation is to ignore this bit, when APRing with 0.0.0.0.

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> Similar to the Welcos test, the W6100 receives an ARP reply and sets the ARP4 bit in the SLIR register, correctly detecting conflicts when someone else has the same IP address

It also detects correctly, if you just try to ARP some other IP.

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> I’ll try emailing WIZNET support about the IPCONF bit in the ARP probe, as Eugeny advised.
> I couldn’t find the email address for support on the WIZNET website.
> Do you have an email address or URL for support?

I hope you’ll get an answer. Please post, if so!
I just wrote them via the contact formular (Company → Contact us)

### Reply 28 by Eugeny, 2022-08-25 (in reply to reply 26)

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> Do you have an email address or URL for support?

[Locations | WIZnet Co., Ltd.](https://www.wiznet.io/locations/)

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> When sending ARP probes, the W6100’s SIPR register is set to 0.0.0.0.

Can you change the algorithm: as soon as you obtain IP address from DHCP, set it into SIPR, and only then send ARP asking if anyone else is having this IP address.

### Reply 29 by tom3, 2022-08-25 (in reply to reply 27)

Hi,

> I would strongly recommend NOT to compare the different datasheets that much!!

I agree.
Certainly, relying on other device datasheets is not a good idea.

> I hope you’ll get an answer. Please post, if so!
> I just wrote them via the contact formular (Company → Contact us)

Thank you for letting me know how to contact WIZNET.
I will write when I get an answer.
Alternatively, I hope that someone from WIZNET will post it.

Thanks,

### Reply 30 by tom3, 2022-08-25

Thanks for the link.

We set a leased IP address in the SIPR register and conducted the test. This means that the W6100 is sending an ARP Announcement, in this case IPCONF will not be set if someone sends an ARP probe (Sender IP=0.0.0.0).

I did one additional test. . .
After the W6100’s ARP Announcement, someone else sent an ARP Announcement with the same Sender IP address. In this case IPCONF was set. (I think it’s the correct behavior, since this is a true conflict)

Regards,

### Reply 31 by Eugeny, 2022-08-25

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> We set a leased IP address in the SIPR register and conducted the test. This means that the W6100 is sending an ARP Announcement, in this case IPCONF will not be set if someone sends an ARP probe (Sender IP=0.0.0.0).

Not sure I got your conclusion on the results. Does this test help or not? If you have got some IP address from DHCP, you need to check using ARP that there’s no one else with this IP address. You send ARP request/probe, and if there’s a reply with IP address in the response matching yours in SIPR, IPCONF must be set → meaning IP address conflict.

### Reply 32 by tom3, 2022-08-25

This test helped a little to deduce the set condition of the IPCONF bit, but it fell short of my hopes.

It seems that the IPCONF bit cannot be used for conflict detection during ARP probes, so I think that unless the MAC and IP addresses of the Sender/Target of the received ARP request are indicated in some register, the firmware cannot determine conflicts.

thanks,

### Reply 33 by lawrence, 2022-08-29

Hi, [@tom3](https://maker.wiznet.io/u/tom3)

Thank you for sharing your test case and hope WIZnet’s reply is not too late.
Soon tech supper team will reply your email.
Navertherless, I would like to descibe IP conflict on WIZnet Core.

On WIZnet Core, IP conflict only considered in ARP process. And only compare pear source IP & SIPR.
Even W6100 received assigned IP from DHCP server, if SIPR is not set as it, it is still 0.0.0.0.
At that time, pear (set 0.0.0.0) sends broadcase packet to DHCP server.
Then W6100 received the packet, W6100 can check IP conflict.
It is only the basic process in Chip, there are so many exception situation happened. So may we can communicate via email with more details.

[@Eugeny](https://maker.wiznet.io/u/eugeny) [@Welocs](https://maker.wiznet.io/u/welocs) , appreciate so much your answers! always it is so helpful.

[@Welocs](https://maker.wiznet.io/u/welocs) unforfunately, IP Conflict is not adopted to MAC address(uniqe MAC is strongly recommaned to all users) but because there are so many flexible way on network, WIZnet chip has advantage and careful points.

[@Eugeny](https://maker.wiznet.io/u/eugeny) [@Welocs](https://maker.wiznet.io/u/welocs) If any points I missed, please let me know. ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12)

### Reply 34 by tom3, 2022-08-29 (in reply to reply 33)

Hi, [@lawrence](https://forum.wiznet.io/u/lawrence)
Thanks for your advice.

The source IP address of all clients is 0.0.0.0 while all DHCP clients are performing the initial DHCP sequence. So it makes sense that a conflict is detected (IPCONF=1). I tried many times to start the two devices almost at the same time and was able to confirm the fact that IPCONF=1.

After getting an IP address, it clears the IPCONF bit, sends an ARP probe, and waits for someone’s ARP request or response to check for IP address conflicts (RFC5227 section 2.1.1).
At this time, we leave SIPR at 0.0.0.0 in order to send ARP probes.
If someone sends an ARP “reply” while waiting, the W6100 will receive it and set the ARP4 bit in the SLIR register as described in the datasheet.
Instead, the IPCONF bit may or may not be set when someone’s ARP “probe” is received.
First, I would like to know the set condition of IPCONF during this conflict detection process.
In our experiments, the IPCONF bit was also set when someone else probed a target IP address different from the W6100. Since there is no actual conflict, I would like IPCONF to be in a clear state, but please let me know if there is a workaround.

Second, I would like to know if there are any other procedures for using the W6100 to perform the detection process described in RFC5227 section 2.1.1 “In addition, …” paragraph.

Thanks,

### Reply 35 by Eugeny, 2022-08-29

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> At this time, we leave SIPR at 0.0.0.0 in order to send ARP probes.

Why? ARPs are L2 packets, and IP address does not have any effect on them at this level. As I said before, as soon as you get IP address from DHCP, it must be logical to set this address into W6100’s SIPR, and then send ARP. Otherwise it seems anyone sending IP packet with IP address 0.0.0.0 will cause this IPCONF bit to be set.

### Reply 36 by tom3, 2022-08-29

Thank you.

I wanted to send an ARP “Probe” after getting an IP address from DHCP, so I needed the ARP’s Sender IP address field to be 0.0.0.0. This is what is written at the beginning of section 2.1.1 of RFC5227.

Unfortunately, the W6100 datasheet section 6.6.1 does not say how to set the Sender IP address. As a result of experimentation, this Sender IP address field could be set in the SIPR register, so we left the SIPR at 0.0.0.0 and sent the ARP request.
After confirming that there is no conflict after sending ARP “Probe” 3 times, I store the obtained IP address in SIPR and send ARP “Announcement” 2 times. This is what is written in section 2.3 of RFC5227.

Should I first ask WIZnet how to set the Sender IP field of the ARP packet?

### Reply 37 by Eugeny, 2022-08-29

![](https://avatars.discourse-cdn.com/v4/letter/t/bc8723/48.png) tom3:

> This is what is written at the beginning of section 2.1.1 of RFC5227.

RFC says

> The ‘sender IP address’ field MUST be set to all zeroes; this is to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host.

It is effective in case W6100 puts its SIPR as sender IP address into the ARP packet. Does it? Did you check?

### Reply 38 by tom3, 2022-08-30

Thank you for reply.

Eugeny:

> It is effective in case W6100 puts its SIPR as sender IP address into the ARP packet. Does it? Did you check?

Yes.
Sending ARP with the code below will send the packet shown in packet #5 in the image.
This code intentionally sets SIPR to 1.2.3.4. Setting this part to 0.0.0.0 will send an “ARP Probe” packet.
However, this is not written in the datasheet.

```
uint8_t sip[4]={1,2,3,4};
NETUNLOCK();
setSIPR(sip);//set SIPR=1.2.3.4 for Sender IP
NETLOCK();
setSLDIP4R(OfferedIp);//set SLDIP4R for Target IP
setSLCR(SLCR_ARP4);//Send ARP Probe
```

[![SenderIPAddress](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/b/b93520ed8a2ca9abc4a190ebdc8983cde1422e32.gif) SenderIPAddress816×677 73.9 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/b/b93520ed8a2ca9abc4a190ebdc8983cde1422e32.gif)

Best regards,

### Reply 39 by Eugeny, 2022-08-30

So APR differs with ARP probe by this field: probe is performed by “unnamed” requestor, this ARP on the last picture you provided is performed by very specific requestor.
Let’s put being super correct and RFC5227-compliant aside, if you perform ARP with SIPR set to DHCP obtained IP address, will it cause correct IPCONF flag operation or not?

Let’s look at your problem from different angle - why do you need ARP probes at all?

I did not read RFC, and suspect ARP probes are useful for:

- network troubleshooting;

- network cracking or administration;

- if network is non-manageable and each host has to select IP address by itself.

In your case you have DHCP server on the line, which is managing the network. In this case, when you obtain IP address from DHCP server, you will do virtue to the network and its controllers setting IP address to obtained and publicly declare that now you have it. In case someone on the network will reply with the same IP address, network controller receives it and raises red flag that address being leased by DHCP is already used, most probably, by malicious node. Thus doing “defined” ARP instead of “unnamed” ARP probe should be good for managed networks.

### Reply 40 by lawrence, 2022-08-31

Hi [@tom3](https://maker.wiznet.io/u/tom3)

Sorry for the information about setting IP during DHCP process.

Could you check DHCP application WIZnet offers as official library?

![](https://github.githubassets.com/favicons/favicon.svg) [github.com](https://github.com/Wiznet/ioLibrary_Driver/tree/master/Internet/DHCP)

### [ioLibrary_Driver/Internet/DHCP at master · Wiznet/ioLibrary_Driver](https://github.com/Wiznet/ioLibrary_Driver/tree/master/Internet/DHCP)

[master/Internet/DHCP](https://github.com/Wiznet/ioLibrary_Driver/tree/master/Internet/DHCP)

ioLibrary_Driver can be used for the application design of WIZnet TCP/IP chips as W5500, W5300, W5200, W5100 W5100S.

I know you can program DHCP client examples. If you want to refer other DHCP process, like recovering, reassigning, or releasing,… , it will be helpful example.

### Reply 41 by tom3, 2022-09-01

Thank you for the advice.

Eugeny:

> Let’s put being super correct and RFC5227-compliant aside, if you perform ARP with SIPR set to DHCP obtained IP address, will it cause correct IPCONF flag operation or not?

I have tested this before and again tested setting the leased IP address to SIPR.

The results were good, except that the W6100 did not output an ARP Probe and could not detect a conflict when receiving another device’s ARP Probe.

This ARP announcement is described in section 2.3 of the RFC, which I also implemented after processing the ARP Probe.
I wanted to do the probing before setting the IP address in SIPR, as described in the beginning of section 2.1 of the RFC, but the IPCONF bit was set, which I did not expect, so I asked in this forum.
This is to make myself safer to boot if the same IP address is leased (e.g. power failure recovery) to multiple devices at the same time due to multiple DHCP servers running or a misconfiguration of the DHCP server.

Thanks,

### Reply 42 by tom3, 2022-09-01

Thanks for the code example.

I was referring to a slightly older version of this code.
It seems that the following sendto() call in the check_DHCP_leasedIP() function in dhcp.c sends the ARP Probe.

```
	// IP conflict detection : ARP request - ARP reply
	// Broadcasting ARP Request for check the IP conflict using UDP sendto() function
	ret = sendto(DHCP_SOCKET, (uint8_t *)"CHECK_IP_CONFLICT", 17, DHCP_allocated_ip, 5000);
```

The code is able to detect a conflict by receiving an ARP “Response” from the other device after the W6100 sends the ARP Probe.
Unfortunately, however, this code does not receive the ARP “Probe” sent by the other device after the W6100 sends the ARP Probe.

If someone’s ARP Probe is received after the sendto() run, the W6100’s IPCONF bit is set, but there seems to be no processing of this bit.
Furthermore, the W6100 also sets the IPCONF bit when it receives a probing packet to another IP address. Because of this, I am unable to determine if there is an IP address conflict.
This is the same behavior as in my previous tests.
Please let me know if there is any workaround for this issue.

I digress
After executing this sendto(), if there is a conflicting device, a packet with a payload containing “CHECK_IP_CONFLICT” bytes will be sent. Is this a W6100 specific phenomenon (W5100 does not send)?
I want to prevent strange packets from being sent out to the LAN, so I thought it would be more appropriate to run setSLCR(SLCR_ARP4) instead of sendto().

Thanks,

---

Source: https://maker.wiznet.io/forum/14617