Just look at both end connectors.  You'll see 8 copper connections, and a colored wire inside the plastic going to them.  If there are 8 wires, you're ok (assuming the cable is actually good).  If there are only four connected to pins 1,2,3 and 6 on either end it won't work on Gigabyte ethernet.  Only 100Mb and lower.

 

Just checked, definitely 8 pin.

 

For example, when you connect to your ISP there is either an automatic or manually set group of parameters that include the ip address of at least one nameserver.  The nameserver's job is to convert a name, like lime-technology.com to a corresponding ip address so that you can connect to it.  Only registered domains and hosts worldwide are in this database.  So if you wanted to add a name that represented an ip address that didn't appear in nameservice, in windows you would add the name/ip address pair in the lmhosts file so your system would know what address you meant when that name was used.

 

Likewise, computers on a local network that don't have a local nameserver to resolve names must have entries in lmhosts (windows) or /etc/hosts (unix) to resolve to an ip address.  Any time you put in an http:// or ftp:// type name you would be using either nameservice or local lookup.  If you don't have this, you can only refer to the remote connection by address, not name.

 

Note that the special syntax used for the initial connection to an unRAID server, //tower, does not use nameservice as it is a NETBIOS name, not an internet style name.

 

--Bill

 

Thanks for the explanation Bill, I think I understand the gist of it. However, if this were an lmhosts issue, wouldn't I be able to pull up the WebGUI by typing in the unRAID box's IP address even though http://tower wasn't working? At this moment neither brings up the web interface.

Thanks for the explanation Bill, I think I understand the gist of it. However, if this were an lmhosts issue, wouldn't I be able to pull up the WebGUI by typing in the unRAID box's IP address even though http://tower wasn't working? At this moment neither brings up the web interface.

 

Right, you should be able to with the IP address.

 

Let's try something else.  From your tower console, can you successfully ping the ip address of the windows machine?  'ping 192.168.0.101'  If so, it will show you receiving 64 bytes from the other end every second.

 

From your windows machine 'ping 192.168.0.102' in a DOS command window.  It will respond similarly but stops after 4 cycles, if there is basic connectivity.  Also, do an 'ipconfig' and let me know what it says.

 

--Bill

 

Sorry for the late response, I did everything before going to work this morning and nothing was good. I forget the exact error message on the unRAID box but it didn't work and from the W7 laptop all I got were timeouts. Ipconfig for the laptop's wired network adapter shows only what I mentioned earlier, an IP of 192.168.0.101 and a subnet mask of 255.255.255.0.

 

As sort of a last ditch effort kind of thing, I popped in a spare Intel gigabit PCIe NIC into the unRAID box, disabled onboard LAN in bios, plugged in the crossover cable and got indicator lights on both the laptop and the box, but when I logged in with root and checked ifconfig, the eth0 didn't even show up. Only the lo settings. I guess because the chipset isn't on the compatibility list. I can get my hands on a PRO/1000 PCIe adapter that I can try, if there's no more troubleshooting possible with that I have.

 

I'm a little frustrated. I seem to be having nothing but bad luck. 

Argh, I have NO idea why but it suddenly started working tonight! I'm finally able to access the webgui even though I changed nothing really (aside from swapping the Intel card in and out).

with a little bit of  

 

EDIT: Okay, I think I finally have everything working just right. I switched back to 4.3 so that I could use the NTFS mounting features of unMenu and copy over files from my 1.5TB Seagate NTFS drive to one of the 1.5TB Samsung drives. Once that's done, I'll create a parity drive out of the second 1.5TB Samsung drive. After a week or so of making sure the hard drives are okay, I'll format the Seagate and add it to the array.

 

I'm really happy that I can start using unRaid. Thanks so much for all the help guys!

 

I do have two last Qs though:

1. Even though I'm able to use unRAID via my laptop now, running ifconfig still gets me a humongous number for dropped on eth0. I see screenshots of others with a dropped of 0. Is this a problem?

2. What noticeable advantages would using the Intel PRO/1000 PCIe NIC have over using the onboard Realtek NIC?

For the second question, the Intel NIC's seem to have better drivers and better "durability" under heavy load.

As sort of a last ditch effort kind of thing, I popped in a spare Intel gigabit PCIe NIC into the unRAID box, disabled onboard LAN in bios, plugged in the crossover cable and got indicator lights on both the laptop and the box, but when I logged in with root and checked ifconfig, the eth0 didn't even show up. Only the lo settings. I guess because the chipset isn't on the compatibility list. I can get my hands on a PRO/1000 PCIe adapter that I can try, if there's no more troubleshooting possible with that I have.

 

Any time you do an ifconfig and eth0 doesn't even show up, it means that the driver in unRAID for that interface cannot (or is not) talking to the interface hardware.

 

--Bill

And for the first question, you should see either very low numbers in DROPPED or zero.  High values indicate either a physical cabling or switch/hub problem, a config mismatch between the interfaces, or the receiving interface unable to keep up with the transmit speed of the sender, and unable to 'pace' it with internal flow control.  High dropped numbers will significantly reduce your transfer speed, but because of the built-in error correction in the TCP part of TCP/IP you are unlikely to end up with corrupt files.  It is the sign of a problem to be concerned with, however.

 

--Bill

Argh, I have NO idea why but it suddenly started working tonight! I'm finally able to access the webgui even though I changed nothing really (aside from swapping the Intel card in and out).

with a little bit of  

 

EDIT: Okay, I think I finally have everything working just right. I switched back to 4.3 so that I could use the NTFS mounting features of unMenu and copy over files from my 1.5TB Seagate NTFS drive to one of the 1.5TB Samsung drives. Once that's done, I'll create a parity drive out of the second 1.5TB Samsung drive. After a week or so of making sure the hard drives are okay, I'll format the Seagate and add it to the array.

 

I'm really happy that I can start using unRaid. Thanks so much for all the help guys!

 

I do have two last Qs though:

1. Even though I'm able to use unRAID via my laptop now, running ifconfig still gets me a humongous number for dropped on eth0. I see screenshots of others with a dropped of 0. Is this a problem?

2. What noticeable advantages would using the Intel PRO/1000 PCIe NIC have over using the onboard Realtek NIC?

 

Did you switch to 4.3 before it began to work or after?

 

The onboard should work without any issues. That is a popular board and lots of people are using it. So, if it's not a cable issue then it's likely a board issue.

 

Peter

Any time you do an ifconfig and eth0 doesn't even show up, it means that the driver in unRAID for that interface cannot (or is not) talking to the interface hardware.

 

--Bill

 

I thought as much.

 

Did you switch to 4.3 before it began to work or after?

 

The onboard should work without any issues. That is a popular board and lots of people are using it. So, if it's not a cable issue then it's likely a board issue.

 

Peter

 

For the second question, the Intel NIC's seem to have better drivers and better "durability" under heavy load.

 

And for the first question, you should see either very low numbers in DROPPED or zero.  High values indicate either a physical cabling or switch/hub problem, a config mismatch between the interfaces, or the receiving interface unable to keep up with the transmit speed of the sender, and unable to 'pace' it with internal flow control.  High dropped numbers will significantly reduce your transfer speed, but because of the built-in error correction in the TCP part of TCP/IP you are unlikely to end up with corrupt files.  It is the sign of a problem to be concerned with, however.

 

--Bill

 

It began to work when I was still on 4.4 and I only switched to 4.3 so that I could mount a NTFS disk via unMenu. However, the high number of dropped appeared in both versions. I think I'll pick up the Intel adapter anyway and see if it removes the problem, and if it doesn't I'll know to get a better cable. There should be no problems with this card correct as I do see Intel PRO/1000 on the hardware compatibility list?

It began to work when I was still on 4.4 and I only switched to 4.3 so that I could mount a NTFS disk via unMenu. However, the high number of dropped appeared in both versions. I think I'll pick up the Intel adapter anyway and see if it removes the problem, and if it doesn't I'll know to get a better cable. There should be no problems with this card correct as I do see Intel PRO/1000 on the hardware compatibility list?

 

It sure looks like it would work, as long as you have an available PCI-e slot.  Newegg has a good return policy too, if it doesn't.

 

--Bill

Okay, there was definitely some sort of issue with the onboard NIC. I upgraded the 4.3 to both 4.4 and 4.5.6 and I kept on getting issues, either not being able to access the webgui again or seeing a huge number for dropped. Popped in the Intel NIC and everything's working like a charm. I was able to access the webgui on 4.5.6 on the first try and I have 0 dropped.  Looks like I'm all set!

 

Thanks again to everyone who helped out!

Glad to hear it's working. You are using a Gigibyte 740g motherboard, correct? That board does work (lots of people use it) so you must have received some bad hardware.

 

Peter

 

Yes, I got an unlucky 740G. Everything worked out though as I would've wanted the Intel NIC anyway.