[ipxe-devel] Intel 82576 MAC swapping

[Kieran Evans]

My point in the previous email was that intel_fetch_mac_eeprom is called 
before is_valid_ether_addr. If there is a MAC in the EEPROM, the if 
statement surounding intel_fetch_mac_eeprom retruns 0 from the 
intel_fetch_mac function.

This means that if there's a MAC in eeprom, the is_valid_ether_addr 
function is never reached, and so the autoloaded MAC is never checked 
for validity.

So any checks I add to is_valid_ether_addr() will never be reached.

/Kieran

On 27/07/2012 11:16, Anton D. Kachalov wrote:
> Kieran,
> First, driver read autoload MAC from INTEL_RAL/INTEL_RAH.
> Then driver fetch MAC from EEPROM. After driver tries to validate 
> autoloaded MAC. If it fits, it copies to "hw_addr" otherwise EEPROM 
> MAC will be used. Usually, EEPROM of embedded NICs programmed by the 
> motherboard vendor, because MAC address space is a vendor specific.
> Try to add two additional checks before "is_valid_ether_addr()" to see 
> which check fails:
> is_multicast_ether_addr(mac.raw) must return 0
> is_zero_ether_addr(mac.raw) must return 0
> 27.07.2012, 14:06, "Kieran Evans" <keyz182 at gmail.com>:
>> Hi, unless I'm mis-reading this, or I've misunderstood, this code 
>> looks like it will always use the EEPROM MAC if it exists (i.e. the 
>> return 0 after intel_fetch_mac_eeprom is before the 
>> is_valid_ether_addr, so it'll never be reached).
>>
>>
>> static int intel_fetch_mac ( struct intel_nic *intel, uint8_t 
>> *hw_addr ) {
>> union intel_receive_address mac;
>> int rc;
>> /* Read current address from RAL0/RAH0 */
>> mac.reg.low = cpu_to_le32 ( readl ( intel->regs + INTEL_RAL0 ) );
>> mac.reg.high = cpu_to_le32 ( readl ( intel->regs + INTEL _RAH0 ) );
>> DBGC ( intel, "INTEL %p has autoloaded MAC address %s\n",
>> intel, eth_ntoa ( mac.raw ) );
>> /* Try to read address from EEPROM */
>> if ( ( rc = intel_fetch_mac_eeprom ( intel, hw_addr ) ) == 0 )
>> return 0;
>> /* Use current address if valid */
>> if ( is_valid_ether_addr ( mac.raw ) ) {
>> memcpy ( hw_addr, mac.raw, ETH_ALEN );< /div> return 0;
>> }
>> DBGC ( intel, "INTEL %p has no MAC address to use\n", intel );
>> return -ENOENT;
>> }
>>
>> It seems like this is the correct way to do things, as if a user has 
>> burned a custom MAC into the EEPROM, then that's the one to use. I 
>> assume (though I can't find any info to back this up) that intel 
>> burns the default MAC into the eeprom too, and that's why there's MAC 
>> addresses in the EEPROM even though I never changed them. Could this 
>> issue be down to PCI device enumeration? I.e. the two ports are being 
>> enumerated in a different order by iPXE than elsewhere, so even 
>> though the auto-assigned mac is correct, when it checks the EEPROM, 
>> it's seeing a different value because  it thinks port 0 is port 1 and 
>> port 1 is 0?
>>
>> /Kieran
>>
>> Also, oops, forgot to reply to the list,  last time, so list email 
>> added back in.
>>
>> On 27/07/2012 10:40, Anton D. Kachalov wrote:
>>> EEPROM macs used only when autoloaded is not complain by "is_valid_ether_addr" routine (lines 226-230). Try to add more debug messages here to track why driver going to use EEPROM's MAC instead of autloaded.
>>>
>>> 27.07.2012, 13:14, "Kieran Evans"<keyz182 at gmail.com>  <mailto:keyz182 at gmail.com>:
>>>> Hmm, it seems that the autoloaded and EEPROM MACs are at odds (I'm the
>>>> only person to have touched these servers since they were purchased, and
>>>> no modification of the EEPROM has been made, no setting of alternate MAC
>>>> addresses etc).
>>>>
>>>> http://dbyz.co.uk/ipxe1.png
>>>> http://dbyz.co.uk/ipxe2.png
>>>>
>>>> After seeing that, I can think of two possible temporary workarounds,
>>>> but not sure about perminent fixes.
>>>>
>>>> Workaround A: Set the MACs in EEPROM the other way around. (May then
>>>> confuse linux, so needs checking)
>>>> Workaround B: Compile iPXE with Mac loading from the EEPROM disabled
>>>> (Comment out line 223+224 of src/drivers/net/intel.c ?)
>>>>
>>>> Any ideas on a more perminent workaround/fix? I'm fairly lucky as I only
>>>> have 4 servers with this NIC/Problem, so modifying the eeprom is only
>>>> half an hour of my time, but this could be a much bigger issue elsewhere.
>>>>
>>
>> _______________________________________________
>> ipxe-devel mailing list
>> ipxe-devel at lists.ipxe.org <mailto:ipxe-devel at lists.ipxe.org>
>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>
> -- 
> Anton D. Kachalov
>
> ITO, R&D group, Senior System Engineer
> Tel: +7 (495) 739-70-00 ext.7613

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20120727/8cf6a85f/attachment.htm>