similar to: ipsec vs. broadcast

Not sure if this is a bug or a feature, but it seems like potential security risk: I have a ufs fs mounted rw+nosuid, then I needed to downgrade it to ro, so I executed mount -u -r on it - imagine my surpise when I found that nosuid flag was removed as well. I know I could have used mount -u -r -o nosuid, but the present behavior seems to be non-obvious (update one flag, orthogonal flags dropped

Are there any tools to decode encrypted part of isakmp provided that identities of both peers are known to me and that I am able to observe the whole exchange ? -- Andriy Gapon

I've just realized that I see in releng/7 something that I did not see in releng/6 - even if I use a file with custom rules in firewall_type I still get default loopback rules installed. I think that this is not correct, I am using custom rules exactly because I want to control *everything* (e.g. all deny rules come with log logamount xxx). -- Andriy Gapon

After some poking into psm.c code I've got some results. First, for the archives, debug.psm.loglevel tunable is much more useful than a verbose boot for debugging PS/2 mouse issues. A good value is 2. Second, I fiddled with various probe methods to force them to "recognize" my mouse (by loosening their checks) and found out that the mouse works perfectly if it is treated as

I have an NFS server and NFS client separated by a firewall. Both servers are FreeBSD 7.1. Server configuration: nfs_server_enable="YES" nfs_server_flags="-t -n 4" rpcbind_enable="YES" mountd_flags="-r -p 737" mountd_enable="YES" The firewall allows tcp and udp to port 111, but only tcp to ports 2049 and 737 (configured for mountd, see above).

System: FreeBSD 7.1-STABLE i386 (revision 187025) Panic message: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0xd2006ad0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc05623aa stack pointer = 0x28:0xdd4f6c34 frame pointer = 0x28:0xdd4f6c40 code segment

This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: <16550A-compatible COM port> port

I wouldn't report this if not for one coincidence (which is described below). I have too little facts, so this is more of a mystery problem tale than a real problem report. There are two systems: 1. old, slow, i386, UP, 7-STABLE 2. new, fast, amd64, MP, 6.3-RELEASE Systems are located at different physical locations. What is common between them: 1. they both have the same backup strategy

I have a semi-theoretical question about the following code in arc.c, arc_reclaim_needed() function: /* * take ''desfree'' extra pages, so we reclaim sooner, rather than later */ extra = desfree; /* * check that we''re out of range of the pageout scanner. It starts to * schedule paging if freemem is less than lotsfree and needfree. * lotsfree is the high-water mark

Now that we have very convenient -C option for fsck, maybe we could use it in fsck_y_enable part of rc.d/fsck? -- Andriy Gapon

I have the following line in /etc/ttys: ttyv8 "/usr/local/bin/kdm -nodaemon" xterm on insecure Because of X misconfiguration it constantly crashed, so: kdm-bin[1178]: Unable to fire up local display :0; disabling. So I fix xorg.conf, then I change on => off in ttys, then I do kill -1 1, and X gets started! Seems illogical. Or maybe kdm-bin does something "smart"

I'm trying to make devd run an stty command whenever a USB serial device is attached. Unfortunately, $device-name is ucom[0-9] and the device names are /dev/cuaU[0-9] - how do I get the correct name in the device action? I haven't found a way to extract the number by itself, so I'm stuck with specifying a separate rule for each number, like so: attach 100 { device-name

550.ipfwlimit check in /etc/periodic/security takes into account only global/default verbosity limit and does not account for a specific logging limit set for a particular rule e.g.: $ ipfw -a l | fgrep log 65000 *521* 41764 deny log logamount *1000* ip from any to any $ sysctl -n net.inet.ip.fw.verbose_limit *100* >From security run output: ipfw log limit reached: 65000 519

On Tue, Apr 15, 2008 at 12:20 PM, Roland Smith <rsmith@xs4all.nl> wrote: > On Tue, Apr 15, 2008 at 11:34:31AM -0700, Steve Franks wrote: > > Being a naturally curious guy, with your pointers, I've located the following: > > > > [steve@dystant /var/crash]$ sudo cat info.2 > > Yep. This is what you need. > > > > Dump header from device

Hello all, I am configuring a vpn between freeswan and windows 2000. I am following the steps at http://www.jacco2.dds.nl/networking/win2000xp-freeswan.html, to get the VPN up and running. using this I have a ppp tunnel between windows and linux, which is inside a l2tp tunnel which is again encrypted by IPSec. (the url gives the configuration in detail and I have followed it exactly) Now the

when booting stable/9 under a debug kernel with WITNESS enabled and verbose I get the following panic.. It seems very much like the discussion from a year back on current: http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031375.html Any ideas? uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1 uhub0: 2 ports with 2 removable, self powered uhub1: 2

Hi All, I have what I think is a ZFS related bug. Unfortunately my simplest test case is a bit cumbersome and I haven't definitively proven that the problem is ZFS related. I'm hoping for some feedback on how to move forward. Quick background: I rip my CD's using grip and produce flac files. I tag the music using Musicbrainz' Picard and transcode it to mp3's within Picard

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of

Hi all, I am using an USB memory stick as cache and log devices for a HDD ZFS pool named tank0: $ zpool status -v tank0 pool: tank0 state: ONLINE scan: scrub repaired 0 in 7h19m with 0 errors on Tue Jul 30 06:11:23 2013 config: NAME STATE READ WRITE CKSUM tank0 ONLINE 0 0 0 ada0s1d ONLINE 0 0 0 logs gpt/SLOG