Unable to ping & access WebUI

[Windows7ge]

This is a college project I'm working on. The equipment I'm working with is a mix of my own and what the college has on hand. Due to this I'm unable to give the specifics of the equipment and I'm only able to test anything when I'm actually there.

What details I can give off memory:
The CPU is an AMD FM2+ A10 series. Exactly which I'm not sure
2x8GB DDR3 memory (speed, timing, not sure)
Motherboard: GIGABYTE GA-F2A58M-DS2 (This may have to do with the issue so I looked this up.)
6x 160GB WD BLue, 2x 500GB WD Green

I installed a Mellanox Connect X2 card in both the server and client machine.
I installed a SYBA SI-PEX40064 (so I could have a total of 8 SATA ports)

After all sorts of hardware problems (equipment the college "threw away") I got the 10Gbit network working with SMB.

As a Proof-of-Concept I would also like to implement a 1Gbit SMB client, an iSCSI client on the 1Gbit network, and demonstrate port forwarding on a router from another network to access SSH/SFTP on the server. All of these I already know how to do.

Like the title says. The servers 1Gbit NIC refuses to be recognized on the network. it shows up on the server re0 I can give it an IP through the console window on the server itself and it'll say I can access the WebUI from that IP. The only problem is I can't. No device can ping the server. The server can't ping any device.

Server IP: 192.168.0.254/24 (Static & reserved)
Clients: 192.168.0.2/24, .3/24

The server can ping it's own loopback. I tested ALL the cables, switch/router, other clients can ping each other. The 10Gbit network can ping the server but the onboard NIC just refuses to interact with any other device. The NIC is enabled in the BIOS and the NICs enabled and activity indicator LEDs say it's doing something.

I'm asking for troubleshooting ideas for when I return next week.

 

[DrKK]

If the hardware itself isn't broken, then I think the most likely culprit here is either an IP conflict, an ARP conflict/problem, or a router/firewall issue.

 

[Windows7ge]

If the hardware itself isn't broken, then I think the most likely culprit here is either an IP conflict, an ARP conflict/problem, or a router/firewall issue.

I can assure you it isn't an IP conflict and I eliminated the router in a test by going P2P which still did nothing. I don't know about ARP but even so I should still be able to ping the interface.
I haven't verified that the NIC is working outside of being able to assign it an IP & pinging 127.0.0.1.

I'm left with three theories:

The NIC has something wrong with it.
Something is wrong with FreeNAS (in general).
FreeNAS doesn't have good support with Realtek NICs.

 

[kdragon75]

FreeNAS doesn't have good support with Realtek NICs.

This is generally true as they rely on the driver to do a lot of the processing (because there cheap) and the drives are of poor quality. You may also want to check if the board has IPMI that is shared with that port and disable it.

 

[DrKK]

I don't know about ARP but even so I should still be able to ping the interface.

That's a negatory sir.

There is no "IP" address on Ethernet LAN's. There is only MAC. If the ARP is not properly resolving a given IP address, you won't be reaching (or pinging) it on the LAN in most cases.

Of course, this won't affect a loopback address, since a loopback does not require ARP resolution.

 

[Windows7ge]

This is generally true as they rely on the driver to do a lot of the processing (because there cheap) and the drives are of poor quality. You may also want to check if the board has IPMI that is shared with that port and disable it.

I can say for sure that the motherboard does not support IPMI. This is a frankenstein proof-of-concept server, desktop hardware. One action I can try taking is booting something like Ubuntu off a thumb drive, checking the interface IP and pinging it from elsewhere on the network. If it works. Something related to FreeNAS is wrong (driver likely). If it doesn't. Hardware failure.

There is no "IP" address on Ethernet LAN's. There is only MAC. If the ARP is not properly resolving a given IP address, you won't be reaching (or pinging) it on the LAN in most cases.

Informative. Would it be possible for ARP to work perfectly fine on one interface but when setting up a second not work at all? I'm uncertain if the ARP service runs as a single instance which handles resolution for all ports or if each port runs it's own instance of ARP. If the former then I would think it's running fine but then again I don't have extensive knowledge on how it works. I just understand the basics.

 

[Elliot Dierksen]

Informative. Would it be possible for ARP to work perfectly fine on one interface but when setting up a second not work at all?

The interface would be selected based on the IP routing table. Then there is an ARP table for that network although most host systems list the ARP table as a single entity.

Another area of concern is that your motherboard has a Realtek NIC which doesn't work very well with FreeNAS/FreeBSD.

Are you trying to use multiple NIC ports? I couldn't tell for sure from your original post. If so, that could be part of your problem. The way you can be sure is to look at the MAC on the FreeNAS side. This does require you to do some CLI commands.

Code:

root@freenas2:/nonexistent # ifconfig lagg1
lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
		options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
		ether e4:c7:22:84:8f:30
		inet 10.180.3.27 netmask 0xffffff00 broadcast 10.180.3.255

Note the ethernet MAC address there. Now I ping it, and then check the ARP table.

Code:

C:\Users\elliot>ping 10.180.3.27

Pinging 10.180.3.27 with 32 bytes of data:
Reply from 10.180.3.27: bytes=32 time<1ms TTL=64
Reply from 10.180.3.27: bytes=32 time<1ms TTL=64
Reply from 10.180.3.27: bytes=32 time<1ms TTL=64
Reply from 10.180.3.27: bytes=32 time<1ms TTL=64

Ping statistics for 10.180.3.27:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\elliot>arp -a | find "10.180.3.27"
  10.180.3.27		   e4-c7-22-84-8f-30	 dynamic

As you can see, the MAC addresses match. If you get a ping response but the MAC addresses are different, then you have an IP address conflict as @DrKK suggested.

 

[Windows7ge]

Another area of concern is that your motherboard has a Realtek NIC which doesn't work very well with FreeNAS/FreeBSD.

This is what I'm thinking the problem is. I have a motherboard I could bring which uses the Intel 82579V but it has no onboard video. I could make it work but it wouldn't be fun.

Are you trying to use multiple NIC ports?

I'm using multiple NIC's yes.
A 10Gbit SFP+ Mellanox Connect X2 card.
& the 1Gbit onboard

As you can see, the MAC addresses match. If you get a ping response but the MAC addresses are different, then you have an IP address conflict as @DrKK suggested.

All I get is "Destination host unreachable" from either the router or the interface I'm transmitting from so even if I did a ARP lookup the table would be empty. Any attempt to ping from the server to elsewhere acts as if the cable is disconnected. I've verified that the cable & port on the switch are in working order. I've also verified that everything is on the same subnet and there are no duplicate IP's. The router on the network when checking the client list does not see the server but does see all other clients including MAC & IP.

 

[Windows7ge]

@DrKK @kdragon75 @Elliot Dierksen
For anybody who was curious.
I replaced the motherboard with one that used an Intel NIC and instantaneously everything started working how it should have been.

Seeing as how the Realtek NIC was being recognized and 1/2 worked with IP assignment and active indicator lights I'm left to assume the issue was lack of driver support. That's my conclusion.

 

[DrKK]

Sir. We've all dealt with RealTek NICs now for many years in this community. The question is not whether or not they will generally "work", because they *do* generally work. They just are not very good---they do not have the efficiency and line speed of Intel NICs. Whatever your problem was, there was more to it than just being "RealTek NIC".

In any case, I'm glad it's solved.