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 Yesterday, 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 Yesterday, 20:24:

DaveDDS wrote on Yesterday, 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 Yesterday, 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!

megatron-uk wrote on Yesterday, 20:24:

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.

Kinda suprising ... the MAC is supposed to be unique .. vendors are assigned range which they must set their card to in
production.

If you provide a tool to allow an end-user to set the MAC to an arbitrary value, you violate this.

The reason they must be unique is that two NICs with the same MAC address can't talk to each other,
and cause confusion in local network/switch addressing. Originally this was envisuned as being the
"network address", but as networking methods progressed, routable protocols were developed which
separate the endpoint MAC address from the network address. This (among other things) allows network
addresses to be reassigned to different systems (which have different MACs)

In practice, given how many NICs there are in the world, the chances of two changed to the same address
being on the same local network are very minimal... In fact there is an OUI prefix reserved for "locally
unique only" MACs which are set within an organization.

Btw, I often see FF:FF:FF:FF:FF:FF reported as the MAC address for a non-working/mis addressed card.
There are a few packet drivers which don't detect that a card is not responding correctly, and these often
report FF:FF:FF:FF:FF:FF (more often than 00:00:00:00:00:00) when the NIC just "isn't there".

Grzyb wrote on Yesterday, 20:34:

... 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...

Almost all networking will stop working if you prevent broadcast on those nodes.

And "flooding" broadcast will bog-down and confuse networks.

There are reasons we use broadcast, and also why we limit broadcast traffic.

The only case where I can envision that this "might" work is on a dedicated hub with no other nodes.
and even then most network software would get confused by excessive unexpected broadcasts and data
packets addressed as broadcast ...

I don't think even DDLINK would work, it only uses one broadcast by the client to find the server,
then uses directed MACs only ... but it's been >10 years since I wrote it, and don't recall if it checks to
see/ignore broadcast packets during that transfer (probably does as broadcasts could still come from
the other end if running under a multi-thread OS)

Easy to test -- DosBox can simulate an NE2000 NIC, and you can set what its MAC address is...

Easy to test -- DosBox can simulate an NE2000 NIC, and you can set what its MAC address is...

Hi, please everyone note that some emulators don't do ethernet protocol emulation but rather use pass-through to host. I vaguely remember reading about this.
So it won't work with WiFi connection, for example. The physical LAN connection must be same ethernet.

DOSBox does not have NE2000 emulation, that would be a fork of some sort.

Grzyb wrote on Yesterday, 20:57:

Also, I've just tried to add the following line: […]
Show full quote

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!

🤣 ... it only damn works...

1$ arp
2Address                  HWtype  HWaddress           Flags Mask            Iface
3192.168.1.232            ether   00:0d:b6:00:00:01   C                     enp3s0

Speeds are now largely symmetrical - around ~13-14 Megabytes/sec both up and down when using Filezilla on my Linux desktop to the MTCP ftpsrv server.

Using the MTCP ftp client against vsftpd it is showing ~7-8 Megabytes/sec.

This is using B57.DOS v11.0.8 - I've not tried any others. And, of course, this doesn't fix the underlying issue of the NIC NVRAM/EEPROM being totally busted - since the Linux driver relies on those things (I guess the Win9x/NT/XP drivers probably do too). But, it is a pretty cool workaround for DOS!

Using a large ISO (~560MB) I now see that the transfer rates using Filezilla against ftpsrv are more or less identical using the different versions of B57.DOS:

B57.DOS v11.0.8
B57.DOS v15.0.1
B57.DOS v16.0.2

All versions of the driver get within +/- a few hundred kilobytes of each other, and those figures are ~14.8 megabytes download and ~12.5 megabytes upload, so the NIC is definitely working at above Fast Ethernet speeds (though depending on your metrics - just barely 🤣).