Networking issues with Haswell-based Linux increase Courvoisier consumption

[paulunderwood]

Originally Posted by 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

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:

ifconfig eth0 down
ifconfig eth1 down
ifconfig eth0 192.168.1.102
ifconfig eth1 192.168.1.103
ifconfig
ifconfig eth0 up

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

[ewmayer]

Originally Posted by paulunderwood

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:

ifconfig eth0 down
ifconfig eth1 down
ifconfig eth0 192.168.1.102
ifconfig eth1 192.168.1.103
ifconfig
ifconfig eth0 up

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

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

[ewmayer]

Originally Posted by ewmayer

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.

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?

[paulunderwood]

On the Haswell box, edit "/etc/ssh/sshd_config" and change the line to, or append the line if "UseDNS" does not exist:

UseDNS no

Save. Then run:

/etc/init.d/sshd restart

HTH