@tuexen is currently looking to create standard compliant packetdrill scripts to check various test cases.

In D58096#1334930, @zlei wrote:

@pouria @adrian Do you want me to commit it now ?

In D58096#1335659, @vinicius_ferrao.net.br wrote:

In D58096#1334930, @zlei wrote:

@vinicius_ferrao.net.br I do not have IB devices so not able to test. Would you please test against stable/15 after I commit it ?

Hi @zlei, I've double checked and yes, everythinig was working. I was able to replicate the issue without the patch and them checking the fix after applying it and rebuilding the kernel.

In D58096#1334930, @zlei wrote:

@vinicius_ferrao.net.br I do not have IB devices so not able to test. Would you please test against stable/15 after I commit it ?

In D58096#1333045, @pouria wrote:

It's really hard to MFC this change to stable/15.

In D58096#1333064, @vinicius_ferrao.net.br wrote:

Yes. How is the procedure? I should open other Phabricator review or just attach a patch here?

In D58096#1333045, @pouria wrote:

It's really hard to MFC this change to stable/15.
Could you please prepare a patch for stable/15 too?
If you're willing to do that, I could talk to release manager.

It's really hard to MFC this change to stable/15.
Could you please prepare a patch for stable/15 too?
If you're willing to do that, I could talk to release manager.

In D58096#1332939, @vinicius_ferrao.net.br wrote:

Yes, please @pouria.

I've tested the new changes against CX-6 and CX-5, but only on x86_64. Everything is working so far. I've also run this patch in a stress test in the context of another project (a NFS over RDMA server, which is how I found out about this issue in first place) and it worked.

To test the redirect I've used 3 VMs, being a FreeBSD router plus two Linux clients. Both input and output worked fine from everyone.

we can merge it into stable/15 before its cut and/or ask the release manager to merge it from stable/15 to the release branch after its cut but before its released.

I've tested the new changes against CX-6 and CX-5, but only on x86_64. Everything is working so far. I've also run this patch in a stress test in the context of another project (a NFS over RDMA server, which is how I found out about this issue in first place) and it worked.

Do you want me to commit this one? @vinicius_ferrao.net.br

I'm new to this Phabricator thing, and didn't thank @pouria correctly, because I clicked 'submit' too early.

Address @pouria requests

Nice catch! Thank you for your contribution.
IMHO, we simply need to make sure the length of our nd_opt header is align to octets.

In D58096#1332339, @adrian wrote:

Oh this is a good catch! I was just about to put some cx6 NICs in some boxes here to test.

Just to be complete - did you also test the non-IB case? (straight up ipv6 over ethernet at least.)

In D58096#1332288, @glebius wrote:

Can you please make the pad variables unsigned? (and while here the associated length variables as well)

Address @glebius requests

Oh this is a good catch! I was just about to put some cx6 NICs in some boxes here to test.

Can you please make the pad variables unsigned? (and while here the associated length variables as well)

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

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.

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

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.

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")

In D57617#1321864, @ngie wrote:

Were there any RFCs that superseded the one referenced?

Some other research I just did.

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

In D57537#1321192, @gallatin wrote:

@gallatin Do you want to commit this, or should I? (Reid doesn't have a bit, so someone else needs to.)

If you could push it, that would be great.

Will do.

In D57537#1321127, @kp wrote:

In D57537#1319082, @gallatin wrote:

It took me a while, but I think your patch is correct.

@gallatin Do you want to commit this, or should I? (Reid doesn't have a bit, so someone else needs to.)

In D57537#1319082, @gallatin wrote:

It took me a while, but I think your patch is correct.

Hi, I have a patch for media in aue that should work, can you test please:

It took me a while, but I think your patch is correct.

In D57537#1319074, @kgalazka wrote:

Shouldn't this be actually handled by this condition? (https://cgit.freebsd.org/src/tree/sys/net/iflib.c#n2969)

/* was this only a completion queue message? */
if (__predict_false(ri.iri_nfrags == 0))
	continue;

I mean if a packet is discarded does it need to use any iri_frags?

Shouldn't this be actually handled by this condition? (https://cgit.freebsd.org/src/tree/sys/net/iflib.c#n2969)

/* was this only a completion queue message? */
if (__predict_false(ri.iri_nfrags == 0))
	continue;

I mean if a packet is discarded does it need to use any iri_frags?