Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Feb 2010 14:30:38 +0000
From:      Matthew Seaman <m.seaman@black-earth.co.uk>
To:        James Smallacombe <up@3.am>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: yikes!  MAC address changed ??
Message-ID:  <4B74148E.8090405@black-earth.co.uk>
In-Reply-To: <alpine.BSF.2.00.1002110706300.93530@mail.pil.net>
References:  <alpine.BSF.2.00.1002102226470.19792@mail.pil.net> <alpine.BSF.2.00.1002102313420.43691@mail.pil.net> <alpine.BSF.2.00.1002110544080.50734@mail.pil.net> <4B73EC31.6030209@black-earth.co.uk> <alpine.BSF.2.00.1002110706300.93530@mail.pil.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1D5A9850DE44E05A54191F1B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/02/2010 12:22, James Smallacombe wrote:
>> It's not 'arp -s' that is used to change the MAC address on an
>> interface, but ifconfig(8) -- something like this:
>>
>>    # ifconfig re0 ether 00:17:e0:4f:b9:c0
>=20
> See my second post.  I screwed up in my first post.  It wasn't the MAC
> address of my NIC that changed, it's the MAC address of the DEFAULT
> GATEWAY that changed.  I believe that would use 'arp', not 'ifconfig',
> right?

Ah, right.  Please ignore my previous bletherings.  Had wrong end of
stick.

>>> 2) Could an Ethernet card defect or re0 driver problem cause anything=

>>>    like this?  Other bug?
>>
>> Yes -- this is the most likely cause.  Hardware problems.  The MAC
>> address is built into the network card using an EEPROM or such like,
>> and those can conceivably go bad.  Replace the NIC and see if the
>> problems go away.
>=20
> Ok, longer shot here...could a hardware problem on my box screw up the
> MAC address of the default gateway?  It should be noted that when I did=

> and ifconfig -a during this down time, the Ether showed "no carrier".=20
> Could messed up ARP tables even do that?  I would think that the carrie=
r
> just needs a cable plugged from the NIC into a switch?

I still think it's probably hardware.  The question is: duff router or
duff server?

A good test is to see what happens to another box on the same network
segment.  If there's another machine already there that will do, or try
plugging in a laptop configured with a spare IP and the correct default
gateway.  Then try pinging around other addresses on the network, and
beyond your gateway box.

If this third machine:

   * can ping the world successfully, and gets the original (correct)
     mac address

     -- then your server is where the problem is

   * can ping the world successfully, but gets the changed mac address

     -- then your router has somehow changed mac: whether deliberately,
        by operator accident or by hardware flaking out.  In which case,
        you can leave everything running with the changed mac for the
        time being while you concentrate on dealing with the router.

   * can't ping the default gateway or ping through it, but can ping
     other machines on the local net, irrespective of what MAC it picks
     up for the default gateway.

     -- then the router is fubar.  At best it is responding to ARP
        requests with a corrupt MAC address and can be cured by a reboot
        or similar.  At worst, it needs expensive replacement therapy.

You can't change the MAC address on the router by fiddling with arp(8)
on your server.  You can however terminally confuse your server as to
what the MAC address of the router really is, and you can make mayhem
by creating an arp conflict and having your machine usurp the router's
mac address.  Best not to do either of those things.  Just let the arp
table be populated automatically.  Unless marked as permanent,
addresses in the arp cache will time out and be refreshed once they
reach the maximum age:

    % sysctl net.link.ether.inet.max_age
    net.link.ether.inet.max_age: 1200

which equates to 20 minutes.  So if you simply wait, it will frequently
sort itself out.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.              7 Priory Courtyard, Flat 3
Black Earth Consulting                       Ramsgate
                                             Kent, CT11 9PW
Free and Open Source Solutions               Tel: +44 (0)1843 580647


--------------enig1D5A9850DE44E05A54191F1B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt0FJgACgkQ8Mjk52CukIz3VwCfb3O69Uql2ZjxVZ555i212d90
YOEAn2/fpuFH8nfgSN61WbhVUXrRZ1s7
=0VKN
-----END PGP SIGNATURE-----

--------------enig1D5A9850DE44E05A54191F1B--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B74148E.8090405>