1G eth UDP / IP Stack

Hi, i think i found a little bug in arp_RX.vhd, triggered by a change done 2013-01-14 assuming the comment is correct.

BUG: Changing the last byte of our_ip-value in testbench (8 instead of 9 for example) will also trigger an ARP-reply due to a bug in ARP_RX.vhd

REASON: When the incoming ARP is processed in rx_combinatorial (-- RX FSM) of mentioned vhd-file the current data_in is parsed depending on rx_count. The first check condition was changed from rx_count = 42 to 41 resulting in not using the second if-clause (not_our_arp()), which checks for correct last byte of our_ip when count = 41.

SOLUTION: Change order of if-clauses to first do a check with not_our_arp() and after that place the check for rx_count = 41. If the not_our_arp()-check fails the error condition is raised, if the check succeeds, the next if-clause will be choosen, due to rx_count=41, and the ARP is processed.

I'm quite new to the project, so it might be that my solution will have side-effects, which I didn't noticed so far.

I think you are right! as it stands, a received broadcast ARP request to an other IP address on the same sub net (assuming net mask is 255.255.255.0) would trigger an ARP reply. I had changed the rx_count to 41 check because I was receiving ARP packets that where exactly 42bytes long, therefore never triggering the rx_count = 42 check. my bad...

I'll test the solution you provided shortly TB