# alc0 transfer issues



## iMil (Jul 23, 2020)

I use FreeBSD as my gateway with _pf_ as firewall / NAT. The machine has two NICs, _re0_ is connected to the Internet, and _alc0_ connected to the LAN.

Whenever I transfer data *to* the gateway, from LAN to LAN, using alc0 only, the resulting file size shown by `du -sh` is always 512B. `ls -l` in turn, shows the right size. Nevertheless, the file can't be read, `cat` for example would hang indefinitely. Like the file is opened for writing but a buffer is never emptied.
However, the gateway plays its role, as a transfer from / to the outside works perfectly and at a decent speed.
I tried ssh, NFS and netcat in both TCP and UDP mode for the latter with the same result.
Transfer *from* the gateway to the LAN works perfectly fine.

Some details:

FreeBSD newcoruscant 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64

```
alc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=83018<VLAN_MTU,VLAN_HWTAGGING,WOL_MCAST,WOL_MAGIC,LINKSTATE>
    ether d1:60:09:3c:4b:ff
    inet 192.168.0.254 netmask 0xffffff00 broadcast 192.168.0.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

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 f8:dd:12:b7:bb:c2
    inet 192.168.1.249 netmask 0xffffff00 broadcast 192.168.1.255
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

$ grep ifconfig /etc/rc.conf
ifconfig_re0="inet 192.168.1.249 netmask 255.255.255.0 -tso4 -tso6 -lro -vlanhwtso"
ifconfig_alc0="inet 192.168.0.254 netmask 255.255.255.0 -lro -tso4 -tso6 -vlanhwtso -rxcsum -txcsum -vlanhwcsum"
ifconfig_alc0_9="inet 192.168.9.254 netmask 255.255.255.0"
```
I had to add `-lro -tso4 -tso6 -vlanhwtso -rxcsum -txcsum` to the interfaces because I was bitten by a performance issue, which were fixed by disabling those features.

I did some tuning on /etc/sysctl.conf, with no effect on this issue:

```
net.inet.tcp.tso=0
net.inet.ip.redirect=0
net.inet6.ip6.redirect=0

vfs.usermount=1

# from [URL]https://calomel.org/freebsd_network_tuning.html[/URL]
net.inet.tcp.recvbuf_inc=65536    # (default 16384)
net.inet.tcp.recvbuf_max=4194304  # (default 2097152)
net.inet.tcp.recvspace=65536      # (default 65536)
net.inet.tcp.sendbuf_inc=65536    # (default 8192)
net.inet.tcp.sendbuf_max=4194304  # (default 2097152)
net.inet.tcp.sendspace=65536      # (default 32768)

net.inet.tcp.mssdflt=1460
```
Does this rings a bell for anybody? I'm out of options for now.


----------



## SirDice (Jul 23, 2020)

iMil said:


> the resulting file size shown by  du -sh is always 512B.  ls -l in turn, shows the right size.


A sparse file?


----------



## iMil (Jul 23, 2020)

SirDice said:


> A sparse file?



Hmm, not sure what you meant, the files I try to copy are regular plain files. To make things worse, the behavior is pretty erratic, right now it's acting normally...


----------



## SirDice (Jul 23, 2020)

I suspect the issue is with your filesystem, not the network card. If you transfer a file with scp(1) then it would use encryption on the network connection. If there's any network related corruption the entire connection would fail. You certainly wouldn't get a good connection and end up with a corrupted file. That just not possible. Transferring data _through_ the machine never stores anything on the local disk.



iMil said:


> I tried ssh, NFS and netcat in both TCP and UDP mode for the latter with the same result.


The only thing in common here is the local filesystem where the file gets stored.


----------

