Networking issues with Haswell-based Linux increase Courvoisier consumption

[ewmayer]

Originally Posted by paulunderwood

I found this 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

( here is another solution )

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:

Originally Posted by paulunderwood

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

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'):

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

[paulunderwood]

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.)

[chalsall]

Originally Posted by ewmayer

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

On the machine you wish to access...

$ 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

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

$ 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

Hope that helps.

[paulunderwood]

Originally Posted by ewmayer

Request timeout for icmp_seq 37
ping: sendto: No route to host

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...

[ewmayer]

Originally Posted by paulunderwood

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.)

See edit-addenda to my above post.

Originally Posted by chalsall

On the machine you wish to access...

$ 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

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...

[ewmayer]

Originally Posted by paulunderwood

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).

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?

Try ping and ssh from the Haswell to itself again.

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

inet addr:172.16.1.1 Bcast 172.16.255.255 Mask:255.255.0.0

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.

[chalsall]

Originally Posted by ewmayer

eth0: returns, nothing printed
eth1: No such device
eth2: No such device

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....

[paulunderwood]

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)

[ewmayer]

Originally Posted by ewmayer

inet addr:172.16.1.1

Also, where did the value 192.168.1.102 set in /etc/network/interfaces go?

[ewmayer]

Originally Posted by chalsall

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....

ping: unknown host 172.16.x.1

No change in LEDs during this.

[chalsall]

Originally Posted by ewmayer

So I have no control over the number of 255s in Mask, and simply must edit the macbook's mask to match?

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?