Re: kern/54645: Netbooting over a direct cable connection is unreliable

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR kern/54645; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: jdolecek%NetBSD.org@localhost
Subject: Re: kern/54645: Netbooting over a direct cable connection is unreliable
Date: Sat, 18 Jul 2020 19:38:22 +0300

 I have now found a way to reproduce the issue using a setup that does
 not involve netbooting, which should make it easier for others to
 reproduce.  This was with a -current system of source date
 2020.07.17.21.04.14.
 
 Here's how to do it:
 
 You need two systems, the system under test (or "sut" for short) with
 at least one bnx network interface (let's call it bnx3) and a second
 system, the traffic generator (or "tg" for short) with a network
 interface of any supported type (let's call it "bge1").  The two
 interfaces are connected by a patch cable (no switch).
 
 On sut, run this script (replace bnx3 by the actual interface
 name if needed):
 
 sysctl -w net.inet.ip.dad_count=0
 ifconfig bnx3 10.89.0.1 netmask 255.255.255.0
 
 On tg, run this script (replace bge1 with the actual interface
 name if needed):
 
 sysctl -w net.inet.ip.dad_count=0
 ifconfig bge1 10.89.0.2 netmask 255.255.255.0
 while true
 do
   ifconfig bge1 down
   sleep 1
   ifconfig bge1 up
   ping -i 0.1 -c 100 10.89.0.1
 done
 
 This will run ping repeatedly.  Normally, each invocation of ping will
 report a packet loss of some 30-40% as packets are lost while the
 network interface is being configured "up", but if you are suffering
 from the bug, the packet loss will eventually jump to 100%.  This can
 take several hours.
 
 The scripts disable DAD because it slows things down, and to eliminate
 DAD as a possible cause of the bug.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost