Correction: this is indeed a problem, but my description is not quite correct. It seems the "poll interval" is 10 ms and the burst logic looks to see if there's more than one packet in a poll inteval. The BEE2 on the network is sending ARP packets every ~4ms so a burst is perpetually detected. So I need to increase the number of packets per poling itnerval to count as a burst. I'm just going to disable the burst checking for now.
Glenn On Tue, Dec 18, 2012 at 2:08 PM, G Jones <glenn.calt...@gmail.com> wrote: > 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 <glenn.calt...@gmail.com> 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 <glenn.calt...@gmail.com> 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
