The MAC address should be pre-programmed (permanent) - every NIC should have a unique one, it's the lowest level of
ID on a network.. FF:FF:FF:FF:FF:FF is definitely NOT the right MAC address, this is the broadcast mac address, which all
NICs should receive, but no NIC will actually have that as an address.

If you want to know your actual MAC address, assuming you can make it send some network traffic, any packet "sniffer" (like
my DOS "sniff") should be able to see it - unless you are using an old-style hub, you will need to to send a broadcast so that
everything on a switch would see it. (not usually a problem - after reboot, and during most connection attemps at least
one broadcast will be sent).

I'm curious how that "FF:FF:FF:FF:FF:FF" card is seen from the outside - run "arp" on the other computer, and see what's the MAC for the problematic laptop's IP.

The NVRAM and the VPD memory on this NIC are definitely faulty. The B57UDIAG utility fails every write test to those areas, though tests on the normal (RAM), BCM registers, MII interface and similar all seemingly pass without issue.

Since I'd guess that the MAC address is loaded into NVRAM (based on the commands that the B57DIAG tool has available to programme it) my guess is that is why it is showing/set as FF:FF:FF:FF:FF:FF - though the Thinkpad BIOS screen also claims it to be 00:00:00:00:00:00 ... I think both are just symptoms of the fact that it cannot actually be read, and whatever is there is gibberish.

Though.... as Grzyb suggest, running arp on the Linux machine I connect to the laptop with using Filezilla does indeed show:

Address HWtype HWaddress Flags Mask Iface
192.168.1.232 ether ff:ff:ff:ff:ff:ff C enp3s0

It's dead, Jim.

DaveDDS wrote on Today, 18:09:

The MAC address should be pre-programmed (permanent) - every NIC should have a unique one

Although set with one by default, the diagnostic tool for the Broadcom chips absolutely can set the MAC address to anything you want - it's definitely not permanent since it's in writeable (eep)ROM and/or RAM areas in the NIC (which the diagnostic tools can write to)... though you have to write a relatively comprehensive 'EEPROM' definition file first. Something I've not looked at yet.... and quite honestly since the diag tests seem to fail when writing to those areas... I think that's why it has the symptoms it does.

So, the packets sent to that NIC are indeed broadcast packets.

It's likely that the switch limits broadcast traffic - effectively limiting that laptop's download rate, but not upload.
If it's a managed switch, it may be worth looking if there are some options related to broadcast limiting...

megatron-uk wrote on Today, 20:24:

DaveDDS wrote on Today, 18:09:

The MAC address should be pre-programmed (permanent) - every NIC should have a unique one

Although set with one by default, the diagnostic tool for the Broadcom chips absolutely can set the MAC address to anything you want - it's definitely not permanent since it's in writeable (eep)ROM and/or RAM areas in the NIC (which the diagnostic tools can write to)... though you have to write a relatively comprehensive 'EEPROM' definition file first. Something I've not looked at yet.... and quite honestly since the diag tests seem to fail when writing to those areas... I think that's why it has the symptoms it does.

Can you post a screenshot of this diag test showing the failing to write ?

anyway, fist time I ran into an issue like this, I just filled the eeprom with consecutive hex numbers, then booted the device, figured out which numbers were the mac and wrote the mac address that was on the physical label in the eeprom. Mostly ignoring the other data that could be of consequence, ie I just filled the rest with zeroes. This was on a mainboard with two integrated nics and both had lost their eeprom contents. The eeprom was just a 1 kilobyte, maybe 4, chip and actually lived on the shared i²c/smbus on the mainboard, which is likely the reason it somehow got zeroed out, and was also helpful in getting some data back in it without desoldering using linux.

VPD... does that stand for vital product data? the mac address seems pretty vital for a network interface, although setting it with software should be available & viable.

Also... is this on just one laptop or is it on all of them ? ( Dell Latitude X1, Toshiba Portege R200, IBM Thinkpad T43 )

Grzyb wrote on Today, 20:34:

So, the packets sent to that NIC are indeed broadcast packets.

It's likely that the switch limits broadcast traffic - effectively limiting that laptop's download rate, but not upload.
If it's a managed switch, it may be worth looking if there are some options related to broadcast limiting...

No.
Fixing the faulty mac address is the way to go.

Also, I've just tried to add the following line:

NodeAddress="000102030405"

...to the [B57] section of PROTOCOL.INI
And it works as expected - the other side shows "00:01:02:03:04:05" in the ARP table...

Edit:

But can't get it to work for ODI - adding the following to NET.CFG :

Node Address 021122334455

The "locally administered" bit is set.
Without that bit, the ODI driver complains when loading.
With that bit, it loads normally, but doesn't change the MAC.
Oh well, I guess it's not implemented in this driver - use NDIS instead!