[Bug 281361] ddclient: messages about unknown DHCP option keep cluttering the log
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281361 Bug ID: 281361 Summary: ddclient: messages about unknown DHCP option keep cluttering the log Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: mich...@vonglasow.com I keep getting the following error message in the log every time the IP config on the external interface is renewed (15 minutes with my ISP): > Error:dhclient:unknown dhcp option value 0x7d **To Reproduce** Steps to reproduce the behavior: * Set up a network with a DHCP server. * Configure the DHCP server to send an unknown DHCP option (0x7d is known to work) * Configure a short timeout (under an hour) for DHCP leases. * Configure DHCP on one interface, and connect it to the network with DHCP server configured in the previous steps. * Observe the log **Expected behavior** I would expect ddclient to silently ignore any options it does not understand (which is the recommended standard behavior for most parsers). If it does log a message at all, the log level should be Debug or Information at most, not Error. **Describe alternatives you considered** Reconfiguring the DHCP server to not set any obscure options ddclient does not need or understand is not an option: the DHCP server is beyond my control (I probably won’t get my ISP to configure their DHCP server the way I think it should be), and since lease times are such that renewals happen every 15 minutes, this really clutters up the logs. There may certainly be legit use cases why a DHCP server would specify DHCP options which some DHCP clients do not understand. **Additional context** I’ve verified DHCP traffic with a packet capture tool, and the DHCP offer indeed does have the unsupported option in it. The log entry has been around for a few versions and might have been present ever since I started using OPNsense on that particular ISP. It makes the logs hard to read when you’re trying to debug something, especially since it is logged as an error. The lower the log level, the easier it is to filter out. Should I have filed this bug against the wrong component, please feel free to move it or let me know where it should go. **Environment** OPNsense 24.7.3_1-amd64 (based on FreeBSD 14.1-release-p3); Franco Fichtner suggested I file my issue as a bug here (however, I don’t agree with him that this is just a minor annoyance) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281352] bsdinstall(8) Error while extracting lib32.txz with "Can't unlink already-existing object"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281352 --- Comment #1 from porok...@gmx.com --- Could not reproduce. Didn't specify: before and now filesystem choice is UFS. Maybe it had something to do with the fact one ftp mirror (latvia) failed to download some -dbg.txz etc. errored out yet perhaps still extracted some, then I cancelled restarted install that maybe somehow didn't reformat the storage to clean state. Needs more people stumbling upon this error to narrow down the cause. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #66 from Tomasz "CeDeROM" CEDRO --- ACK :-) TANK U :-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 238006] syslogd not starting because of missing /var/run/log
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238006 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #7 from Mark Johnston --- Created attachment 253432 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253432&action=edit proposed patch Here's a patch and test case which I believe will fix the problem. Some testing would be appreciated. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281332] tzsetup creates broken symlink after 5e16809c953f (main) and fc43a1b6842a (stable/14)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281332 Mark Linimon changed: What|Removed |Added Keywords||regression Assignee|b...@freebsd.org|ema...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281279] nfscl: panic: MSan: Uninitialized stack memory in nfscl_cberrmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281279 Alan Somers changed: What|Removed |Added CC||rmack...@freebsd.org --- Comment #4 from Alan Somers --- I think I've found the source of the problem: Firstly, my environment is a 15.0 client and a 14.1 server. The client uses nfs 4.2 for /usr/home and I run nfsuserd on both client and server. I have no NFS tunables set on the client. What happens is that: 1) When I run "whoami", my shell does an append write to /usr/home/somers/.local/share/fish/fish_history 2) ncl_writerpc allocate "struct nfsvattr nfsva" on the stack, on its first line, but does not initialize it. 3) The AppendWrite RPC returns from the server. Wireshark shows that the compound RPC includes SEQUENCE, PUTFH, GETATTR, VERIFY, WRITE, and GETATTR. But the attr masks for neither GETATTR contain Owner. 4) So nfsv4_loadattr returns without initializing nap->na_uid . Note that if I insert logic to set na_uid to 666 in step 2, it is still equal to 666 here. 5) control returns two levels up the stack back to ncl_writerpc 6) which calls nfscl_loadattrcache. At line 522 that function calls NFSBCOPY to actually copy the attributes into NFS's attribute cache, and at that point na_uid is still uninitialized. Later, the shell stat()s the fish_history file. That reads the uninitialized na_uid attribute from NFS's attribute cache, triggering the MSAN panic above. But what can we do about it? I have a patch that sets na_uid=na_gid=VNOVAL in nfsv4_loadattr. That makes the MSAN warnings go away. And yet, I'm not convinced that it's the correct solution. After all, I've never actually seen the wrong uid or gid displayed by "ls", which suggests that it's getting set somehow, even if MSAN doesn't know it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281279] nfscl: panic: MSan: Uninitialized stack memory in nfscl_cberrmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281279 Mark Johnston changed: What|Removed |Added Status|New |Open --- Comment #5 from Mark Johnston --- (In reply to Alan Somers from comment #4) > After all, I've never actually seen the wrong uid or gid displayed by "ls", > which suggests that it's getting set somehow, even if MSAN doesn't know it. What if you stat(1) just the one file? ls is using fts(3), which perhaps stats something like "." before the file in question, so the struct stat is already pre-populated with the "right" value. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 45568] [ahc] ahc(A19160) pci parity error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=45568 Mark Linimon changed: What|Removed |Added Status|Open|Closed Resolution|--- |Feedback Timeout --- Comment #6 from Mark Linimon --- ^Triage: feedback timeout ( >6 months). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281279] nfscl: panic: MSan: Uninitialized stack memory in nfscl_cberrmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281279 --- Comment #6 from Alan Somers --- (In reply to Mark Johnston from comment #5) If I stat the one file, then everything is fine. MSAN doesn't even trigger. It's the append write that introduces the uninitialized data. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281279] nfscl: panic: MSan: Uninitialized stack memory in nfscl_cberrmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281279 Alan Somers changed: What|Removed |Added Assignee|b...@freebsd.org|asom...@freebsd.org Attachment #253436||maintainer-approval?(rmackl Flags||e...@freebsd.org) --- Comment #7 from Alan Somers --- Created attachment 253436 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253436&action=edit Initialize previously uninitialized fields in nfsv4_loadattr Rick, does this patch look ok to you? -- You are receiving this mail because: You are the assignee for the bug.
Problem reports for b...@freebsd.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- New |252123 | fetch(3): Fix wrong usage of proxy when request i New |262764 | After DVD1 13.0-R install with ports tree, portsn New |262989 | sys/conf/files, sys/conf/options, sys/conf/NOTES: New |269994 | build options have different kernel and userland New |276571 | makefs(8) creates broken UFS images with sectorsi New |279203 | killpg(): Forking fast leads to livelock Open| 46441 | sh(1): Does not support PS1, PS2, PS4 parameter e Open|165059 | vtnet(4): Networking breaks with a router using v Open|177821 | sysctl: Some security.jail nodes are funky, dupli Open|220246 | syslogd does not send RFC3164-conformant messages Open|250309 | devmatch: panic: general protection fault: sysctl Open|255130 | Issue with rtsx driver Open|256952 | kqueue(2): Improve epoll Linux compatibility (com Open|257149 | CFLAGS not passed to whole build Open|257646 | opensm: rc service is installed by default, but o Open|258665 | lib/libfetch: Add Happy Eyeballs (RFC8305) suppor Open|259292 | vmware/pvscsi: UNMAP fails on VMWare 6.7 thinly p Open|259636 | multiple components: Change "Take Affect" to "Tak Open|259655 | periodic: security/security.functions does not re Open|259703 | In sys/dev/pci/pci.c, error in do_power_nodriver Open|259808 | etc/periodic/daily/100.clean-disks: Fix error (Di Open|260214 | acpi_battery: Should provide current/max battery Open|260245 | swap/vm: Apparent memory leak: 100% swap usage Open|261640 | sysctl: Add -F option to display sysctl format st Open|261641 | drm-kmod: Launch message is written into (possibl Open|261771 | nvme(4): Reports errors every 5 minutes: PRP OFFS Open|261971 | kernel crash launching bhyve guest on ZFS: #15 bu Open|262157 | su+j: Crashes during mmc(4) fsck after timeout: E Open|262192 | Crashes at boot with kern.random.initial_seeding. Open|264028 | loader: Incorrect (32gb) memory reported by BTX l Open|264075 | freebsd-update in 13.1-RELEASE detects an install Open|264188 | kinit(1): Ignores KRB5CCNAME environment variable Open|264195 | Fix cross-building from macOS for newversh.sh and Open|264226 | setting kern.vty=sc causes hang during UEFI boot Open|264833 | 12.3-STABLE panic on sync and reboot: panic: slee Open|266419 | mrsas: Corrupts memory (crashes) when reading dat 36 problems total for which you should take action.
[Bug 280418] calendar -a trashes parent's pgrp login setting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280418 Philip Paeps changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #17 from Philip Paeps --- Erratum issued: https://www.freebsd.org/security/advisories/FreeBSD-EN-24:15.calendar.asc -- You are receiving this mail because: You are on the CC list for the bug.
