Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Incorrect MAC received on packet - why? How to fix?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Incorrect MAC received on packet - why? How to fix?

myhkenmyhken Member
edited February 2015 in Help

After I got my /28 IPv4 subnet at Hetzner I have started to get this error when I try to connect to some of my VMs using the subnet.
Windows VMs works fine, CentOS 7 VMs works fine, but not CentOS 6.6 (32bit and 64bit)

I'm using static IP with this setup:

Here is my subnet NIC, and I have used the first IP in my subnet + NETMASK, no gateway, and Googles nameservers. As you can see it's online, and as I wrote, it work good at Windows and CentOS 7.

I get this error at home, and I get it from my other Hetzner server at another DC. So it's not a issue at my ISP. I found this about the error on putty FAQ

But I'm using putty v.0.62, so there should not be any issue. And why did it just happen when I changed from a /29 to a /28 subnet?
To be sure, I removed DHCP from the server so there is no old settings there. I also created the new subnet you see on the picture, so no old settings there either.

Edit: New info for new readers.

I have now created a total of 10 VMs on my /28 subnet, all using different IPv4.
I have used Windows (works without any issue), I have used CentOS 7 (works without any issue), I have used CentOS 6.4 minimal (works without any issue) and then I have used CentOS 6.6, and I have issues with all VMs with 6.6, both 32bit and 64bit.

I have no problem using putty on all my VMs inside the main server. But it will not work from outside.

The CentO 6.4 installation works fine, until I run yum update -y and it's become a CentOS 6.6 installation, then it stop working.

It's only VMs using my new IPv4 /28 subnet that is affected. If I move the VM to one of my external IPs, not part of the /28 subnet, the same server works 100% without any issues. When I move it back to the /28 subnet, there is a issue again.

I have tried putty from my:
Home computers - don't work with the /28 subnet CentOS 6.6 VMs. 6.4 and 7 is OK.
Second Hetzner server (on a different DC) - don't work with the /28 subnet CentOS 6.6 VMs. 6.4 and 7 is OK.
And on the main dedicated server there the VMs are created. Works fine with all VM's..

Any quick fix for this problem?

Comments

  • perennateperennate Member, Host Rep

    It has nothing to do with your network configuration, as indicated by the Putty FAQ. Maybe try upgrading packages on your server that's not working, and restart sshd.

  • myhkenmyhken Member
    edited February 2015

    @perennate said:
    It has nothing to do with your network configuration, as indicated by the Putty FAQ. Maybe try upgrading packages on your server that's not working, and restart sshd.

    Which packages? My test VMs has a clean CentOS 6.6 32/64bit minimal installation on it, downloaded directly from CentOS mirrors. I have then used yum update so all is updated.

    Why do one of the VMs works on the external NIC with one of my extra IPs fra Hetzner (not part of any subnet), but will not work when I change NIC to subnet, and change settings in eth1 (since the old NIC was eth0). Then I get the MAC error using putty.
    Changing back on external NIC, changing back to eth0 (and enable boot=yes there), no error. Make no sense.

    PS! same .iso files is used to create all my other CentOS VMs on both of my dedicated servers. No errors on any other VM, beside they on my new IPv4 /28 subnet.

  • myhkenmyhken Member
    edited February 2015

    I also get the same error using another SSH client:

    http://myhken.info/div/160215putty4.jpg

  • More info while I test. Downloaded CentOS 6.4 64bit minimal, and that worked without the MAC error after installation.
    When I was sure everything worked, I did a yum update, and then a reboot after the update. Then the same error was back. So it has something with CentOS 6.6 in combination with my /28 subnet. So Windows = OK, CentOS 7 = OK, CentOS 6.4 = OK, but CentOS 6.6 is not OK.

    What can it be?

  • Try to use dropbear instead of openssh-server on CentOS. Let's see what happens...

    http://miami-nice.co.uk/how-to-install-dropbear-and-change-the-ssh-port-centos/

  • @pbalazs123 said:
    Try to use dropbear instead of openssh-server on CentOS. Let's see what happens...

    http://miami-nice.co.uk/how-to-install-dropbear-and-change-the-ssh-port-centos/

    Tried everything in the guide, only get this error when I try to connect then:

  • Did you specify that IP address in sshd_config or did or leave it at the default (0.0.0.0)?

  • UrDNUrDN Member
    edited February 2015

    does it show the correct mac?

    ip link show eth0

  • @UrDN said:
    does it show the correct mac?

    ip link show eth0

    Yes, it's the same MAC in the eth0 config file as I have in Hyper-V interface for all the servers I test on now. Can't understand why CentOS 6.4 minimal works, but not if I upgrade it to 6.6.

    @bsdguy said:
    Did you specify that IP address in sshd_config or did or leave it at the default (0.0.0.0)?

    Never changed IP in the sshd-config file before, and all my other CentOS servers work just fine with SSH (always using another port), just the VMs on the /28 subnet that has this issue, and just CentOS 6.6. Something new has come since CentOS 6.4, that create this issue.

  • UrDNUrDN Member
    edited February 2015

    So it's obviously not related to MAC as in Media Access Control but rather Message Authentification Code.

    Since you've upgraded SSH you may try deleting your known_hosts or SshHostKeys as it's called with Putty iirc.

    Also please check your syslog for ssh debug information.

    PS: I have just seen the screenshots, it's definitely MAC as in Message Authentification Code so your problem is not related with the MAC address.

    Thanked by 1Silvenga
  • Don't think so. Error code 10054 in Windows is clearly network related. It can mean different (related) things but here it seems to be due to SSHD (remote side/server) terminating the connection.

    Moreover it seems to work fine with another IP address, if I got myhken right.

    What's in the log files? Also, just to make sure and to avoid misunderstandings, please provide the output of "ifconfig -a" (Feel free to black out some bytes like you did before).

    Also, it seems at least worth to try editing /etc/ssh/sshd_config (or similar for your distro) and to uncomment and/or set "ListenAddress your_servers_IP" (e.g. "ListenAddress 148.14.14.3" to make sure that SSHD listens not on any and all addresses but on that one.

  • @UrDN said:

    Since you've upgraded SSH you may try deleting your known_hosts or SshHostKeys as it's called with Putty iirc.

    I'm talking about brand new clean VMs, just created for this issue here. New fresh installations of Windows, Centos 7, Centos 6.4 and CentOS 6.6. Also tried both 32bit and 64bit version there it's available. So I have not upgraded a thing. Just straight from the box, from the minimal .iso files from CentOS.

    I have used around 10 new VMs for this test, so none of them is "known" from before in putty. I have also used different IPs for all tests.

    And as I wrote before, the issue is at Bitvise SSH Client also, not just Putty,
    and it's only outside the server. Inside the server, putty works 100% on the same VMs that don't work from the outside. But it will not work on my second Hetzner server, so again, it's has something with the network from my mainserver to the outside to do.

  • bsdguy said: Moreover it seems to work fine with another IP address, if I got myhken right.

    It worked fine with a /29 subnet I had (6 IP addresses) and it works fine with three extra IPs I have outside the /28 subnet.
    The only issues is with VMs created on the /28 subnet (15 IPs)

    bsdguy said: What's in the log files? Also, just to make sure and to avoid misunderstandings, please provide the output of "ifconfig -a" (Feel free to black out some bytes like you did before).

    From all 10 test VMs I have created now? I'm talking about brand new VMs just created for this issue here, CentOS minimal installation.

    Here is one ifconfig:

    As with all servers I have created yesterday on my new IPv4 /28 subnet, this VM workes 100% within the main server. No issues at all using putty on it.
    But putty or other SSH clients will not work on this or the others servers I have created from outside the main server.

    If I use one of my external IPs (not the /28 subnet) I have no issues at all.

    bsdguy said: Also, it seems at least worth to try editing /etc/ssh/sshd_config (or similar for your distro) and to uncomment and/or set "ListenAddress your_servers_IP" (e.g. "ListenAddress 148.14.14.3" to make sure that SSHD listens not on any and all addresses but on that one.

    I did then restart sshd, and then I tried login from the outside again, and still the same error.

  • You must check the log file on the server's side.

  • I finally found the problem, and then the solution. When you use a IPv4 subnet in Hyper-V (on Hetzner) you have to set your network card to Legacy NIC before you start your new VM.
    They say so in their DHCP guide, but since I was not using DHCP, I did not think that was relevant for me. Still, you don't need legacy NIC on Windows VMs and on CentOS 7 VMs, just on CentOS 6.6. (don't know why, but thats the case).

    So problem solved after many many hours, and a total server reload (twice).

Sign In or Register to comment.