14.0 ’arp -a’ creates a crash

E

escape

Has anyone noticed that arp is not working correctly in FreeBSD 14.0? After installing new 14.0-RELEASE the first symptom was that the network connection did not work if there were static arp-pairs in rc.conf . Second symptom was that running
Bash: 
arp -a
created a witness dump and the OS rebooted.

Where can I read about the changes made to check when the arp will be working again, is it just the email list?

There was a photograph of the dump message but it is not available right now to include the text here (maby later). Is this an incorrect network card driver related matter?
 
It's working for me on 14.0-RELEASE-p5 will update now to p6 and will test again.

Edit:
it's also working on 14.0-RELEASE-p6
 
ARP works fine here too. But I don't have any static ARP entries. Why are you adding static entries?
 
IMG_0247.jpeg

14.0-RELEASE-p6
 
Last edited:
I can make arp -a unhappy but not sure if what I'm doing is meaningful or not. Not sure if any of my MAC address are super-secret but put a few XXs in just in case.
Code: 
root@r220:/home/user # arp -a
? (192.168.1.233) at XX:XX:XX:XX:XX:4e on bge0 permanent [ethernet]
? (192.168.1.1) at XX:XX:XX:XX:XX:58 on bge0 expires in 1200 seconds [ethernet]
? (192.168.1.84) at XX:XX:XX:XX:XX:fc on bge0 expires in 1109 seconds [ethernet]
? (172.16.0.233) at XX:XX:XX:XX:XX:50 on bge1 permanent [ethernet]
root@r220:/home/user # arp -s 172.16.0.233 XX:XX:XX:XX:XX:50  (so just the same details as the last line in -a)
arp: set 172.16.0.233: Operation not permitted
root@r220:/home/user # arp -a
? (192.168.1.233) at XX:XX:XX:XX:XX:4e on bge0 permanent [ethernet]
(time passes)
^C^C^C^C^C (try to kill it)
load: 2.22  cmd: arp 1180 [tq_qdrain] 906.66r 0.00u 0.00s 0% 2596k
And it will sit there until reboot. No crash. FreeBSD 14.0-RELEASE-p6. (Ignore the load I'm also doing other stuff on the machine).
 
Sorry it took a while. I have another 14.0 device and it does not have this feature.

richardtoohey2 said:
Is there still a crash if you remove those?

Obviously you are getting a crash but you aren’t providing enough information for anyone to reproduce the issue.
Click to expand...

If the static routes are removed from rc.conf, there is no crash.

Following additional options compared to the GENERIC are still in effect in this modified kernel config:

Code: 
device pf
options ALTQ
options LIBALIAS

device gre
device wg

options MROUTING
options IPDIVERT
options IPSTEALTH

options DUMMYNET

The if_bridge was a suspect but the arp -a at least jams without it.


Edit 12. April:
Static routes is a typing error. It should read static ARP pairs.
 
Ok and most network cards were removed without device em and the rest of Intel devices after this. The network device appearing is igb. There are VLANs and a tun interface.
 
What happens on a standard 14.0 RELEASE?

Probably works - no-one else (so far) sees the crash.

If that works then you know one of your changes breaks it.

So you can try each change until you find the change(s) that trigger this crash. Or if the standard install works, use that.
 
@OP - Are you using a driver that you converted/loaded using ndisgen and then kldload-ed by any chance? Till date 'ifconfig destroy' hangs FreeBSD for lots of broadcom and some other wifi cards.
 
According to man page of ndisgen from FreeBSD 12 this is Windows compatibility. No, there were no kernel modules like that. ndisgen() was not installed. The FreeBSD 14 man page is missing.

There were no ifconfig destroy commands either because the machine was rebooted before the next tries.
 
escape said:
14.0-RELEASE GENERIC with the mentioned changes.
Click to expand...
Please, never modify GENERIC. We have to assume GENERIC has a certain configuration. Make a copy and change the ident of the kernel if you want to customize it.

Revert your changes and test with a real GENERIC kernel (not your modified version).
 
When somebody asks you if you're running GENERIC they are asking if you're using kernel (and/or modules) that are shipped with the given release. Even if you take GENERIC kernel config and recompile it you're using custom kernel.

First you should test your config running on GENERIC. If you can't state why you can't use GENERIC kernel.
Then you should share the minimal configuration of yours where you can trigger panic so others can have a look took and test.
 
arp.png

Just took another try and posted the new image again. It is similar.

Is it possible that the hardware is broken?

Added to the GENERIC were these. Additionallly some network card drivers were removed:
Code: 
device pf
options ALTQ
options LIBALIAS

device gre
device wg

options DUMMYNET
 
Please share your rc.conf and/or any other non-standard configuration you're using so we can replicate that.
Also test this on proper GENERIC kernel. if_gre.ko, if_wg.ko and pf.ko can be loaded (/boot/loader.conf), you don't need to recompile kernel for that. yes, altq/libalias won't be in effect but it's worth the test.

Without that nobody is able to tell you what's wrong because we can't reproduce that. My wild guess is wireguard issue but that's just .. well, wild guess.
 
escape said:
Is it possible that the hardware is broken?
Click to expand...
Yes and that is why everyone is telling you to start with a standard kernel.

If a standard kernel works then it’s not so likely to be hardware.

You‘ve got to start with a solid baseline and then go from there.

You do not seem to want to do that so no-one can really help.
 
It looks like that after freebsd-update fetch; freebsd-update install the kernel was "GENERIC" and the problem persists. Removing all of the previous kernel config -file lines the problem persists.
 
richardtoohey2 said:
...
You do not seem to want to do that so no-one can really help.
Click to expand...

Sorry about that. The server is a residential gateway, a router and really important and I have time mostly some hours in the evenings. There is an open internet next and at least someone is trying randomly all of the ports. It has been jammed because of unbound too often. This is the operators lease line network.
 
You must log in or register to reply here.
Back
Top