freebsd-hackers-digest V5 #723
owner-freebsd-...@freebsd.org
freebsd-hackers-digest Tuesday, February 18 2003 Volume 05 : Number 723
In this issue:
RE: IPC and jail.
Re: IPC and jail.
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
Re: debugging a repeating panic that does not produce a dump
[none]
RE: IPC and jail.
Results: what userland files are necessary for an installworld?
DHCP problem with pxeboot over wireless via LinkSys WAP11
lost filesystems, recovery
DHCP Client DoS
Re: DHCP Client DoS
Re: DHCP Client DoS
Re: DHCP Client DoS
Simple question about profiling
----------------------------------------------------------------------
Date: Mon, 17 Feb 2003 10:24:46 -0800
From: "Mooneer Salem" <moo...@translator.cx>
Subject: RE: IPC and jail.
Hello,
PostgreSQL might be a good test, since it uses IPC to an extent. I also have
some
code for 5.0 that adds a struct prison pointer to the IPC primitives for
tracking purposes.
Although it doesn't give each jail its own IPC cache, it does ensure they
don't step on each
other. For the purpose of seperating the jail from the main environment
though, your approach
may be better.
Thanks,
- --
Mooneer Salem
GPLTrans: http://www.translator.cx/
lifeafterking.org: http://www.lifeafterking.org/
- -----Original Message-----
From: owner-free...@FreeBSD.ORG
[mailto:owner-free...@FreeBSD.ORG]On Behalf Of Pawel Jakub Dawidek
Sent: Monday, February 17, 2003 9:39 AM
To: freebsd...@freebsd.org
Cc: ch...@aims.com.au
Subject: IPC and jail.
Hello hackers.
I'm preparing a patch against FreeBSD 4.7 (for now) which splits IPC zones
between jails and main host. Every entity will have his own IPC memory
not shared with others (jails or main host). Message queues are already
patched, but it need to be tested - that's why I'm writing.
Does anybody have any regression tests for IPC functionality?
If not, which program use it and will be a good test?
Thanks.
- --
Pawel Jakub Dawidek
UNIX Systems Administrator
http://garage.freebsd.pl
Am I Evil? Yes, I Am.
------------------------------
Date: Mon, 17 Feb 2003 19:25:55 +0100
From: Thierry Herbelot <thi...@herbelot.com>
Subject: Re: IPC and jail.
Hello,
PostGreSQL (see the ports) is one (big) program which is difficult to set up
in a pure jail, as it uses shared memory : it could be a good candidate for
your test.
you may want to have first a patch against -Current, as this is the "One True
Way" to introduce a new functionality to FreeBSD (futhermore, -Current is
quite stable, these days)
TfH
------------------------------
Date: Mon, 17 Feb 2003 19:50:24 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: debugging a repeating panic that does not produce a dump
Mike Tancsa <mi...@sentex.net> writes:
> I am seeing a repeatable panic with a 4.x SMP machine (not when in uni
> mode). It never produces a crash dump, but always panics when periodic
> runs.
Hmm, it doesn't even seem to *try* to dump... are you sure you have
configured a dump device?
> instruction pointer = 0x8:0xc0174830
This is the address of the instruction which caused the fault. You
can run nm(1) on your kernel to find out where in the kernel that is,
e.g.:
# nm /kernel | grep \^c0174 | sort
this should give you a list of maybe a dozen symbols; the one you want
is the last one in the list that has a lower address than c0174830.
How do you build your kernels - 'make buildkernel' or manually?
DES
- --
Dag-Erling Smorgrav - d...@ofug.org
------------------------------
Date: Mon, 17 Feb 2003 14:29:26 -0500
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: debugging a repeating panic that does not produce a dump
At 07:50 PM 17/02/2003 +0100, Dag-Erling Smorgrav wrote:
>Mike Tancsa <mi...@sentex.net> writes:
> > I am seeing a repeatable panic with a 4.x SMP machine (not when in uni
> > mode). It never produces a crash dump, but always panics when periodic
> > runs.
>
>Hmm, it doesn't even seem to *try* to dump... are you sure you have
>configured a dump device?
Arrrrrrggggh... There was a typo on /etc/rc.conf :-(
dumpdev="/dev/twed0s1b" # Device name to crashdump to (or NO).
dumpdir="/var/crash" # Directory where crash dumps are to be stored
istead of the correct
/dev/twed0b
I have corrected that and did a
ns4# dumpon -v /dev/twed0b
dumpon: crash dumps to /dev/twed0b (147, 1)
ns4#
> > instruction pointer = 0x8:0xc0174830
>
>This is the address of the instruction which caused the fault. You
>can run nm(1) on your kernel to find out where in the kernel that is,
>e.g.:
>
># nm /kernel | grep \^c0174 | sort
ns4# nm /kernel | grep \^c0174 | sort
c0174034 t switch_timecounter
c01740c4 t sync_other_counter
c0174130 t tco_forward
c0174278 t sysctl_kern_timecounter_hardware
c0174310 T pps_ioctl
c01743fc T pps_init
c0174420 T pps_event
c0174578 T devsw
c017459c T cdevsw_add
c01746c4 T cdevsw_remove
c017471c T major
c017473c T minor
c017475c T lminor
c0174788 T makebdev
c01747d4 T makedev
c01748f4 T freedev
c0174980 T dev2udev
c017499c T udev2dev
c0174a00 T uminor
c0174a0c T umajor
c0174a18 T makeudev
c0174a28 T make_dev
c0174a68 T destroy_dev
c0174a90 T devtoname
c0174b2c T getdtablesize
c0174b54 T dup2
c0174bf4 T dup
c0174c4c T fcntl
ns4#
Does this actually show the location ?
ns4# gdb -k kernel.debug
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read
called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933 in fill_symbuf
(kgdb) list *0xc0174830
0xc0174830 is in makedev (/usr/src/sys/kern/kern_conf.c:208).
203 if (x == umajor(NOUDEV) && y == uminor(NOUDEV))
204 Debugger("makedev of NOUDEV");
205 udev = (x << 8) | y;
206 hash = udev % DEVT_HASH;
207 LIST_FOREACH(si, &dev_hash[hash], si_hash) {
208 if (si->si_udev == udev)
209 return (si);
210 }
211 if (stashed >= DEVT_STASH) {
212 MALLOC(si, struct specinfo *, sizeof(*si), M_DEVT,
(kgdb)
>this should give you a list of maybe a dozen symbols; the one you want
>is the last one in the list that has a lower address than c0174830.
>
>How do you build your kernels - 'make buildkernel' or manually?
Always make buildkernel. I have a debug kernel built as well
(makeoptions DEBUG=-g)
Thanks for responding. Your above comment was what was needed to triple
check my rc.conf and correct the typo :(
---Mike
------------------------------
Date: Mon, 17 Feb 2003 20:39:27 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: debugging a repeating panic that does not produce a dump
Mike Tancsa <mi...@sentex.net> writes:
> ns4# nm /kernel | grep \^c0174 | sort
> [...]
> c01747d4 T makedev
> c01748f4 T freedev
This is it (makedev)
> Does this actually show the location ?
> ns4# gdb -k kernel.debug
> [...]
> (kgdb) list *0xc0174830
> 0xc0174830 is in makedev (/usr/src/sys/kern/kern_conf.c:208).
> 203 if (x == umajor(NOUDEV) && y == uminor(NOUDEV))
> 204 Debugger("makedev of NOUDEV");
> 205 udev = (x << 8) | y;
> 206 hash = udev % DEVT_HASH;
> 207 LIST_FOREACH(si, &dev_hash[hash], si_hash) {
> 208 if (si->si_udev == udev)
> 209 return (si);
> 210 }
> 211 if (stashed >= DEVT_STASH) {
> 212 MALLOC(si, struct specinfo *, sizeof(*si), M_DEVT,
> (kgdb)
Yep. Looks like si is garbage:
> fault virtual address = 0x211e6d36
is most likely the value of si at the time of the crash. It's nowhere
near kernel memory (which starts at 0xc0000000).
If / when you get a dump, show me the backtrace and the value of x, y
and udev (as reported by gdb operating on the recovered core)
> > How do you build your kernels - 'make buildkernel' or manually?
> Always make buildkernel. I have a debug kernel built as well
> (makeoptions DEBUG=-g)
That's what I wanted to know.
DES
- --
Dag-Erling Smorgrav - d...@ofug.org
------------------------------
Date: Mon, 17 Feb 2003 15:32:29 -0500
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: debugging a repeating panic that does not produce a dump
At 08:39 PM 17/02/2003 +0100, Dag-Erling Smorgrav wrote:
>If / when you get a dump, show me the backtrace and the value of x, y
>and udev (as reported by gdb operating on the recovered core)
Thank you very much, I will do so as soon as I get the dump. BTW, could
the act of giving the wrong params to dumpon cause the crash ? I dont see
anything directly in periodic that would look for / trigger that however.
---Mike
> > > How do you build your kernels - 'make buildkernel' or manually?
> > Always make buildkernel. I have a debug kernel built as well
> > (makeoptions DEBUG=-g)
>
>That's what I wanted to know.
>
>DES
>--
>Dag-Erling Smorgrav - d...@ofug.org
------------------------------
Date: Mon, 17 Feb 2003 22:33:56 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: debugging a repeating panic that does not produce a dump
Mike Tancsa <mi...@sentex.net> writes:
> Thank you very much, I will do so as soon as I get the dump. BTW,
> could the act of giving the wrong params to dumpon cause the crash ?
No, it wouldn't.
DES
- --
Dag-Erling Smorgrav - d...@ofug.org
------------------------------
Date: Mon, 17 Feb 2003 19:03:20 -0300
From: Diego Wentz Antunes <devl...@terra.com.br>
Subject: [none]
unsubscribe freebsd-hackers
------------------------------
Date: Tue, 18 Feb 2003 09:06:43 +1100
From: "Chris Knight" <ch...@aims.com.au>
Subject: RE: IPC and jail.
Howdy,
Excellent!
For regression tools, look at the /usr/src/tools/regression
directory in the -current source tree. There are regression tests
for sysv there.
Regards,
Chris Knight
Systems Administrator
AIMS Independent Computer Professionals
Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795
Web: http://www.aims.com.au
> -----Original Message-----
> From: Pawel Jakub Dawidek [mailto:ni...@garage.freebsd.pl]
> Sent: Tuesday, 18 February 2003 4:39
> To: freebsd...@freebsd.org
> Cc: ch...@aims.com.au
> Subject: IPC and jail.
>
>
> Hello hackers.
>
> I'm preparing a patch against FreeBSD 4.7 (for now) which splits IPC
> zones between jails and main host. Every entity will have his own IPC
> memory not shared with others (jails or main host). Message queues
> are already patched, but it need to be tested - that's why I'm
writing.
> Does anybody have any regression tests for IPC functionality?
> If not, which program use it and will be a good test?
>
> Thanks.
>
> --
> Pawel Jakub Dawidek
> UNIX Systems Administrator
> http://garage.freebsd.pl
> Am I Evil? Yes, I Am.
>
------------------------------
Date: Mon, 17 Feb 2003 17:41:58 -0500
From: The Anarcat <ana...@anarcat.ath.cx>
Subject: Results: what userland files are necessary for an installworld?
- --mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Ok. A few panics later, I brought the box back from the dead, with the
help of a 5.0-rel mini-iso. :)
I have put the gory details (a script record of the session) on
http://anarcat.ath.cx/scrapped.log
(warning: it's big and ugly as the rest of this mail).
A few things about the final setup: my /var is hosed, I moved most
files from / and /usr into subdirectories so they're considered
"dead".
After this experiment, I can say that make installworld need much more
than just make and /usr/{src,obj}. In fact, if you have lost either of
{/usr}/{s}bin or /usr/lib/libc* or /usr/libexec/ld-elf.so.1, consider
using an iso or a install floppy. :)
First of all, my mistake was to think make could live without
/bin/sh. :) So that's the first thing that's needed. Then there's
make(1) "system mk files":
lenny# cd /usr/src^M
lenny# ~/make^M
make: no system rules (sys.mk).
ouch! So I brought back /usr/share and /bin/sh from the dead. Then
there's is a long list of binaries that are used here and there:
date(1):
lenny# make installworld^M
date: not found
"/usr/src/Makefile", line 120: warning: "LC_ALL=3DC date" returned non-zero=
status
echo(1):
"/usr/src/Makefile", line 120: warning: "LC_ALL=3DC date" returned non-zero=
status
echo:No such file or directory
sysctl(8):
sysctl: not found
"/usr/src/Makefile.inc1", line 126: warning: "sysctl -n kern.osreldate" ret=
urned
non-zero status
At this point, we can consider that those tools (date, echo and
sysctl) are pretty much essential. But what about some less obvious
stuff:
mktemp(1):
/usr/bin/mktemp: not found
"/usr/src/Makefile.inc1", line 161: warning: "/usr/bin/mktemp -d -u -t inst=
all"=20
returned non-zero status
grep(1):
grep: not found
ERROR: Required smmsp user is missing, see /usr/src/UPDATING.
Then I got tired and just restored /bin, /sbin /usr/bin and
/usr/sbin. But installworld wasn't happy yet:
lenny# make installworld^M
Running test variables
ELF interpreter /usr/libexec/ld-elf.so.1 not found^M
FAIL: Test failed: regression detected. See above.
ELF interpreter /usr/libexec/ld-elf.so.1 not found^M
*** Signal 6
Stop in /usr/src/tools/regression/usr.bin/make.
Abort trap
Yes-yes... The regression tests try out the non-working, userland
make, then try to build one because it doesn't see *it already has one
in /usr/obj*. Ouch!
So, I restored the original /usr/bin/make. :( Then I got problems over
the /etc front:
grep: /etc/passwd: No such file or directory
ERROR: Required smmsp user is missing, see /usr/src/UPDATING.
*** Error code 1 (continuing)
I avoided this one by copying master.passwd from /usr/src, but
installworld could have seen this one coming. Generating /etc/passwd
automatically demands pwd_mkdb, but I could've wrote it by hand or
called in mergemaster to the rescue.
Then I got a little bit farther:
Testing installed kernel for new sigaction(2) syscall
Seems ok..
mkdir -p /tmp/install.VpIC0A0d
for prog in [ awk cat chflags chmod chown date echo egrep find grep ln mak=
e mkd
ir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic; do cp `whic=
h $pr
og` /tmp/install.VpIC0A0d; done
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
This is of course not very wise to do when you don't have those tools
installed. Restoring /bin, /sbin, /usr/bin and /usr/sbin along with
ld-elf.so.1 (since /usr/* stuff is dynamic) solves that one.=20
At this point, I managed to trash my backup copies of [/usr]/[s]bin
and I just dropped the whole experience.
I don't recommend people to rely on /usr/obj to get their system back
from the dead. Only a "real" bootstrap tool such as a livecd, the
install disks or the install floppies can get you out of a mess such
as /bin being dead. This, of course, ignoring the backup argument. :)
I'll send my acpiconf experiments results on -current later on.
A.
- --=20
Legislation should outlaw an advertiser's attempts to use its economic
relationships with a media enterprise to influence the enterprise not
to print or broadcast content that it would otherwise choose to
present . . . . There is little reason to allow this use of economic
power to censor others' speech and to block the public's access to
information or viewpoints.
- C. Edwin Baker
- --mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+UWU1ttcWHAnWiGcRAkk+AKCEj6vq9GIKhHt2uVQItn+IcVk5sQCfUT7A
CQdXHRFQPDBYPM8pn7cu8qA=
=yD6/
- -----END PGP SIGNATURE-----
- --mP3DRpeJDSE+ciuQ--
------------------------------
Date: Mon, 17 Feb 2003 20:09:53 -0800 (PST)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: DHCP problem with pxeboot over wireless via LinkSys WAP11
I came across an interesting problem trying to pxeboot a diskless
machine over a wireless network.
The sequence of events goes like this:
network bios:
network bios issues DHCP request from 0.0.0.0 (via wireless bridge)
my dhcp server replies
network bios sets IP address
network bios loads pxeboot successfully
pxeboot runs:
pxeboot issues DHCP request from <IP> (ip assigned by network bios)
mh dhcp server replies
LinkSys WAP11 eats the reply. poof gone.
[repeat until pxeboot gives up]
I think the LinkSys is just plain broken but it's weird that the network
bios was able to issue a request without the reply getting eaten, and
the kernel (once one is able to boot that far) is also able to issue
a request and get a reply that isn't eaten. And yet the reply to
pxeboot's bootp() request gets eaten by the WAP11 every time. It works
fine on a hard line, but blows up through the wireless.
Anyone see this before?
In anycase, I found a solution, which is to extract the RFC1048 data
from the PXE cache in the PXE code. Then if the PXE's bootp() attempt
fails (which it does for me :-( ), it can use the data extracted from
the PXE cache to set the appropriate variables.
This patch is for -stable and it needs a bit of cleaning up, and still
has some debugging, and the bootp() call is #if 0'd out to test the
PXE cache data interpretation, but once cleaned up I believe it can be
committed and, in fact, we might be able to avoid having to call bootp()
at all if the PXE cache has all the necessary info.
-Matt
Matthew Dillon
<dil...@backplane.com>
Index: i386/libi386/pxe.c
===================================================================
RCS file: /home/ncvs/src/sys/boot/i386/libi386/pxe.c,v
retrieving revision 1.3.2.9
diff -u -r1.3.2.9 pxe.c
- --- i386/libi386/pxe.c 15 Mar 2001 08:35:54 -0000 1.3.2.9
+++ i386/libi386/pxe.c 18 Feb 2003 04:02:51 -0000
@@ -96,6 +96,7 @@
extern u_int16_t __pxenvseg;
extern u_int16_t __pxenvoff;
extern void __pxenventry(void);
+extern struct in_addr servip;
struct netif_dif pxe_ifs[] = {
/* dif_unit dif_nsel dif_stats dif_private */
@@ -256,6 +257,7 @@
char temp[FNAME_SIZE];
int error = 0;
int i;
+ struct iodesc *d;
va_start(args, f);
devname = va_arg(args, char*);
@@ -273,16 +275,49 @@
if (pxe_debug)
printf("pxe_open: netif_open() succeeded\n");
}
+ if (!(d = socktodesc(pxe_sock))) {
+ printf("pxe_open: bad socket. %d\n", pxe_sock);
+ return (ENXIO);
+ }
if (rootip.s_addr == 0) {
/*
+ * Try to extract the RFC1048 data from PXE
+ *
+ * It turns out that at some wireless bridges/access-points
+ * eat dhcpd responses to pxeboot's bootp requests. This
+ * may save us if the bootp() attempt below fails. In fact,
+ * if we get enough info we can skip the bootp() attempt XXX.
+ */
+ if (dhcp_try_rfc1048(bootplayer.vendor.d, BOOTP_DHCPVEND))
+ printf("pxe_open: no RFC1048 data in PXE Cache\n");
+ else
+ printf("pxe_open: loaded RFC1048 data from PXE Cache\n");
+
+ /*
* Do a bootp/dhcp request to find out where our
* NFS/TFTP server is. Even if we dont get back
* the proper information, fall back to the server
* which brought us to life and a default rootpath.
*/
+#if 0
bootp(pxe_sock, BOOTP_PXE);
+#endif
+
+ /*
+ * Failsafe
+ */
if (rootip.s_addr == 0)
rootip.s_addr = bootplayer.sip;
+ if (gateip.s_addr == 0)
+ gateip.s_addr = bootplayer.gip;
+ if (myip.s_addr == 0)
+ myip.s_addr = bootplayer.yip;
+ if (servip.s_addr == 0)
+ servip = rootip;
+ if (d->myip.s_addr == 0)
+ d->myip = myip;
+ printf("d->MYIP %04x d->servip %04x\n", d->myip.s_addr, servip.s_addr);
+
if (!rootpath[1])
strcpy(rootpath, PXENFSROOTPATH);
@@ -503,6 +538,7 @@
bzero(udpopen_p, sizeof(*udpopen_p));
udpopen_p->src_ip = bootplayer.yip;
+
pxe_call(PXENV_UDP_OPEN);
if (udpopen_p->status != 0) {
@@ -549,7 +585,7 @@
{
t_PXENV_UDP_WRITE *udpwrite_p = (t_PXENV_UDP_WRITE *)scratch_buffer;
bzero(udpwrite_p, sizeof(*udpwrite_p));
- -
+
udpwrite_p->ip = h->destip.s_addr;
udpwrite_p->dst_port = h->destport;
udpwrite_p->src_port = h->myport;
Index: bootp.c
===================================================================
RCS file: /home/ncvs/src/lib/libstand/bootp.c,v
retrieving revision 1.1.1.1.6.2
diff -u -r1.1.1.1.6.2 bootp.c
- --- bootp.c 20 Sep 2000 18:37:25 -0000 1.1.1.1.6.2
+++ bootp.c 18 Feb 2003 03:52:34 -0000
@@ -335,6 +335,16 @@
return (-1);
}
+int
+dhcp_try_rfc1048(u_char *cp, u_int len)
+{
+ expected_dhcpmsgtype = DHCPACK;
+ if (bcmp(vm_rfc1048, cp, sizeof(vm_rfc1048)) == 0) {
+ return(vend_rfc1048(cp, len));
+ }
+ return(-1);
+}
+
static int
vend_rfc1048(cp, len)
register u_char *cp;
@@ -356,6 +366,7 @@
while (cp < ep) {
tag = *cp++;
size = *cp++;
+
if (tag == TAG_END)
break;
------------------------------
Date: Tue, 18 Feb 2003 12:29:26 +0200
From: mika ruohotie <bsd...@aeon.st>
Subject: lost filesystems, recovery
hello,
recently my current system lost it's filesystems complitely while [1]
running the daily thru the disk. well, current and current, it was
5.0-current, but not recent one, had soft-updates.
disklabel is fine, and if i dd the partitions into a file, and then
read that with "stings", it seems as if most or even all of the
stuff supposed to be there, actually still _is_ there.
fsck [2] doesnt seem to think anything is wrong (on the first run it
cleared few files, assuming those which were open while the damage
was happening) and fssrecov doesnt like my dd-images [3]. i got few
of the /var logs out with it.
suggestions other than ibas? (was a personal machine, not production
and i doubt my insurance covers their costs... :> )
i've seen something similar once several years ago when my other ide
drive (western digital) decided it wants to sleep while i did a
find thru the system. then fixit fsck resulted everything got put
into lost&found, this time tho nothing there either. this time the
drive was ibm deathstar, ide.
i assume there could be something more to do, since as i said, the
data seems to be there still. it'd be annoying to read thru those
dd-images and cut&paste all the text out.
mickey
[1] i read /var image and timestamps there suggested the damage
happened around the same time daily ran it's find, i was able to
pinpoint the damage into a 5 minute window.
[2] fixit or another system, ofcourse, since _nothing_ is left on
that 10GB drive, except the mbr and disklabel. (and the stuff
i still can see from the dd images, ofcourse)
[3] mmap issues with above 2GB or alike, splitting images didnt help,
should i have used some additional dd flags, other than just if/of?
------------------------------
Date: Tue, 18 Feb 2003 13:41:12 +0000
From: Ian Watkinson <ian.wa...@ehsbrann.com>
Subject: DHCP Client DoS
Hi all,
We've recently found a problem with dhclient that can DoS a DHCP
server. If you have schg flags set on /etc/resolv.conf to stop dhcp
overwriting your existing nameservers, the problem occurs.
Basically, the client just keeps rejecting the IP details it has
received from the server and requesting another. The server marks the
record as used, and moves onto the next one. Over the course of a couple
of minutes, you can pretty much mark an entire class C as in use.
If you remove the schg flag from resolv.conf, this problem does not
happen.
This has been tested from a FreeBSD 5 client against a Windows NT server
and a FreeBSD 4.7 server with the same results.
- --
Ian Watkinson
------------------------------
Date: Tue, 18 Feb 2003 14:44:21 +0100
From: Stijn Hoop <st...@win.tue.nl>
Subject: Re: DHCP Client DoS
- --DBIVS5p969aUjpLe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 18, 2003 at 01:41:12PM +0000, Ian Watkinson wrote:
> We've recently found a problem with dhclient that can DoS a DHCP
> server. If you have schg flags set on /etc/resolv.conf to stop dhcp
> overwriting your existing nameservers, the problem occurs.
>=20
> Basically, the client just keeps rejecting the IP details it has
> received from the server and requesting another. The server marks the
> record as used, and moves onto the next one. Over the course of a couple
> of minutes, you can pretty much mark an entire class C as in use.=20
>=20
> If you remove the schg flag from resolv.conf, this problem does not
> happen.=20
While this is of course very bad, you do know about the 'supersede'
command in dhclient.conf to override any DHCP-supplied values?
Something like
interface "fxp0" {
supersede domain-name-servers 127.0.0.1;
}
should work.
That should at least solve the 'overwriting /etc/resolv.conf' problem.
man dhclient.conf for details.
- --Stijn
- --=20
Fairy tales do not tell children that dragons exist. Children already
know dragons exist. Fairy tales tell children the dragons can be
killed.
-- G.K. Chesterton
- --DBIVS5p969aUjpLe
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+Uji1Y3r/tLQmfWcRApDKAJ0UNnzi6Brl3PoAMctTp0E7qOmetACeIiCR
rwi2eq7FEDazFpOSZGw8r8g=
=r4s5
- -----END PGP SIGNATURE-----
- --DBIVS5p969aUjpLe--
------------------------------
Date: Tue, 18 Feb 2003 16:11:14 +0100
From: Volker Stolz <st...@i2.informatik.rwth-aachen.de>
Subject: Re: DHCP Client DoS
In local.freebsd-hackers, you wrote:
> We've recently found a problem with dhclient that can DoS a DHCP
> server. If you have schg flags set on /etc/resolv.conf to stop dhcp
> overwriting your existing nameservers, the problem occurs.
> Basically, the client just keeps rejecting the IP details it has
> received from the server and requesting another. The server marks the
> record as used, and moves onto the next one. Over the course of a couple
> of minutes, you can pretty much mark an entire class C as in use.
The problem of read-only resolv.conf is already documented in the PR
database and I think recently somebody started thinking about a solution.
Check http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/38778
That the server runs out of IPs is his probably his own fault. It
should be configured to not eat up all IPs when a host which already
has obtained a lease requests another one but simply hand out the old
one or deny the request...
Stijn: Could you add your suggestion to the above PR?
- --
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
rage against the finite state machine
------------------------------
Date: Tue, 18 Feb 2003 16:19:13 +0100
From: Stijn Hoop <st...@win.tue.nl>
Subject: Re: DHCP Client DoS
- --ZfOjI3PrQbgiZnxM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 18, 2003 at 04:11:14PM +0100, Volker Stolz wrote:
> In local.freebsd-hackers, you wrote:
> > We've recently found a problem with dhclient that can DoS a DHCP
> > server. If you have schg flags set on /etc/resolv.conf to stop dhcp
> > overwriting your existing nameservers, the problem occurs.
> > Basically, the client just keeps rejecting the IP details it has
> > received from the server and requesting another. The server marks the
> > record as used, and moves onto the next one. Over the course of a couple
> > of minutes, you can pretty much mark an entire class C as in use.=20
>=20
> The problem of read-only resolv.conf is already documented in the PR
> database and I think recently somebody started thinking about a solution.
> Check http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dbin/38778
>=20
> That the server runs out of IPs is his probably his own fault. It
> should be configured to not eat up all IPs when a host which already
> has obtained a lease requests another one but simply hand out the old
> one or deny the request...
>=20
> Stijn: Could you add your suggestion to the above PR?
Well I could but it's a workaround -- dhclient should imho be made not
to fail when it cannot write /etc/resolv.conf. That's a separate issue
from being able to set the contents of the newly written resolv.conf,
which is essentially what the supersede option does. All I was trying to
say was that there already is a solution for keeping your own nameservers
in /etc/resolv.conf.
That said, I will add some words to this effect to the PR.
- --Stijn
- --=20
The rain it raineth on the just
And also on the unjust fella,
But chiefly on the just, because
The unjust steals the just's umbrella.
- --ZfOjI3PrQbgiZnxM
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+Uk7xY3r/tLQmfWcRAimUAJwMQW3+lC3a2Dte+c4ewaQPhhqaIACgj6iB
P+wUkDHdiqHQezA0aSKgZpM=
=YrnR
- -----END PGP SIGNATURE-----
- --ZfOjI3PrQbgiZnxM--
------------------------------
Date: Mon, 17 Feb 2003 15:10:34 +0100
From: Paolo Pisati <p.pi...@oltrelinux.com>
Subject: Simple question about profiling
I've to confess this my first serious profile session, and
i found something really strange (at least for me... =P)
[flag@law3 src]$ gprof proto3
[snip]
% cumulative self self total
time seconds seconds calls ms/call ms/call name
74.4 39.26 39.26 .mcount (83)
6.7 42.82 3.56 111575600 0.00 0.00 checkRule2d [4]
6.6 46.30 3.48 1024 3.39 12.30 buildTree2d [3]
3.8 48.29 1.99 117334464 0.00 0.00 add_tail [6]
3.7 50.25 1.96 117234464 0.00 0.00 rem [7]
1.8 51.18 0.93 117234464 0.00 0.00 rem_head [5]
0.6 51.51 0.33 1600004 0.00 0.00 __qdivrem [13]
0.5 51.75 0.24 800004 0.00 0.00 __svfscanf [9]
0.4 51.96 0.21 9037 0.02 0.09 buildTree1d [10]
0.3 52.14 0.18 800000 0.00 0.00 strtoumax [12]
0.3 52.28 0.14 1078414 0.00 0.00 memset [20]
0.2 52.41 0.12 5658864 0.00 0.00 checkRule1d [21]
0.1 52.47 0.07 250129 0.00 0.00 count [23]
0.1 52.52 0.05 537809 0.00 0.00 malloc_bytes <cycle 1> [22
]
0.1 52.56 0.04 1166299 0.00 0.00 append_lists [25]
0.1 52.59 0.03 2411019 0.00 0.00 new_list [26]
0.1 52.62 0.03 536551 0.00 0.00 calloc [14]
0.0 52.64 0.02 70 0.24 0.42 tree2dHeight [29]
[snip]
i think this is the beef: what the hell is .mcount?!?!
if i read the table correctly, .mcount is the guilty, isn't it?
any help or pointer is appreciated, thank you... =)
- --
Paolo
------------------------------
End of freebsd-hackers-digest V5 #723
*************************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message