if_re has a bug If you set ether address in ifconfig, ping fails, but after, if you change interface to promiscuous mode ping become work. re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC> re0@pci0:2:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet How-To-Repeat: /etc/rc.conf ifconfig_re0="inet 192.168.0.2/24" ping works ifconfig_re0="inet 192.168.0.2/24" ifconfig_re0_alias0="ether 00:02:1a:2b:3c:4d" ping fails tcpdump -i re0 ping works until Ctrl+C :)
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
State Changed From-To: open->feedback I think the correct way to change station address is to use /etc/start_if.<interface>. For this case, the filename would be /etc/start_if.re0 and its contents could be like the following. #!/bin/sh /sbin/ifconfig $1 ether 00:02:1a:2b:3c:4d See rc.conf(5) for more details.
Responsible Changed From-To: freebsd-net->yongari Grab.
I have the same network card and am also having trouble with this bug. I also tried disabling all offloads (ifconfig re1 -rxcsum -txcsum -vlanmtu -vlanhwtag -vlanhwcsum -wol) but that did not help. Here is my card: re1@pci0:3:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet If I change MAC address, card only works in promiscuous mode. I have tested this on both 10.1 and 11.0-CURRENT.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
If I change MAC address, card only works in promiscuous mode. I have tested this on 11.2 D-Link DGE-560T (re0) on FreeBSD 11.2-RELEASE-p4: "ether" work only with "promisc" rc.conf: ifconfig_re0="DHCP ether 00:30:4f:xx:xx:xx promisc" kernel: re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0xf0104000-0xf0104fff,0xf0100000-0xf0103fff irq 17 at device 0.0 on pci1 ifconfig: re0: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
Still, doesn't work even on 13-STABLE. I'm using lagg(4) in failover mode with other other adapter (bge(4)) as master, and this changes mac address of backup (re(4)). Without promiscuous mode on re interface this setup doesn't work. So, I finished with this setup and using promiscuous mode (which normally I shouldn't): dream#/usr/ports>ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> ether 00:10:18:30:44:a4 inet 10.12.41.20 netmask 0xffffff00 broadcast 10.12.41.255 laggproto failover lagghash l2,l3,l4 laggport: bge0 flags=5<MASTER,ACTIVE> laggport: re0 flags=0<> groups: lagg media: Ethernet autoselect status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> dream#/usr/ports>ifconfig bge0 bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> ether 00:10:18:30:44:a4 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> dream#/usr/ports>ifconfig re0 re0: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC> metric 0 mtu 1500 options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> ether 00:10:18:30:44:a4 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
*** Bug 197511 has been marked as a duplicate of this bug. ***
^Triage: committer's bit was taken into safekeeping some time ago. Apparently this was still a problem as of 2021-03-23.