search for: icyb

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

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

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

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

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

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

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

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

Hi all! I have problem with Samba and NT 4.0 workstation. I configured Samba 1.9.17p2 under FreeBSD so some directories became accessible from Windows 95. But when I tried to access them from NT Workstation, I received error message : System error 1240 has occurred. The account is not authorized to login from this station. Both machines are in domain, [global] section looks like : [global]

Maybe this is already fixed in the newer code, I am still on 5.2.1 and have a problem with traffic that originally goes to a broadcast ip address but then gets encrypted by ipsec and should go into a tunnel but when it is sent it has ethernet broadcast flag. Just to be clear: traffic originates on the same host which is a tunnel endpoint. It looks to me that a fix could be as simple as clearing

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

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

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

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

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

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