wait, did this change at some point?

No, I just necromanced into code that was idle for 22 years. The AF_ARP case was copied from if_ethersubr.c when @dfr added if_fwsubr.c in 2004.

The trimming may have actually been correct at the time. But if_ether.c has had 1.2k commits since then, and nobody was retesting FireWire ARP.

This is not something that made networking unusable, I just have verbose and debug logging enabled, which is how I noticed it.

@bz, @glebius, @melifaro, etc: can you help confirm that this is change is correct?

It seems like it's the right thing to do to my untrained eye, but I don't know all of the [current] nuances of our networking stack.

Some other research I just did.

Linux implements ARP over IEEE1394 like this:

• https://github.com/torvalds/linux/blob/53c7db5c1916afcecc8683ae01ff8415c708a883/drivers/firewire/net.c#L206-L207
• https://github.com/torvalds/linux/blob/53c7db5c1916afcecc8683ae01ff8415c708a883/drivers/firewire/net.c#L223-L227

NetBSD implements ARP over IEEE1394 like this:

• https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ieee1394/if_fwip.c?rev=1.31.10.1;content-type=text%2Fplain

My guess is that OSX would be the gold standard implementation of IEEE1394 though.

The latest version (before they completely pulled IEEE1394 support from their products) seems to support either specifying a target address, or broadcasting ARP packets to entire (networks/fabrics/etc? not sure the nomenclature):
https://github.com/apple-oss-distributions/IOFireWireIP/blob/cff24dfbfc7170b3af0c1d3b9894f3eab2365551/KernelSource/BSD/if_firewire.cpp#L192-L196

Were there any RFCs that superseded the one referenced?

In D57617#1321864, @ngie wrote:

Were there any RFCs that superseded the one referenced?

No, if it were, it would be mentioned, like this one:
https://datatracker.ietf.org/doc/html/rfc2460 (look for "Obsoleted by" or "Updated by")

Unfortunately, I don't know much about ARP implementation on anything other than ethernet.

In D57617#1321866, @pouria wrote:

In D57617#1321864, @ngie wrote:

Were there any RFCs that superseded the one referenced?

No, if it were, it would be mentioned, like this one:
https://datatracker.ietf.org/doc/html/rfc2460 (look for "Obsoleted by" or "Updated by")

Yeah 👍.

Unfortunately, I don't know much about ARP implementation on anything other than ethernet.

I'll look at the code again (FreeBSD with this driver and with another driver, vs the OSX implementation). There might be a nuance that I'm missing..

Did you check interoperability vs OS X or Linux? If this change is correct then firewire interface was not functional for many years and nobody noticed that. This raises question on whether it needs to be kept in FreeBSD at all.

AFAIK, the only real firewire application today is dumping data from old but expensive professional video cameras.

This code originates from the very beginning of firewire and it is not a copy from ether_output().

In D57617#1323362, @glebius wrote:

Did you check interoperability vs OS X or Linux? If this change is correct then firewire interface was not functional for many years and nobody noticed that. This raises question on whether it needs to be kept in FreeBSD at all.

AFAIK, the only real firewire application today is dumping data from old but expensive professional video cameras.

Connecting OS X and Linux + verbose mode is what showed the error. The driver did work for file transfer without this fix.

Firewire is not used only in cameras. Industrial machines used it a transport layer, they still depend on an OEL version of MACOS. There are also old audio hardware that can be controlled via firewire (The racks don't have to be replaced every year)

ok, if you have tested it between macosx and linux and freebsd then that's good enough for me.

(Hopefully next week i'll be in a situation to test firewire again.)