W6100 IPCONF is set by other device's ARP Probe

Question

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,

Eugeny · Answer

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

Eugeny · Answer

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?

tom3 · Answer

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,

Eugeny · Answer

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.

tom3 · Answer

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,

tom3 · Answer

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

tom3 · Answer

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…

Eugeny · Answer

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…

tom3 · Answer

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,

Eugeny · Answer

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

tom3 · Answer

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

Welocs · Answer

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…

Eugeny · Answer

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. Welocs: You are right, sadly theres no information about when the IPCONF-bit is set. W5500 datasheet: 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: 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: 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…

Welocs · Answer

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

Eugeny · Answer

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.

Welocs · Answer

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

Eugeny · Answer

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 Then it seems that chip does not work as expected… @tom3 try to contact WIZnet support using email and point them to this thread. Optionally write to sales address to ensure to get attention.

Welocs · Answer

@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 do you have the possibility to try this error out this some W5500 or W5100 chips? Would be interesting. Regards

Welocs · Answer

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.

Welocs · Answer

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

Eugeny · Answer

@Welocs I have W5100, but can not commit to testing anything shortly. W5500 and W5100 do not have info about these 60 byte padding. 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 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 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.

Welocs · Answer

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!

Welocs · Answer

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

tom3 · Answer

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,

Welocs · Answer

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

tom3 · Answer

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,

Eugeny · Answer

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.

tom3 · Answer

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,

lawrence · Answer

Hi, @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 @Welocs , appreciate so much your answers! always it is so helpful. @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 @Welocs If any points I missed, please let me know.

Eugeny · Answer

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.

tom3 · Answer

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?

Eugeny · Answer

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?

tom3 · Answer

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 SenderIPAddress816×677 73.9 KB Best regards,

Eugeny · Answer

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.

lawrence · Answer

Hi @tom3 Sorry for the information about setting IP during DHCP process. Could you check DHCP application WIZnet offers as official library? github.com ioLibrary_Driver/Internet/DHCP at master · Wiznet/ioLibrary_Driver 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.

tom3 · Answer

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,

tom3 · Answer

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,