G120 with ENC28: unsolicited incoming arp reply

We are using G120 with ENC28 in our product. (FW V4.3.8.1)
The MAC address is generated with an algo found in codeshare, based on the device Serial number.
The device has a fixed IP address and is connected to a Windows PC over a small local Network (no Domain, Internet, … on this Network).
This worked fine so far.
Now one of our customers has Symantec endpont protection installed.
Symantec detects an "Unsolicited incoming arp Reply, this a Kind of MAC spoofing that may consequently do harm to your Computer."
After that no communication to the G120 is possible anymode (not even ping) until it is reset (power off/on).
Anyone had a similar experiance? Can this be cause due to the MAC address Generation?


Did you verify that the MAC is unique on the network? Also, is the MAC valid? I.e. if you lookup the MAC on the internet, does it associate with an actual manufacturer?

1 Like

Wonder if its because SEPM is seeing the original MAC address, then when your code changes it, it detects it as a re-mapping?

Found this on Symantecs support forum

Enable anti-MAC spoofing:-
Allows inbound and outbound ARP (Address Resolution Protocol) traffic only if an ARP request was made to that specific host. It blocks all other unexpected ARP traffic and logs it in the Security Log.
Media access control (MAC) addresses are hardware addresses that identify the computers, the servers, and the routers. Some hackers use MAC spoofing to try to hijack a communication session between two computers. When computer A wants to communicate with computer B, computer A may send an ARP packet to computer B.

Anti-MAC spoofing protects a computer from letting another computer reset a MAC address table. If a computer sends an ARP REQUEST message, the client allows the corresponding ARP RESPOND message within a period of 10 seconds. All client rejects all unsolicited ARP RESPOND messages.

This option is disabled by default.

Apparently you can create a firewall rule to allow this traffic from an address (saves having to disable this feature totally)

The MAC address is not changed at runtime (this would only happen if the Serial number would change). Once the MAC is generated it gets written to Flash.
Since the MAC generated, I doubt that it will resolve to a specific manufacturer. But at random it would be possible.
Here is the Code I use for this (based on Code from CodeShare):

private static byte[] GenerateUniqueMacAddr(object myUniqueId = null)
   //great article explaining the making of the MAC Address first Byte...

   // create a en empty byte array
   var myMac = new byte[6];
   //generate a random based on a fixed seed this will guarantee that we get the 
   //same Random number every time based on the provided string... make your string UNIQUE...
   //This would be great if only each board had a UNIQUE SERIAL Number
   var r = myUniqueId != null ? new Random(myUniqueId.GetHashCode()) : new Random();
   // fill the newly generated bytes into the variable
   // update the last bit of the first byte with 1 which will flag the Mac as a Locally administered Mac address...
   //Please share if you have a better way of doing this.
   myMac[0] = (byte)(myMac[0] | 0x01);
   //shift to the left by 1 which will give 10 on the last two bits of the first byte... 0 on the last bit means UNICAST Mac Address.
   myMac[0] = (byte)(myMac[0] << 1);
   return myMac;

// ENC28 does not have a built in unique MAC address, so we generate one
object uniqueId = DeviceCfg.GetDeviceSearialNo() ?? DeviceCfg.GetDeviceId() ?? "ENC28";
var myMac = GenerateUniqueMacAddr(uniqueId);
if (!ByteArrayEquals(eth.PhysicalAddress, myMac))
   //update the Mac Address
   eth.PhysicalAddress = myMac;
   //Hard Reboot the device so the newly Updated MAC is taking into consideration.

a) are you changing MAC each time or just once? and b) do you set the first byte in the mac address as private unicast?

Looking at my Code above:yes and yes.

Looks like i missed this “while” i was typing my reply, lol.
I use something like this, not having issues until now.

                    //factory default =  {0,33,3,0,0,2}
                    byte[] DeviceMac = MyEthernet.PhysicalAddress;
                    if (DeviceMac[0] == 0 && DeviceMac[1] == 33 && DeviceMac[2] == 3)
                        //factory mac found, create new private mac address
                        byte[] MyNewMac = new byte[6];
                        Random MyRandom = new Random();

                        //set private and unicast bits in first byte
                        MyNewMac[0] = 2; 
                        MyEthernet.PhysicalAddress = MyNewMac;

                        SysLogOut("", "Generate MAC address and reboot");
                        PowerState.RebootDevice(true, 1000);

Looks actually nearly identical to me. 1st 2 bist of Byte 0 are 10 (equals 2). everything else is random.
Thank you for sharing.

I think we know now why Symantec got alarmed. We recently added 2 new Micro Controller devices to this Network, both based on Atmel UC3 CPU’s. Our programer assigned both the same MAC address: 0x01 02 03 04 05 06.
I wonder why it workes at all. We just dont’t know yet if this also kicks the G120 from the Network. The G120 does not comunicate with these other devices.

Ok, so the MACs were not unique.

So, making all MACs unique on the Network does not help.
Symantac still complaining about the G120. The Symantec message even contains the MAC and IP address of the G120.
Any more ideas?
Could the lwIP Version from the @GHI Firmware do something “bad” with it’s ARP request?

There’s a list of MAC address manufacturer codes. I’d absolutely seed your randommess based on that list, not a fully random list, because SEP probably has tighter rules than your everyday router does. Try the IEEE lists to find someone who you think might never appear on your network :slight_smile: Welcome to The Public Listing For IEEE Standards Registration Authority

why dont you ask Symantec ? Your customer don’t have to pay for support cases and should know how to open a support case

You will need a wire-shark capture if you want to dig in deeper.

I read the Wikipedia article about MAC addresses, and as I understand it if I set the locally managed MAC bit, It does not matter what the vendor id actually is.

Problem here is that this Problem is a customer site in China (I’m in Germany) and there is no one on site I can really work with. Also I guess the People in Charge from our customer will say that this is our Problem, so why should they contact Symantec. It’s not so simple. Even the People in Charge (whic are actually Germans too) say that it’s not that easy with the Chinese Plant.

Good luck…

Thank you, but thats actually buisness as usual.