# NIC ping gives no output even with disabled firewall



## Beeblebrox (Oct 15, 2013)

I seem to have run into a network problem - I can't ping (from host or client) either of two NICs I have installed on the system. I can ping to the outside from the host. I have disabled all services (HTTP, SSH, etc.) and pf for debugging. My hardware:

```
re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfebfbc00-0xfebfbcff irq 22 at device 7.0 on pci4
re0: Chip rev. 0x10000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow

re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 17 at device 0.0 on pci6
re1: Using 1 MSI-X message
re1: Chip rev. 0x2c800000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus1
rgephy1:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
```
kldstat is showing these modules as loaded: 136 re/miibus, 135 pci/re
`$ ifconfig`

```
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 ab:cd:ef:12:34:56
	inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
re1: 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 ab:cd:ef:12:34:57
	inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
```
Pinging just hangs with no output:

```
# ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10): 56 data bytes
^C
--- 192.168.1.10 ping statistics ---
23 packets transmitted, 0 packets received, 100.0% packet loss
```
Network traffic from host to outside works, but some of the traffic from clients to host is having problems.
*EDIT:* The NICs have static IP assigned. If I request IP from DHCP by dhclient, re0 responds to pinging for the DHCP-assigned IP. IP's assigned in /etc/rc.conf by:

```
ifconfig_re0="inet 192.168.1.10/24"
ifconfig_re1="inet 192.168.2.1/24"
defaultrouter="192.168.1.1"
```


----------



## J65nko (Oct 15, 2013)

How does the `#  netstat -rn -f inet` output look like?


----------



## Beeblebrox (Oct 15, 2013)

The ARP table looks normal to me:

```
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGS         2   111965    re0
127.0.0.1          link#10            UH          0       13    lo0
192.168.1.0/24     link#5             U           0       11    re0
192.168.1.10       link#5             UHS         0       15    lo0
192.168.2.0/24     link#7             U           0        5    re1
192.168.2.1        link#7             UHS         0       82    lo0
```


----------



## SirDice (Oct 15, 2013)

Beeblebrox said:
			
		

> ARP Table looks normal to me:


That's not your ARP table, that's your routing table. The ARP table contains the relations between MAC and IP addresses.


----------



## Beeblebrox (Oct 15, 2013)

Yep, a slip-up after a long night of heavy drinking


----------



## Beeblebrox (Oct 16, 2013)

More foolishness:

If I remove the assigned IP addresses and then add it back with:
`# ifconfig re0 192.168.1.10 delete`
`# ifconfig re0 192.168.1.10/24`
Then the internal ping from the host to re0 starts to respond. I get the same result when modifying re1. Restarting the network as a service does NOT give the same result. However, doing this gives a different problem - I can ping the gateway router but not to the outside. So I do:

```
[CMD]# route add default gw 192.168.1.1 re0[/CMD]
route: writing to routing socket: Network is unreachable
add net default: gateway gw fib 0: Network is unreachable
```


```
[CMD]# netstat -rn[/CMD]
Destination        Gateway            Flags    Refs      Use  Netif Expire
127.0.0.1          link#10            UH          0      291    lo0
192.168.1.0/24     link#5             U           2       27    re0
192.168.1.10       link#5             UHS         0        9    lo0
192.168.2.0/24     link#7             U           0        2    re1
192.168.2.1        link#7             UHS         0        2    lo0
```


----------



## usdmatt (Oct 16, 2013)

I can't see any reason why the interfaces should not work on reboot, but start working after re-applying the addresses. However, I'm not certain about the command you used to re-add the default gateway. Can you just try:


```
# route add default 192.168.1.1
```


----------



## SirDice (Oct 16, 2013)

Is there a difference between a cold boot (turn it completely off and back on again) and a warm boot (after a reboot)? It may be that the card is left in some weird state when it reboots.


----------



## Beeblebrox (Oct 17, 2013)

I just had an idea - could this be an IPv6 setting problem? As my /etc/src.conf has:

```
WITHOUT_INET6= yes
WITHOUT_INET6_SUPPORT= yes
```
/etc/rc.conf has:

```
ipv6_activate_all_interfaces="NO"       #ipv6_enable="NO"
ip6addrctl_enable="NO"
```
/boot/loader.conf has:

```
ipv6_load="NO"
```

@usdmatt: I'm not sure these are the correct IPv6 disable flags and I should first try by correcting these disable codes maybe?

EDIT: @SirDice: I removed the PCI NIC card for debug and only the mo_ther_bo_ard_-embedded NIC remained - the same result. Cold/warm reboot makes no difference.


----------



## J65nko (Oct 18, 2013)

If you run 9-STABLE, as stated in your signature, you could boot an  install CD/stick with a different version of FreeBSD, select the LiveCD option. Then you can verify whether this weird behaviour is FreeBSD version dependent or not.


----------



## Beeblebrox (Oct 18, 2013)

Last night I started a completely clean (deleted /usr/obj/src) re-build of world and kernel. Installed and tried this morning. Problem persists.

`# route add default 192.168.1.1`
Worked and both NICs ping after manually re-assigning same IP numbers.


----------



## J65nko (Oct 18, 2013)

Beeblebrox said:
			
		

> Last night I started a completely clean (deleted /usr/obj/src) re-build of world and kernel. Installed and tried this morning. Problem persists.



This is not what I suggested  We also are not sure which FreeBSD version (`uname -a`) you are using


----------



## Beeblebrox (Oct 18, 2013)

> not sure which FreeBSD version you are using


My signature info is valid



> This is not what I suggested


Yes, and I chose to disregard it, for the reason that it's impractical to implement:

The problem is limited to static-assigned IP's from /etc/rc.conf, as evidenced in dhclient obtained IP's and manually re-assigned IP's responding to pings.
Configuring a static-assigned IP to a liveCD/live-USB, or failing that, having to install 10-current on a new HDD partition so as to define the same static IP's is way more trouble than what I'm willing to go through.
It would be easier to connect my HDD's to a different motherboard or attach NICs from different manufacturers as a method to test the if_re driver rather than slog through the liveCD business (which is what I plan to do next).
At least that's how I see it...


----------



## Beeblebrox (Nov 4, 2013)

I tested the Realtek cards on a Linux distro and obtained similar error problems; something like: 
	
	



```
cannot assign IP address to that interface
```
 So I decided to send the Motherboard in for warranty testing. The results came back, and both the NIC on the mainboard and the PCI NIC are clean.

That, plus this thread from today, leads me to conclude erroneous driver for this NIC.


----------

