Well I think I located the problem: in tcpborphserver3/tg.c The main do-while loop has a burst variable that's supposed to keep the ROACH from broadcasting ARPs if the network is busy. burst is initialized to zero at the start of the program, but from that point on, it is only incremented. The ARP "spamming" as it's called only occurs if burst < 1, so once a "burst" is detected, it will never again spam ARP packets. In our case, the network is being spammed by the BEE2 on the net and other devices, so it never gets a chance to do it's ARP broadcast.
I'll try to fix this myself, but someone more familiar with the code should look at it and decide what the right thing to do is. Glenn On Tue, Dec 18, 2012 at 1:57 PM, G Jones <[email protected]> wrote: > Looking through the tcpborphserver3 code, I saw there is a tap-info > command. When I run that I get: > > ?tap-info > #log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000 > #log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0 > #log info 2212751 raw current\_iteration\_0 > #log info 2212751 raw buffers\_arp=0/rx=0/tx=0 > #log info 2212751 raw polling\_interval\_10 > #log info 2212751 raw address\_10.17.0.64 > #log info 2212751 raw gateware\_port\_is\_60000 > #log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29 > !tap-info ok > > The 10:10:10.... MAC is a BEE2 on the network happily blasting arps as > usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like > it is receiving and interpreting ARPs OK. It's just not sending them > itself... > > Any ideas? > > Thanks, > Glenn > > On Tue, Dec 18, 2012 at 10:58 AM, G Jones <[email protected]> wrote: >> Hi, >> In the last couple of days our ROACH2's have decided to stop sending >> ARP packets after tapstart'ing. As a result, the default ARP table >> values cause all UDP packets to be sent to the broadcast MAC address >> (all F's). Any ideas what could have caused this and how to fix it? My >> best guess is that we changed uImage files a while ago to try to deal >> with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't >> rebooted until later so we didn't see the change until recently. But >> I'm not sure. >> >> The tge details look fine: >> ------------------------ >> GBE0 Configuration... >> My MAC: 02 02 0A 11 00 40 >> Gateway: 0 0 0 1 >> This IP: 10 17 0 64 >> Gateware Port: 60000 >> Fabric interface is currently: Enabled >> XAUI Status: 0000007E >> lane sync 0: 1 >> lane sync 1: 1 >> lane sync 2: 1 >> lane sync 3: 1 >> Channel bond: 1 >> XAUI PHY config: >> RX_eq_mix: A >> RX_eq_pol: 4 >> TX_pre-emph: 0 >> TX_diff_ctrl: 7 >> >> >> Thanks, >> Glenn
