Hi Glenn, Would it work to just send me your compiled tcpborphserver3 to replace the one I have?
Dave MacMahon suggested setting the ARP table statically, but his example uses Ruby to interface with Katcp. Is there an example out there to do that in Python? Regards, Dale On Fri, Jun 7, 2013 at 2:56 PM, Dale Gary <[email protected]> wrote: > Hi Glenn, > > Would it work to just send me your compiled tcpborphserver3 to replace > the one I have? > > Dave MacMahon suggested setting the ARP table statically, but his > example uses Ruby to interface with Katcp. Is there an example out > there to do that in Python? > > Regards, > Dale > > Sent from my iPhone > On Jun 7, 2013, at 6:47 AM, G Jones <[email protected]> wrote: > > > It requires recompiling tcpborphserver3. So I cloned the ska-sa/katcp > > directory into the /boffiles directory on the ROACH 2, hacked the > > source, built it on the ROACH 2 (which requires mounting the > > filesystem rw so you can apt-get the libz package and perhaps > > another), and then run that version of tcpborphserver3. > > > > Glenn > > > > On Fri, Jun 7, 2013 at 9:45 AM, Gary, Dale E. <[email protected]> > wrote: > >> Hi Glenn, > >> > >> I recalled your original messages, and just located them again. There > it > >> says you were going to disable burst checking. How does one do that? > We do > >> not have a BEE2 on the network, but it is the main LAN with a lot of > devices > >> on it, so this could be our problem. > >> > >> Thanks, > >> Dale > >> > >> > >> On Fri, Jun 7, 2013 at 1:23 PM, G Jones <[email protected]> > wrote: > >>> > >>> H Dale, > >>> Do you have a lot of other ARP traffic on the network (from a BEE2 for > >>> example?) We ran into an issue where the current implementation of > >>> tcpborphserver3 (which does all of the tgtap stuff; there is no > >>> separate process for it now) will not send enough ARP requests to > >>> populate it's ARP table if there is significant other ARP traffic on > >>> the network. This is an optimization for situations where you have a > >>> large number of ROACH2s on a network to avoid being overwhelmed with > >>> ARP broadcasts. However, it also means it flat out doesn't work if you > >>> have a BEE2 on the network. If this sounds like your problem (try > >>> sniffing the network and see what's flowing around), I'll try to dig > >>> up old emails with the solution we concocted. It should be in the > >>> casper list archive. > >>> > >>> Glenn > >>> > >>> On Fri, Jun 7, 2013 at 9:14 AM, Gary, Dale E. <[email protected]> > >>> wrote: > >>>> Hi All, > >>>> > >>>> We previously were successful in setting up the 10gbe core for ROACH1 > >>>> using > >>>> tap_start, which I believe resulted in a process tgtap appearing in > the > >>>> ROACH. > >>>> > >>>> I am using the same method for ROACH2 (using the latest ROACH2 rev 2 > >>>> file > >>>> system loaded via netboot), and there is no reported error, but the > ARP > >>>> table does not contain the MAC address for the destination IP address, > >>>> and > >>>> when I check the processes running on the ROACH2 I do not see tgtap. > >>>> > >>>> Has the procedure changed at all, or is there something I am doing > >>>> wrong? > >>>> > >>>> Thanks, > >>>> Dale > >>>> > >>>> Here are the relevant katcp python calls we are using: > >>>> > >>>> # Configuration Parameters for 10 GbE ports. > >>>> dest_ip = 10 * ( 2 ** 24 ) + 101 # DPP_IP 10.0.0.101 > >>>> fabric_port = 60000 > >>>> source_ip = 10 * ( 2 ** 24) + 11 # ROACH1, SLOT 0, CHANNEL 0: > 10.0.0.11 > >>>> mac_base = (2 << 40) + (2 << 32) > >>>> > >>>> # Configuring 10 Gbe core Tx_P > >>>> print 'Configuring transmitter core...', > >>>> sys.stdout.flush() > >>>> fpga.tap_start('tapP1',tx_core_name, mac_base + source_ip, > >>>> source_ip, > >>>> fabric_port) > >>>> print 'done' > >>>> > >>>> print 'Setting-up DPP IP and port information...', > >>>> sys.stdout.flush() > >>>> fpga.wordwrite('f_ctrl_dpp_ip', 0, hex(dest_ip)) > >>>> fpga.wordwrite('f_ctrl_dpp_port', 0, hex(fabric_port)) > >>>> print 'done' > >>>> > >>>> # Reset 10 GbE cores > >>>> print 'Resetting 10 GbE core...', > >>>> sys.stdout.flush() > >>>> fpga.wordwrite('f_ctrl_rst', 0, hex(1)) > >>>> fpga.wordwrite('f_ctrl_rst', 0, hex(0)) > >>>> print 'done' > >>>> > >>>> time.sleep(2) > >>>> > >>>> # Print ARP table > >>>> print '\n===============================\n' > >>>> print '10GbE Transmitter core details:' > >>>> print '\n===============================\n' > >>>> print "Note that for some IP address values, only the lower 8 bits > >>>> are > >>>> valid!" > >>>> fpga.print_10gbe_core_details( tx_core_name, arp=True ) > >>>> > >>>> This ARP table is correct for the source_ip, but all FF for the MAC > >>>> address > >>>> of the dest_ip. > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> >
