@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.
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.
@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.
@Welocs I have W5100, but can not commit to testing anything shortly. W5500 and W5100 do not have info about these 60 byte padding.
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.
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.
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!
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.
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…
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.
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.
It also detects correctly, if you just try to ARP some other IP.
I hope you’ll get an answer. Please post, if so!
I just wrote them via the contact formular (Company → Contact us)
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)
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.
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.
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.
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.
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.
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?
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?
Sending ARP with the code below will send the packet shown in packet #5 in the image.
This code intentionally sets SIPR to 126.96.36.199. Setting this part to 0.0.0.0 will send an “ARP Probe” packet.
However, this is not written in the datasheet.
setSIPR(sip);//set SIPR=188.8.131.52 for Sender IP
setSLDIP4R(OfferedIp);//set SLDIP4R for Target IP
setSLCR(SLCR_ARP4);//Send ARP Probe
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 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.