> Wireshark sees an ARP being broadcasted saying "Who has 100.1.255.255? Tell 100.1.3.100".
> 100.1.3.100 is my board's address...it's the one sending the packet. my PC is just supposed to receive it.
The ARP is being sent by 00:cf:52:53:54:55 ("RSTU" in last 4 bytes). That is a more trustworthy identification of the source than the IP address.
So the board is sending those ARPs. That is because the board doesn't "know" that 100.1.255.255 is a broadcast address.
So either the IP address configuration is wrong, the IP stack is buggy or you're not driving it properly.
I have no idea how Interniche Lite 7 works (and don't want to, so don't ask me 
, but here are all the different ways it might be implemented. You'll have to pattern-match it against these and work out what is wrong.
In general, when the IP stack goes to send a packet it has to check the destination IP address to see (a) which interface to send it out (if there's more than one, unlikely in this case), (b) whether the destination address is on the local network, or whether it is "somewhere else" and has to be sent to a router instead, and then for "local and router" it has to find the Ethernet address of the local device or the local router. Then it has to work out if the address is a broadcast. This is the bit that is going wrong. As an added complexity, it might be a Multicast destination (also not likely to be supported).
1 - One way is to check the address against the subnet mask. If the node part is all-ones it is a broadcast. For backwards-compatibility it might also check against all-zeros which is a very old broadcast address.
2 - Another way is to have a "broadcast address" separately configured for the port. The code then compares against that fixed IP address.
3 - Another way is to "seed" the ARP Cache with a static entry mapping "100.1.255.255" to "ff:ff:ff:ff:ff:ff". That way the code that handles mapping an IP address to an Ethernet address doesn't have to do anything special - it finds the broadcast one the same way it finds a normal one.
4 - Another way is to require the Application code to send a flag through to the stack stating "I want this to be broadcast".
So check the subnet mask (again), check if there's an "all ones, all zeros or both" Broadcast option, check if there's a configured Broadcast address and if there's a need for the App to specify broadcasts. Then add some code to dump the ARP cache in case it is meant to be seeded, and if so, seeded with what.
Or (like I should have done), search this forum first. This looks interesting:
Re: Subnetting with NicheLite 2010-03-01 12:22 PM ... There are serious problems with the way broadcasts are handled, resulting in only the all-bits set broadcast working as a side effect of buggy code that fails to handle the subnet broadcast. ... but routing with a router is still dead, with or without DHCP turned on. The comment at the top of the file, "no real routing", says a lot, I had more expectations for NicheLite than it's going to deliver. I'm going to drop back, document the limitation to the end users, and maybe lock out the ability for them to set a subnetmask and gateway.
That doesn't look at all good. It implies that this code has thirty-year-old bugs in it if it can't handle broadcasts and if it still has "subnet confusion" (CIDR got rid of that in 1993!). The code isn't 30 years old, just that new programmers keep making 30-year-old mistakes .
The "doesn't do routing" comment could mean that it only works as a host (and can't route between multiple interfaces, which is find) or it might be more serious and mean that it can't send to gateways properly.
It only needs one line of code in there that says "if destination address and mask matches broadcast then ethernet address is broadcast, else do the ARP thing" to handle broadcasts in this case. You could probably add that yourself.
It looks like it might only support simple host-to-host messages, and then only on the one network too. It might rely on DHCP (or not work with DHCP).
