Bug 234668

I upgraded from 11.0 to 12.0 and since then have been unable to transfer large files TO the host, though sending files from that host is unaffected.

I've attempted file xfer via scp, rsync and cifs and in each case the file transfer starts, gets a few megabytes in, and then stalls, with the bandwidth-counters wuickly falling to zero. There are no errors reported via e.g. netstat -I, and nothing in the logs. Here's the dmesg for the interface:

% cat /var/run/dmesg.boot |grep re0
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xa000-0xa0ff mem 0xd2104000-0xd2104fff,0xd2100000-0xd2103fff irq 17 at device 0.0 on pci12
re0: Using 1 MSI-X message
re0: Chip rev. 0x2c000000
re0: MAC rev. 0x00200000
miibus0: <MII bus> on re0
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: aa:bb:cc:dd:ee:ff
re0: netmap queues/slots: TX 1/256, RX 1/256
re0: link state changed to DOWN
re0: link state changed to UP

And here's ifconfig:

% ifconfig re0
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
	ether bc:5f:f4:2c:f3:2e
	inet 192.168.235.4 netmask 0xffffff00 broadcast 192.168.235.255 
	inet 192.168.235.30 netmask 0xffffffff broadcast 192.168.235.30 
	inet 192.168.235.31 netmask 0xffffffff broadcast 192.168.235.31 
	inet 192.168.235.32 netmask 0xffffffff broadcast 192.168.235.32 
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

This is the only interface on the host.

Attempted debugging:
 - removed bridge0 and tap0
 - moved physical switch ports
 - sysctl net.inet.ip.redirect=0
 - sysctl net.link.ether.inet.allow_multicast=1
 - attempted to limit bandwidth used with 'scp -l <val>', and for low values (1024, 2048, 4096...) I would get a 'stall' message after a couple of seconds, but then scp would recover and proceed normally (albeit slowly); I would terminate after 2 minutes of transfer just because I dont have all day, but saw no further stall messages. This worked fine through 131072. At '-l 262144' scp was unable to recover from the stall.