Networking issues with Haswell-based Linux increase Courvoisier consumption
 

Been running my Haswell system for ~2 weeks now, using thumb drive for file transfer, which is OK for transferring a Sandy-Bridge-suitable binary and doing preliminary perforance testing, but not for ongoing Haswell-specific [= AVX2] code-dev work. I was unable to find any Linux network drivers for the builtin networking on the MSI motherboard, so our very own Scott Bardwick kindly sent me an Intel network interface card [NIC] free of charge, and he and Mike/Xyzzy helped me in my efforts to get networking up and running - unsuccessfully, hence the thread. Here is a cull of the various e-mails we exchanged:

---

o Here is the basic LAN topology [which Scott wrote up as an aid] I had running on the older Sandy Bridge-based system which previously occupied my ATX case [and which used the same Linux-install-on-SSD as I am still using]:
[code]
We have a macbook with WiFi and wired networking.
The MacBook WiFi appears to use 192.168.0.xxx network range.
The MacBook wired connection should be using 192.168.1.xxx range.

The Haswell box is wired only.
We want to wire the Haswell box to the Mac without a router, so an Ethernet cable is directly connecting the two.
The Haswell needs to be using 192.168.1.xxx to talk to the MacBook.
[/code]

---

o Intel Ethernet card install notes:

- After initial attempt to install card in pci1 slot led to no-joy, retried in pci3;
- 'lspci' shows hardware is recognized;
- 'lsmod' shows e1000e entry [= Intel NIC] as expected, but '0' in 'used by' column
- 'dmesg | grep eth0' shows the following ['renamed' entry same as 1st attempt, when card was plugged into pci1]:
[code]
e1000e 0000:02:00.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1b:21:a8:53:44
e1000e 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:02:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-005
udev[572]: renamed network interface eth0 to eth2
[/code]
As before [when card was in pci1], 'ifconfig' shows only an 8-line entry for 'loopback', no eth* stuff.

The last 'renamed' line especially is curious to me - I sense it's telling me something important, not sure what, though.

(Retrying 'dmesg | grep eth2' shows that the above line is the only one output by dmesg which refers to eth2).

Specifically, /etc/network/interfaces currently contains
[code]
allow-hotplug eth0
iface eth0 inet static
[/code]
My thought was to maybe edit that to read 'eth2' - more on that below.

---

At this point Mike suggested I download a Ubuntu image onto USB flash and try to boot from it, using its recipe to configure networking, but stopping short of anything that writes to the current hard disk. I have burned a Ubuntu boot flash and tested whether the BIOS can see that, but have not yet made the above experiment.

Rather, after changing eth0 to eth2 in my /etc/network/interfaces file, I simply booted into Debian as normal to test out that change ... and 'ifconfig' now shows the eth2 stuff above the loopback entries:
[code]
eth2 Link encap:Ethernet HWAddr 00:1b:21:a8:53:44
inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:16 Memory:f7cc0000-f7ce0000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)
[/code]
Still can't ssh to it from the macbook, though. [And yes, I checked that the ethernet cable was plugged in, and into the proper slots - on the Haswell side that means the NIC card, not the ethernet port built into the motherboard. :-]

Any help from the Linux/networking gurus is appreciated!

Can you "ping 192.168.1.102" from the Haswell box?

Not sure about this, but you could try changing the netmask to 255.255.0.0

( My [URL="http://linux.about.com/od/lna_guide/a/gdelna47t00.htm"]loopback[/URL] is inet addr:127.0.0.1 Mask:255.0.0.0 )

Hi, Paul:

[QUOTE=paulunderwood;344666]Can you "ping 192.168.1.102" from the Haswell box?[/QUOTE]
Yes.

[QUOTE]Not sure about this, but you could try changing the netmask to 255.255.0.0[/QUOTE]
Would I have to manually restart networking after editing the /etc/network/interfaces file thusly?

Not sure, but "ifdown eth2", "ifup eth2" might help.

Check out your loopback; I am pretty sure it should be 127.0.0.1

My /etc/network/interfaces:

[CODE]# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
#NetworkManager#iface eth0 inet dhcp
[/CODE]

Maybe yours should say "eth2"

"/etc/init.d/networking restart" won't do any harm :smile:

Can you "ssh 192.168.1.102" from the Haswell? This will tell you sshd is installed and running.

[QUOTE=paulunderwood;344674]Not sure, but "ifdown eth2", "ifup eth2" might help.[/QUOTE]
'ifup' gives 'interface eth2 already configured'

[QUOTE]Check out your loopback; I am pretty sure it should be 127.0.0.1[/QUOTE]
Whoops - I mis-copied that one ... it is indeed 127.0.0.1 according to ifconfig. [OP edited accordingly]

[QUOTE]My /etc/network/interfaces:

[CODE]# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
#NetworkManager#iface eth0 inet dhcp
[/CODE]

Maybe yours should say "eth2"[/QUOTE]
Both the 'hotplug' and 'iface ... static' entries in my interface file use 'eth2'.

[QUOTE=paulunderwood;344680]Can you "ssh 192.168.1.102" from the Haswell? This will tell you sshd is installed and running.[/QUOTE]
Yep - after the obligatory first-ssh-attempt 'authenticity if host [blah] can't be established' warning, I am able to login to myself successfully, or something.

[QUOTE]"/etc/init.d/networking restart" won't do any harm :smile:[/QUOTE]
OK, just did that - ping/ssh-to-self still OK, connect-from-outside still no-go.

One thing I notice - during all the above, I saw none of the LEDs on the port of the NIC flash ... tried unplug/replug cable, nothing. But presumably the card is active, otherwise none of the above stuff would work, right?

Since the loopback stuff if OK [typo by me in my OP being the only bug], is the next-thing-to-try changing the netmask as you suggested?

[QUOTE=ewmayer]

One thing I notice - during all the above, I saw none of the LEDs on the port of the NIC flash ... tried unplug/replug cable, nothing. But presumably the card is active, otherwise none of the above stuff would work, right?

Since the loopback stuff if OK [typo by me in my OP being the only bug], is the next-thing-to-try changing the netmask as you suggested?[/QUOTE]

Hmm my NIC sockets light up when I plug in a cable.

Yeah, the subnet mask trick might work, but is a bit perplexing if the wired socket of the MacBook is on 192.168.1.xxx.

To restart networking, as root type:

[FONT="Courier New"]/etc/init.d/networking restart[/FONT]

[QUOTE=Xyzzy;344694]To restart networking, as root type:

[FONT="Courier New"]/etc/init.d/networking restart[/FONT][/QUOTE]

Yeah - Paul already suggested that ... but just restarted for the 2nd time, after editing netmask to 255.255.0.0 in the interfaces file. Self-ping again works, no joy from outside.

Gotta get some actual algo work done ... let's sleep on it, thanks for the suggestions!

I guess you would have to change the netmask on the MacBook too.

Make sure the cable works too.

[QUOTE=paulunderwood;344697]I guess you would have to change the netmask on the MacBook too.

Make sure the cable works too.[/QUOTE]

While trying the first, I noticed a 'cable unplugged' note in the mac's network-setup dialog ... that led me to discover the lack-of-LED cause, which is that the NIC's cable connector is bad - I have to manually jam the cable plug into the connector hard for the LEDs to come on and the above dialog's physical-connection-status message to change to the desired 'connected'.

[I say the NIC connector because the same cable worked just fine with the old mobo ... let's just say 'connection to the outside world is dodgy'.]

Anyhoo, even with one hand jamming the cable in while the other types 'shh...' ... no joy. Also reverted the netmasks on both sides to the previous values of 255.255.255.0 and retried (again keeping one eye on the connected-or-not status line in the macbook's dialog to make sure it read 'connected') - still nothing. Bloody hell.

BTW, I still have no idea what that 'rename eth0 to eth2' business is all about - can anyone explain why the old-setup eth0 wasn't OK?

Dodgy cable, eh? Keep an eye on those LEDs. :smile:

I don't know why eth0 gets moved eth2. It would suggest you have 3 sockets. Perhaps you should disable the on-board ethernets in BIOS.

[QUOTE=paulunderwood;344701]Dodgy cable, eh? Keep an eye on those LEDs. :smile:

I don't know why eth0 gets moved eth2. It would suggest you have 3 sockets. Perhaps you should disable the on-board ethernets in BIOS.[/QUOTE]

That was the very first thing I did, before attempting to install the NIC.

I feel in dire need need of a beer...

[QUOTE=ewmayer;344712]I feel in dire need need of a beer...[/QUOTE]

127.0.0.1/8...

[CODE][chalsall@burrow ~]$ ping 127.12.34.56
PING 127.12.34.56 (127.12.34.56) 56(84) bytes of data.
64 bytes from 127.12.34.56: icmp_seq=1 ttl=64 time=0.070 ms
64 bytes from 127.12.34.56: icmp_seq=2 ttl=64 time=0.069 ms
64 bytes from 127.12.34.56: icmp_seq=3 ttl=64 time=0.064 ms
^C

[chalsall@burrow ~]$ ping 127.255.255.254
PING 127.255.255.254 (127.255.255.254) 56(84) bytes of data.
64 bytes from 127.255.255.254: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 127.255.255.254: icmp_seq=2 ttl=64 time=0.087 ms
64 bytes from 127.255.255.254: icmp_seq=3 ttl=64 time=0.069 ms
^C[/CODE]

For Christmas my girlfriend bought me a tee-shirt which says "There's no place like 127.0.0.1" (I'm not joking)....

I found [URL="http://ca.answers.yahoo.com/question/index?qid=20101023141056AAsAXts"]this[/URL] and other similar solutions. Comment out rather than delete!

Please post back the results of "cat /etc/udev/rules.d/70-persistent-net.rules" (or something similar) if you can't figure it out :beer:

( [URL="http://muzso.hu/2012/10/29/how-to-regenerate-the-etc-udev-rules.d-70-persistent-net.rules-file-on-debian-ubuntu"]here is another solution[/URL] )

[QUOTE=ewmayer;344699]While trying the first, I noticed a 'cable unplugged' note in the mac's network-setup dialog ... that led me to discover the lack-of-LED cause, which is that the NIC's cable connector is bad - I have to manually jam the cable plug into the connector hard for the LEDs to come on and the above dialog's physical-connection-status message to change to the desired 'connected'.

[I say the NIC connector because the same cable worked just fine with the old mobo ... let's just say 'connection to the outside world is dodgy'.]

Anyhoo, even with one hand jamming the cable in while the other types 'shh...' ... no joy. Also reverted the netmasks on both sides to the previous values of 255.255.255.0 and retried (again keeping one eye on the connected-or-not status line in the macbook's dialog to make sure it read 'connected') - still nothing. Bloody hell.

BTW, I still have no idea what that 'rename eth0 to eth2' business is all about - can anyone explain why the old-setup eth0 wasn't OK?[/QUOTE]Yeah, screwed me as well. Ethernet interfaces are now dynamically named specifically for the case of removable / re-configrable devices. Much the same as drives are to allow for USB and Bluetooth devices, so /dev/sdc can be different physical devices at different times. On a Gentoo box here, for instance, what used to be eth0 is now enp8s0 --- decoded as EtherNet Pci 8 Slot 0 or something like that. Just one link of many which may be useful to you: [url]https://bbs.archlinux.org/viewtopic.php?id=157764[/url]

Paul

Ah yeah, Gentoo. I have a couple of Gentoo installations here. Configuring and compiling the kernel to add specific hardware is encouraged. I guess Ernst's on-board realtek network device would be a supported option :smile:

FYI, I'll be in a position to fiddle with the system again in a couple hours.

Also, I'm running Debian, and my internet searches for drivers for the MSI mobo in question [cf. the Haswell preview thread in Hardware for exact specs] came up empty. How long does it typically take for such drivers to appear after a new mobo/cpu family hits market?

I think you have the same [URL="http://www.mersenneforum.org/showpost.php?p=342469&postcount=38"]MSI Z87-G41 PC Mate mainboard[/URL] as Prime95 has, which according to the [URL="http://www.msi.com/product/mb/Z87-G41-PC-Mate.html"]manual from MSI[/URL] has a Realtek® RTL8111G Gigabit LAN controller, the driver for which can be found [URL="http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false"]here[/URL]. Don't ask me how to install it :wink: (ps: maybe that is not what you need as it is for a PCI-E NIC...)

Much easier is to "mv /etc/udev/rules.d/70-persistent-net.rules ~" and reboot :smile:

[QUOTE=ewmayer;344773]FYI, I'll be in a position to fiddle with the system again in a couple hours.

Also, I'm running Debian, and my internet searches for drivers for the MSI mobo in question [cf. the Haswell preview thread in Hardware for exact specs] came up empty. How long does it typically take for such drivers to appear after a new mobo/cpu family hits market?[/QUOTE]

Kernel 3.10 might probably support it:

[URL]http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=57538c4a89506c333b480ff5bdfcd4f16f78ccdf[/URL]

[URL]http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fe7524c09793c87dfde55ac3f98f4b95d9d48638[/URL]

Kernel 3.9.6 is available at wheezy-backports. 3.10 should follow.

Uh oh, I might have started a sad series of events...

I assumed (incorrectly, as it turns out) that somehow MSI had used a "strange" chip on your [Ernst's] board like they did on my board.

Those Realtek 8111x chips are widely used; I'd be very surprised if recent (2007ish and later) Linux distros didn't support it out of the box.

So, if the jack on the Intel card really is dodgy (that would be...unusual) rather than the cable, you can just go back to the integrated LAN.

[QUOTE=sdbardwick;344778]So, if the jack on the Intel card really is dodgy (that would be...unusual) rather than the cable, you can just go back to the integrated LAN.[/QUOTE]

Just out of possible upside, he's an example (under a modern Linux) of what you can do which might help you:[CODE][chalsall@backup ~]$ cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo:39194972 466562 0 0 0 0 0 0 39194972 466562 0 0 0 0 0 0
em1:521299157 950665 0 0 0 0 0 132872 38783350 417689 0 0 0 0 0 0
em2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
em3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
em4:2394583536 2076278 0 0 0 0 0 130086 83405122 995960 0 0 0 0 0 0[/CODE]

If you're willing to share your's, we might be able to assist further.

[QUOTE=paulunderwood;344715]I found [URL="http://ca.answers.yahoo.com/question/index?qid=20101023141056AAsAXts"]this[/URL] and other similar solutions. Comment out rather than delete!

Please post back the results of "cat /etc/udev/rules.d/70-persistent-net.rules" (or something similar) if you can't figure it out :beer:

( [URL="http://muzso.hu/2012/10/29/how-to-regenerate-the-etc-udev-rules.d-70-persistent-net.rules-file-on-debian-ubuntu"]here is another solution[/URL] )[/QUOTE]

Thanks - that sounds like the correct diagnosis. My version of the above file contains 3 entries eth0-2, whose details are the same except for the device hex address, MAC address and (device type id), as follows (this is my heavily redacted format, not that in the file):

eth0: PC device 0x10ec:0x8168 (r8169) mac = bc:ae:c5:e3:40:8c
eth1: PC device 0x10ec:0x8168 (r8169) mac = d4:3d:7e:b9:c3:03
eth2: PC device 0x8086:0x10d3 (e1000e) mac = 00:1b:21:a8:53:44

(I did note find a file /etc/iftab as mentioned further down on the 1st page you linked, fyi.)

The eth0 is the onboard LAN of the old Sandy Bridge mobo I was using
I'm guessing eth1 is the onboard LAN of the new Haswell mobo? (but unimportant)
And eth2 is the MAC address of the Intel NIC I am attempting to use in the Haswell mobo.

So - edit the above file, swap eth0 <--> eth2, revert to eth0 in /etc/network/interfaces, restart networking? (Or do I need to reboot?)

Edit: Ah, just got to your followup:

[QUOTE=paulunderwood;344774]Much easier is to "mv /etc/udev/rules.d/70-persistent-net.rules ~" and reboot :smile:[/QUOTE]

Rebooted ... new version of the file shows eth0 correctly bound to e1000e ... attempting ssh from the macbook, again with one hand jamming the connector into the NIC until the mac's LAN-status dialog shows 'connected' ... no joy.

Ah, wait, I forgot to revert to eth0 in /etc/network/interfaces ... yep, 'ifconfig' shows only loopback ... revert, restart networking, 'ifconfig' now looks as expected ... retry connect-from-mac ... actually gonna just try 'ping'ing - OK here are 'ping' data, the point around seq 37 is where I again started jamming the cable into the NIC (and I am happy to report that it seems to have found a semi-stable niche this time, I let go it remained 'connected'):
[i]
ernst-w-mayers-macbook:OBJ_SCALAR ewmayer$ ping 192.168.1.102
PING 192.168.1.102 (192.168.1.102): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
Request timeout for icmp_seq 29
Request timeout for icmp_seq 30
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
Request timeout for icmp_seq 37
ping: sendto: No route to host
Request timeout for icmp_seq 38
ping: sendto: Host is down
Request timeout for icmp_seq 39
ping: sendto: Host is down
Request timeout for icmp_seq 40
ping: sendto: Host is down
Request timeout for icmp_seq 41
ping: sendto: Host is down
Request timeout for icmp_seq 42
ping: sendto: Host is down
Request timeout for icmp_seq 43
ping: sendto: Host is down
Request timeout for icmp_seq 44
ping: sendto: Host is down
Request timeout for icmp_seq 45
ping: sendto: Host is down
Request timeout for icmp_seq 46
ping: sendto: Host is down
Request timeout for icmp_seq 47
ping: sendto: Host is down
Request timeout for icmp_seq 48
ping: sendto: Host is down
Request timeout for icmp_seq 49
ping: sendto: Host is down
Request timeout for icmp_seq 50
ping: sendto: Host is down
Request timeout for icmp_seq 51
ping: sendto: Host is down
Request timeout for icmp_seq 52
ping: sendto: Host is down
Request timeout for icmp_seq 53
ping: sendto: Host is down
Request timeout for icmp_seq 54
ping: sendto: Host is down
Request timeout for icmp_seq 55
ping: sendto: Host is down
Request timeout for icmp_seq 56
ping: sendto: Host is down
Request timeout for icmp_seq 57
Request timeout for icmp_seq 58
Request timeout for icmp_seq 59
Request timeout for icmp_seq 60
Request timeout for icmp_seq 61
Request timeout for icmp_seq 62
ping: sendto: No route to host
Request timeout for icmp_seq 63
ping: sendto: Host is down
Request timeout for icmp_seq 64
ping: sendto: Host is down
Request timeout for icmp_seq 65
ping: sendto: Host is down
Request timeout for icmp_seq 66
ping: sendto: Host is down
Request timeout for icmp_seq 67
ping: sendto: Host is down
Request timeout for icmp_seq 68
ping: sendto: Host is down
Request timeout for icmp_seq 69
ping: sendto: Host is down
Request timeout for icmp_seq 70
ping: sendto: Host is down
Request timeout for icmp_seq 71
ping: sendto: Host is down
Request timeout for icmp_seq 72
ping: sendto: Host is down
Request timeout for icmp_seq 73
ping: sendto: Host is down
Request timeout for icmp_seq 74
ping: sendto: Host is down
Request timeout for icmp_seq 75
ping: sendto: Host is down
Request timeout for icmp_seq 76
ping: sendto: Host is down
Request timeout for icmp_seq 77
ping: sendto: Host is down
Request timeout for icmp_seq 78
ping: sendto: Host is down
Request timeout for icmp_seq 79
ping: sendto: Host is down
Request timeout for icmp_seq 80
ping: sendto: Host is down
Request timeout for icmp_seq 81
ping: sendto: Host is down
Request timeout for icmp_seq 82
Request timeout for icmp_seq 83
Request timeout for icmp_seq 84
Request timeout for icmp_seq 85
Request timeout for icmp_seq 86
Request timeout for icmp_seq 87
ping: sendto: No route to host
Request timeout for icmp_seq 88
ping: sendto: Host is down
Request timeout for icmp_seq 89
ping: sendto: Host is down
Request timeout for icmp_seq 90
ping: sendto: Host is down
Request timeout for icmp_seq 91
ping: sendto: Host is down
Request timeout for icmp_seq 92
ping: sendto: Host is down
Request timeout for icmp_seq 93
ping: sendto: Host is down
Request timeout for icmp_seq 94
ping: sendto: Host is down
Request timeout for icmp_seq 95
^C[/i]

Yeah, you might get away with just restarting the networking, after you have swapped eth0 and eth2, but if that fails to do it then reboot. Don't forget to undo any changes you made to /etc/network/interfaces. (Those extraneous lines can be commented out and change the one you are using to eth0.)

[QUOTE=ewmayer;344784]So - edit the above file, swap eth0 <--> eth2, revert to eth0 in /etc/network/interfaces, restart networking? (Or do I need to reboot?)[/QUOTE]

On the machine you wish to access...

[CODE]$ ifconfig eth0 172.16.1.1 netmask 255.255.0.0
$ ifconfig eth1 172.16.2.1 netmask 255.255.0.0
$ ifconfig eth2 172.16.3.1 netmask 255.255.0.0[/CODE]

On the machine you're going to test from, generally attached to the same switch and/or VLAN to the above just configured interfaces:

[CODE]$ ifconfig [YOUR_PRIMARY_INTERFACE]:1 172.16.234.345 netmask 255.255.0.0
$ ping -c 1 172.16.1.1
$ ping -c 1 172.16.2.1
$ ping -c 1 172.16.3.1
[/CODE]

Hope that helps.

[QUOTE=ewmayer]
Request timeout for icmp_seq 37
ping: sendto: No route to host
[/QUOTE]

Make sure your MacBook and Haswell box are on the same subnet i.e. 192.168.1.xxx. If not either change the MacBook address or change the netmask (to 255.255.0.0).

Try ping and ssh from the Haswell to itself again.

You are almost there... :smile:

[QUOTE=paulunderwood;344785]Yeah, you might get away with just restarting the networking, after you have swapped eth0 and eth2, but if that fails to do it then reboot. Don't forget to undo any changes you made to /etc/network/interfaces. (Those extraneous lines can be commented out and change the one you are using to eth0.)[/QUOTE]
See edit-addenda to my above post.

[QUOTE=chalsall;344787]On the machine you wish to access...

[CODE]$ ifconfig eth0 172.16.1.1 netmask 255.255.0.0
$ ifconfig eth1 172.16.2.1 netmask 255.255.0.0
$ ifconfig eth2 172.16.3.1 netmask 255.255.0.0[/CODE][/QUOTE]
eth0: returns, nothing printed
eth1: No such device
eth2: No such device

But something else is happening ... now, a few mins after reboot and the interfaces-file eth2 --> eth0 edit / networking-restart, ifconfig is again only showing loopback.

Gah...

[QUOTE=paulunderwood;344789]Make sure your MacBook and Haswell box are on the same subnet i.e. 192.168.1.xxx. If not either change the MacBook address or change the netmask (to 255.255.0.0).[/QUOTE]
Both /etc/network/interfaces on the Haswell and the netwrok-setup GUI on the mac are using mask 255.255.255.0, as was the case in my old Sandy Bridge setup. Why should the rightmost 255 need to be changed to 0 with the new hardware?

[QUOTE]Try ping and ssh from the Haswell to itself again.[/QUOTE]
OK, it seems with the eth* issue resolved, 'ifconfig' is now sensitive to the plugged-in-ness of the network cable into the bad connector of the NIC ... it 'unconnected' itself again, when I jammed it until the LEDs again lit up, 'ifconfig' again showed an eth0 entry, whose subnet/mask fields are
[i]
inet addr:172.16.1.1 Bcast 172.16.255.255 Mask:255.255.0.0
[/i]
So I have no control over the number of 255s in Mask, and simply must edit the macbook's mask to match?

I may have to resort to extreme measures with regard to this connector problem - or maybe see if I have cable lying around which I can try.

[QUOTE=ewmayer;344790]eth0: returns, nothing printed
eth1: No such device
eth2: No such device[/QUOTE]

That suggests that eth0 is the main ethernet device you'd want focus on; the one you have access to with your current install.

As root on your testing machine, also "$ ping -f 172.16.x.1".

Observe the "blinky" lights -- they're actually there for a reason....

172.16.1.1 ??? you want 192.168.1.102 LOL (which should be slightly different from the MacBook's address; by the last number if you are using mask 255.255.255.0)

[QUOTE=ewmayer;344791][i]
inet addr:172.16.1.1
[/i][/QUOTE]
Also, where did the value 192.168.1.102 set in /etc/network/interfaces go?

[QUOTE=chalsall;344792]That suggests that eth0 is the main ethernet device you'd want focus on; the one you have access to with your current install.

As root on your testing machine, also "$ ping -f 172.16.x.1".

Observe the "blinky" lights -- they're actually there for a reason....[/QUOTE]
[i]
ping: unknown host 172.16.x.1
[/i]
No change in LEDs during this.

[QUOTE=ewmayer;344791]So I have no control over the number of 255s in Mask, and simply must edit the macbook's mask to match?[/QUOTE]

Please tell me everyone here understands that under IPv4 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 and 127.0.0.0/8 are private, and should never be routed over the Internet?

[QUOTE=ewmayer;344795][i]
ping: unknown host 172.16.x.1
[/i]
No change in LEDs during this.[/QUOTE]

The result of "ping 172.16.1.1"?

[QUOTE=chalsall;344798]The result of "ping 172.16.1.1"?[/QUOTE]
[i]
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
[/i][rapidly alternating ._ ascii char-field here, until I ^Ced it][i]
--- 172.16.1.1 ping statistics ---
24387 packets transmitted, 24387 packets received, 0% packet loss, time 7970ms[/i]
[added packet-stats-foo snipped]

On the Debian Haswell box using the menus try going into: system-->preferences-->Network Connections
highlight the "wired connection"
click on the "edit" button
choose the ipv4 tab
make sure the address is 192.168.1.102
and the mask is 255.255.255.0
click on "apply"

On the MacBook:

[CODE]
ping 192.168.1.102
[/CODE]

Also can make sure the MacBook is on the same subnet i.e 255.255.255.0 and that its address is 192.168.1.x where x is [B]not[/B] the same as the Haswell or any router you have connected by the cables

[QUOTE=ewmayer;344799][i]
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
[/i][rapidly alternating ._ ascii char-field here, until I ^Ced it][i]
--- 172.16.1.1 ping statistics ---
24387 packets transmitted, 24387 packets received, 0% packet loss, time 7970ms[/i]
[added packet-stats-foo snipped][/QUOTE]

Be happy...

You've just "made friends" with 172.16.1.1.

[QUOTE=paulunderwood;344800]On the Debian Haswell box using the menus try going into: system-->preferences-->Network Connections
highlight the "wired connection"
click on the "edit" button
choose the ipv4 tab
make sure the address is 192.168.1.102
and the mask is 255.255.255.0
click on "apply"[/quote]
Don't I wish - this was setup as a barebones access-via-network-ssh-only system, no GUI. I am interfacing in term mode via LCD right now.

[quote]On the MacBook:

[CODE]
ping 192.168.1.102
[/CODE]

Also can make sure the MacBook is on the same subnet i.e 255.255.255.0 and that it's address is 192.168.1.x where x is [B]not[/B] the same as the Haswell or any router you have connected by the cables[/QUOTE]

Macbook is ....101, and has always been on that 255.255.255.0 subnet since I first set things up last December. That ping is precisely what I tried after making the eth0-no-rename changes.

Still don't understand why ifconfig is showing the 172-address, not the 192-one I have in my interfaces file. {Maybe you explained it in your IPv4 note, but I need it in English.]

it may help :
[url]https://tools.ietf.org/html/rfc5735[/url]

[QUOTE=firejuggler;344805]it may help :
[url]https://tools.ietf.org/html/rfc5735[/url][/QUOTE]

Can you condense that manypage spec into 1 or 2 sentences? I don't want ti sound like a Luddite, but I have no interest in becoming a networking expert, and actually would like to get some code written at some point this month! (which has a little over 1 day to go, alas).

Fuck me - had a perfectly good working local-ethernet setup, even with new mobo and network card it should need at most a few file edits and reboot to get this working. Now I'm looking at 20-page "Special Use IPv4 Addresses" specs.

I do see this snip in the spec, though:
[i]
192.168.0.0/16 - This block is set aside for use in private networks.
Its intended use is documented in [RFC1918]. As described in that
RFC, addresses within this block do not legitimately appear on the
public Internet. These addresses can be used without any
coordination with IANA or an Internet registry.
[/i]
Yeah - that's the one I want. Where in the hell did it go? Is it being obfuscated by the 172-one?

Signing off for today ... thx again for your generous willingness to help, all.

But if I don't get at least some real (coding) work done today I'm gonna be really annoyed.

To get it back do:

[CODE]
ifconfig eth0 192.168.1.102
ifconfig eth0 up
[/CODE]

Now try pinging from the MacBook, please

[QUOTE=paulunderwood;344808]To get it back do:

[CODE]
ifconfig eth0 192.168.1.102
ifconfig eth0 up
[/CODE]

Now try pinging from the MacBook, please[/QUOTE]

That works - success at last! Now I just need to fix my dodgy-NIC-ethernet-cable-plug issue ... tried swapping the 2 cable ends, same symptoms, confirming that the problem is with the plug in the ethernet card.

Thanks for all the help, folks!

[QUOTE=ewmayer;344833]That works - success at last! Now I just need to fix my dodgy-NIC-ethernet-cable-plug issue ... tried swapping the 2 cable ends, same symptoms, confirming that the problem is with the plug in the ethernet card.

Thanks for all the help, folks![/QUOTE]

You are welcome. I hope it works after a reboot too. :smile:

Perhaps a small shim jammed in with the plug would solve the NIC socket problem, as long as you do not prevent contact.

[QUOTE=ewmayer]Thanks - that sounds like the correct diagnosis. My version of the above file contains 3 entries eth0-2, whose details are the same except for the device hex address, MAC address and (device type id), as follows (this is my heavily redacted format, not that in the file):

eth0: PC device 0x10ec:0x8168 (r8169) mac = bc:ae:c5:e3:40:8c
eth1: PC device 0x10ec:0x8168 (r8169) mac = d4:3d:7e:b9:c3:03
eth2: PC device 0x8086:0x10d3 (e1000e) mac = 00:1b:21:a8:53:44

[/QUOTE]

You know, perhaps you should try turning on the on-board card in BIOS, rename eth1 to eth0 etc etc... or simply "mv /etc/udev/rules.d/70-persistent-net.rules ~/70-persistent-net.rules.backup" as the file will be regenerated on boot --- and anyway reboot. (To save time make the OS change and then change BIOS.) Then run:

[code]
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth0 192.168.1.102
ifconfig eth1 192.168.1.103
ifconfig
ifconfig eth0 up
[/code]

assuming the on-board Realtek is now picked up as eth0 by udev :smile:

[QUOTE=paulunderwood;344843]You know, perhaps you should try turning on the on-board card in BIOS, rename eth1 to eth0 etc etc... or simply "mv /etc/udev/rules.d/70-persistent-net.rules ~/70-persistent-net.rules.backup" as the file will be regenerated on boot --- and anyway reboot. (To save time make the OS change and then change BIOS.) Then run:

[code]
ifconfig eth0 down
ifconfig eth1 down
ifconfig eth0 192.168.1.102
ifconfig eth1 192.168.1.103
ifconfig
ifconfig eth0 up
[/code]

assuming the on-board Realtek is now picked up as eth0 by udev :smile:[/QUOTE]

Hi, Paul:

I wasn't ignoring your advice ... just had a week's worth of AVX2 code-prototyping I needed to get done (all doable on my mac) before serious build/test/debug of same (needing file transfer to the Haswell box and term/gdb access to same) could occur.

Just did as you suggested, worked flawlessly, I was just able to login from the mac for the first time (since the bad-connector issue made such impossible with the 3rd-party NIC, at least for persons with just 2 arms. :) Even better, the onboard ethernet of the MSI mobo appears to be significantly faster than that of the older Sandy Bridge-containing Asus board it replaced - logging in to the old one used to take a full 5-10 seconds to return a login prompt, now it's virtually instantaneous. We are good to go here.

Should we ever meet in real life I am going to buy you multiple beers. :)

[QUOTE=ewmayer;345763]Even better, the onboard ethernet of the MSI mobo appears to be significantly faster than that of the older Sandy Bridge-containing Asus board it replaced - logging in to the old one used to take a full 5-10 seconds to return a login prompt, now it's virtually instantaneous.[/QUOTE]

So here's something interesting: Just brought the system down for some quick maintenance, including removal of the no-longer-needed add-on ethernet card. Came back up fine, verified that eth0 was still configured as desired and up, then did a quick ssh-login from the macbook to test it. Wouldn't you know - same 5-10 second delay-before-login-prompt as I'd been used to with my old Asus mobo. Redid the ifconfig eth0 down/tie-to-IP-...102/up, and voila! Once again the login delays go away. Anybody know the reason for this?

On the Haswell box, edit "/etc/ssh/[URL="http://man.he.net/man5/sshd_config"]sshd_config[/URL]" and change the line to, or append the line if "UseDNS" does not exist:

[CODE]UseDNS no[/CODE]

Save. Then run:

[CODE]/etc/init.d/sshd restart[/CODE]

HTH :smile: