When the ifconfig eth0 hw ether 11:22:33:44:55:66 is executed, the current kernel shows a successful modification, but the ping only sends ARP packets indefinitely, and the PC has given the board back the ARP packet, but without any ICMP packet information, Suspicion is caused by an illegal MAC address.
This is what the online article says:
When entering the second sentence the command is prompted: Siocsifhwaddr:cannot assign requested address. The original MAC address is not set.
IP addresses fall into three categories: broadcast, multicast, and unicast. The broadcast is: FF:FF:FF:FF:FF:FF. Multicast: First byte The last one is 1, such as 47:72:65:65:6e:00,
The last of 47 is 1. Unicast: First byte the last one is 0, such as 48:72:65:65:6e:00。 Changing the address above to 48 will not be the problem.
Problem-intensive Learning:
IEEE 802 defines the MAC address as
|<------------------>|<---------bit-------->|
| Ccccccug CCCCCCCC CCCCCCCC | xxxxxxxx xxxxxxx Xxxxxxxx |
MAC address type controlled by UG:
U:0: Unified Management by IEEE-specified ID
1: Local Administration
g:0: Unicast
1: Multicast
That is, the 12-bit MAC address is divided into four categories, which is determined by the second
The second place is
0 | 4 | 8 | C: (00) Unified Managed Unicast MAC
1 | 5 | 9 | D: (01) Unified Managed Multicast MAC
2 | 6 | A | E: (10) local managed unicast MAC
3 | 7 | B | F: (11) Local managed multicast MAC
=================================================================
Due to such network terminals such as ADSL routing, the general use of unified management of unicast Mac
So will judge 02:10:18:01:00:01 or (11:01:18:00:00:30) as invalid Mac, causing the wireless function failure, or network connection failure and so on.
And for a Mac like 00:25:5e:08:de:43, it's considered effective.
But 2.6.21 changed to the wrong MAC address it does not prompt, MAC address is not legal, but later will be the MAC address filtered out.
Linux 2.6.21 version of the kernel legal MAC address