Page MenuHomeFreeBSD

Improve ARP logging
ClosedPublic

Authored by bz on Mar 7 2019, 12:24 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 12:55 AM
Unknown Object (File)
Fri, Nov 8, 12:27 AM
Unknown Object (File)
Thu, Nov 7, 4:45 PM
Unknown Object (File)
Oct 18 2024, 3:27 AM
Unknown Object (File)
Oct 18 2024, 3:27 AM
Unknown Object (File)
Oct 2 2024, 7:36 PM
Unknown Object (File)
Sep 18 2024, 7:02 PM
Unknown Object (File)
Sep 12 2024, 2:35 AM
Subscribers

Details

Summary

r344504 added an extra ARP_LOG() call in case of an if_output() failure. It turns out IPv4 (especially when dhclient is running) can be noisy. In order to not spam the console by default: (a) add a counter for these events so people can keep better track of how often it happens, and (b) add a sysctl to select the default ARP_LOG log level and set it to INFO avoiding the one (the new) DEBUG level by default.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Should add: X-MFC: never.

sys/net/if_arp.h
106 ↗(On Diff #54793)

I added the extra white line in order to also separate tx from rx counters. I can remove it if people feel it is noise.

sys/net/if_arp.h
104 ↗(On Diff #54793)

Putting txerrors here shifts the elements between it and arp_spares. That presumably breaks compatibility even though the size of the structure does not change. Does netstat print any of these?

sys/net/if_arp.h
104 ↗(On Diff #54793)

Yes, netstat does print these (netstat -s -p arp), see change below.

I can play nice and not break netstat inside HEAD (no MFC planned) and have rx and tx counters intermixed in the structure if that will help for 12->13 upgrades (where we don't guarantee stability but still try to play nice). Should I?

Re-sort the struct fields to not change the expected order and use a spare field in-place. That will help netstat to continue working when updating from 12->13 without shuffling the values around.

bz marked an inline comment as done.Mar 7 2019, 11:18 PM

This seems good to me. If this is not to be MFC'd, compatibility wouldn't matter (in which case I wouldn't have reduced the number of spares). It's nice to have things in order, but maybe this isn't the time to break compatibility given the small scope.

This revision is now accepted and ready to land.Mar 7 2019, 11:46 PM
This revision was automatically updated to reflect the committed changes.