From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 13:54:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C450616A401 for ; Sun, 18 Feb 2007 13:54:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB8C13C428 for ; Sun, 18 Feb 2007 13:54:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id F138CEB4B59; Sun, 18 Feb 2007 21:54:30 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id UqE3SrPSRfcr; Sun, 18 Feb 2007 21:54:23 +0800 (CST) Received: from [192.168.1.32] (unknown [61.49.185.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id AE3ACEB4939; Sun, 18 Feb 2007 21:54:23 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:x-enigmail-version:content-type; b=REJ740gXuuax0Ujdc07maPC9Z3m7xtC82vKFwA1UR+yMIQHDxp0ImxJV4YiGoW7b6 fh2mPEjkBrLSNrohCjvVw== Message-ID: <45D85A88.4040402@delphij.net> Date: Sun, 18 Feb 2007 21:54:16 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig1579E7B082DB1FE636B8A914" Subject: [PATCH] Feature request: exit netstat(1) after user specified outputs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 13:54:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1579E7B082DB1FE636B8A914 Content-Type: multipart/mixed; boundary="------------090407050304000506020605" This is a multi-part message in MIME format. --------------090407050304000506020605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This is a patch that I have backported to -CURRENT, which is originally made against RELENG_6_2. I have received several feature requests from our local community which they wanted to have a top(1)'s '-d' alike feature for netstat, so they will be able to use netstat(1) as a handy brick when building monitoring scripts. So here is the patchset that adds a '-q' option, which accepts a numerical argument meaning how many outputs are going out before we exit.= Comments? (I think 'q' is arguable, but netstat(1) has too many options = :-) Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------090407050304000506020605 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="patch-netstat" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="patch-netstat" Index: if.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/netstat/if.c,v retrieving revision 1.66 diff -u -p -r1.66 if.c --- if.c 8 Nov 2006 15:15:05 -0000 1.66 +++ if.c 18 Feb 2007 13:37:32 -0000 @@ -676,6 +676,8 @@ loop: (void)alarm(interval1); line++; first =3D 0; + if (qflag && (qval-- =3D=3D 0)) + exit(0); if (line =3D=3D 21) goto banner; else Index: main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/netstat/main.c,v retrieving revision 1.83 diff -u -p -r1.83 main.c --- main.c 28 Jul 2006 16:16:40 -0000 1.83 +++ main.c 18 Feb 2007 13:29:11 -0000 @@ -295,6 +295,8 @@ int mflag; /* show memory stats */ int numeric_addr; /* show addresses numerically */ int numeric_port; /* show ports numerically */ static int pflag; /* show given protocol */ +int qflag; /* whether to quit after specified outputs */ +int qval; /* how much outputs before we exit */ int rflag; /* show routing tables (or routing stats) */ int sflag; /* show protocol statistics */ int tflag; /* show i/f watchdog timers */ @@ -316,7 +318,7 @@ main(int argc, char *argv[]) =20 af =3D AF_UNSPEC; =20 - while ((ch =3D getopt(argc, argv, "AaBbdf:ghI:iLlM:mN:np:rSstuWw:z")) != =3D -1) + while ((ch =3D getopt(argc, argv, "AaBbdf:ghI:iLlM:mN:np:q:rSstuWw:z"))= !=3D -1) switch(ch) { case 'A': Aflag =3D 1; @@ -400,6 +402,10 @@ main(int argc, char *argv[]) } pflag =3D 1; break; + case 'q': + qval =3D atoi(optarg); + qflag =3D 1; + break; case 'r': rflag =3D 1; break; Index: netstat.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/netstat/netstat.1,v retrieving revision 1.57 diff -u -p -r1.57 netstat.1 --- netstat.1 29 Sep 2006 15:20:46 -0000 1.57 +++ netstat.1 18 Feb 2007 13:40:17 -0000 @@ -130,6 +130,7 @@ is also present, print interface names u .Nm .Fl w Ar wait .Op Fl I Ar interface +.Op Fl q Ar howmany .Op Fl d .Op Fl M Ar core .Op Fl N Ar system @@ -143,6 +144,11 @@ traffic on all configured network interf or a single .Ar interface . If +.Fl q +is also present, exit after +.Ar howmany +outputs. +If .Fl d is also present, show the number of dropped packets. .It Xo Index: netstat.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/netstat/netstat.h,v retrieving revision 1.48 diff -u -p -r1.48 netstat.h --- netstat.h 28 Jul 2006 16:09:18 -0000 1.48 +++ netstat.h 18 Feb 2007 13:19:41 -0000 @@ -47,6 +47,8 @@ extern int Lflag; /* show size of listen extern int mflag; /* show memory stats */ extern int numeric_addr; /* show addresses numerically */ extern int numeric_port; /* show ports numerically */ +extern int qflag; /* whether to quit after specified outputs */ +extern int qval; /* how much outputs before we exit */ extern int rflag; /* show routing tables (or routing stats) */ extern int sflag; /* show protocol statistics */ extern int tflag; /* show i/f watchdog timers */ --------------090407050304000506020605-- --------------enig1579E7B082DB1FE636B8A914 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF2FqIOfuToMruuMARA7PNAJ91skYOhGG/ogn9vUbZ3jtXZCatZgCdFWAi hiBKc/YafSMUMyepEfdNQUA= =1oWX -----END PGP SIGNATURE----- --------------enig1579E7B082DB1FE636B8A914-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 14:12:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64AA616A408 for ; Sun, 18 Feb 2007 14:12:01 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id 738A713C471 for ; Sun, 18 Feb 2007 14:11:59 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 54560 invoked by uid 1004); 18 Feb 2007 14:11:58 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.2):. Processed in 0.022753 secs); 18 Feb 2007 14:11:58 -0000 Received: from unknown (HELO ?217.25.23.2?) (217.25.23.2) by ns0.azuni.net with AES256-SHA encrypted SMTP; 18 Feb 2007 14:11:58 -0000 Message-ID: <45D85EA3.2050102@azuni.net> Date: Sun, 18 Feb 2007 18:11:47 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 14:12:01 -0000 Hi, I'm trying to use ipfw's limit clause to limit the number of connections a single IP can have at the same time in a transparent web-proxy environment: 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port 80 in via if0 setup limit src-addr 10 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 ... the rest fwd... as I understand the manpage, when the current number of connectiions is below 10, the action "skipto" is performed, else, the packet is dropped and the search terminates. But... the problem is that the src-addr limit is not enforced as some clients somehow open a huge number (3-5 times the prescribed value) of www-connections to some single address Out There, forcing you to bump up certain sysctl variables (such as kern.ipc.nmbclusters, kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be going on? Is ipfw broken, or am I misusing it? OS: FreeBSD 6.2 From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 15:20:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD84216A420; Sun, 18 Feb 2007 15:20:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 049AE13C4B3; Sun, 18 Feb 2007 15:20:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.1.91] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1HInpz2OfA-0002th; Sun, 18 Feb 2007 16:20:29 +0100 From: Max Laier Organization: FreeBSD To: Luigi Rizzo Date: Sun, 18 Feb 2007 16:20:18 +0100 User-Agent: KMail/1.9.5 References: <200702161738.35142.max@love2party.net> <20070216085132.A7944@xorpc.icir.org> In-Reply-To: <20070216085132.A7944@xorpc.icir.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1505776.Wia5angaEs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702181620.26610.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX18W5xoRtw1Lm86fJRsfSSTK/6vI7xvL4jJPeKFgxjqx9sAGs+s9zzhR3nL6p7pHdI60IJEi8JIbDrdBWEx841wJbyWbu6N+5zHCbJVjSOtqkQ== Cc: Jeremie Le Hen , freebsd-net@freebsd.org, "V.Chukharev" , cognet@freebsd.org Subject: Re: iwi leaks memory? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 15:20:50 -0000 --nextPart1505776.Wia5angaEs Content-Type: multipart/mixed; boundary="Boundary-01=_16G2FC0/L+z46iA" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_16G2FC0/L+z46iA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 February 2007 17:51, Luigi Rizzo wrote: > On Fri, Feb 16, 2007 at 05:38:28PM +0100, Max Laier wrote: > ... > > > I'm under the impression that this is more a problem of increasing > > fragmentation until we can't get a big enough unfragmented chunk. I > > don't have any proof of this assumption yet. > > makes sense. > As a matter of fact i wonder whether it wouldn't be smarter > to allocate the dma-ble memory on the first request and > keep it around until the driver is unloaded. > > If i read the code in iwi_load_firmware() correctly, > the contiguous chunks cannot be longer than 8191 bytes, > so a single contiguous buffer is not mandatory. > I just don't know if we can write the firmware to the adapter > with multiple operations (lists of command blocks) or > it needs to be just a single list ? The linux driver uses one continuous buffer as well. I tried to hand in=20 separate buffers, but it failed to initialize the firmware. Attached is=20 a diff (for HEAD and RELENG_6) to allocate the DMA buffer once and keep=20 it around. As I said earlier: As long as the firmware is as (un)stable=20 as it is now, this might be the only sensible way. All in all it's not=20 that bad, as we "only" throw away 212966 bytes. Could you please confirm that this works for you? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_16G2FC0/L+z46iA Content-Type: text/x-diff; charset="iso-8859-1"; name="iwi.r6.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="iwi.r6.diff" Index: if_iwi.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/dev/iwi/if_iwi.c,v retrieving revision 1.8.2.12 diff -u -r1.8.2.12 if_iwi.c =2D-- if_iwi.c 23 Jan 2007 22:17:48 -0000 1.8.2.12 +++ if_iwi.c 18 Feb 2007 15:05:01 -0000 @@ -118,6 +118,8 @@ }; =20 static void iwi_dma_map_addr(void *, bus_dma_segment_t *, int, int); +static int iwi_alloc_fw_cb(struct iwi_softc *); +static void iwi_free_fw_cb(struct iwi_softc *); static int iwi_alloc_cmd_ring(struct iwi_softc *, struct iwi_cmd_ring *, int); static void iwi_reset_cmd_ring(struct iwi_softc *, struct iwi_cmd_ring *); @@ -322,6 +324,12 @@ goto fail; } =20 + if (iwi_alloc_fw_cb(sc) !=3D 0) { + device_printf(dev, + "could not allocate firmware command block\n"); + goto fail; + } + /* * Allocate rings. */ @@ -496,6 +504,7 @@ } iwi_put_firmware(sc); =20 + iwi_free_fw_cb(sc); iwi_free_cmd_ring(sc, &sc->cmdq); iwi_free_tx_ring(sc, &sc->txq[0]); iwi_free_tx_ring(sc, &sc->txq[1]); @@ -536,6 +545,57 @@ } =20 static int +iwi_alloc_fw_cb(struct iwi_softc *sc) +{ + int error; + + sc->fw_dma_size =3D IWI_CB_MAXDATALEN * IWI_FW_CB_MAX; + + error =3D bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 4, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + sc->fw_dma_size, 1, sc->fw_dma_size, 0, NULL, NULL, + &sc->fw_dmat); + if (error !=3D 0) { + device_printf(sc->sc_dev, + "could not create firmware DMA tag\n"); + goto fail; + } + + error =3D bus_dmamem_alloc(sc->fw_dmat, &sc->fw_virtaddr, 0, + &sc->fw_map); + if (error !=3D 0) { + device_printf(sc->sc_dev, + "could not allocate firmware DMA memory\n"); + goto fail; + } + + error =3D bus_dmamap_load(sc->fw_dmat, sc->fw_map, sc->fw_virtaddr, + sc->fw_dma_size, iwi_dma_map_addr, &sc->fw_physaddr, 0); + if (error !=3D 0) { + device_printf(sc->sc_dev, "could not load firmware DMA map\n"); + goto fail; + } + + return (0); +fail: iwi_free_fw_cb(sc); + return (error); +} + +static void +iwi_free_fw_cb(struct iwi_softc *sc) +{ + if (sc->fw_virtaddr !=3D NULL) { + bus_dmamap_sync(sc->fw_dmat, sc->fw_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fw_dmat, sc->fw_map); + bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); + } + + if (sc->fw_dmat !=3D NULL) + bus_dma_tag_destroy(sc->fw_dmat); +} + +static int iwi_alloc_cmd_ring(struct iwi_softc *sc, struct iwi_cmd_ring *ring, int co= unt) { int error; @@ -2433,6 +2493,14 @@ uint32_t sentinel, ctl, src, dst, sum, len, mlen, tmp; int ntries, error; =20 + if (fw->size > sc->fw_dma_size) { + device_printf(sc->sc_dev, + "to less dma memory for %s firmware (%d < %d)\n", + fw->name, sc->fw_dma_size, fw->size); + error =3D ENOMEM; + goto fail5; + } + /* copy firmware image to DMA memory */ memcpy(sc->fw_virtaddr, fw->data, fw->size); =20 @@ -3099,47 +3167,18 @@ goto fail; } =20 =2D /* allocate DMA memory for mapping firmware image */ =2D if (sc->fw_boot.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_boot.size; =2D if (sc->fw_fw.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_fw.size; =2D if (sc->fw_uc.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_uc.size; =2D =2D if (bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, =2D BUS_SPACE_MAXADDR, NULL, NULL, sc->fw_dma_size, 1, sc->fw_dma_size, =2D 0, NULL, NULL, &sc->fw_dmat) !=3D 0) { =2D device_printf(sc->sc_dev, =2D "could not create firmware DMA tag\n"); =2D IWI_LOCK(sc); =2D goto fail; =2D } =2D if (bus_dmamem_alloc(sc->fw_dmat, &sc->fw_virtaddr, 0, =2D &sc->fw_map) !=3D 0) { =2D device_printf(sc->sc_dev, =2D "could not allocate firmware DMA memory\n"); =2D IWI_LOCK(sc); =2D goto fail2; =2D } =2D if (bus_dmamap_load(sc->fw_dmat, sc->fw_map, sc->fw_virtaddr, =2D sc->fw_dma_size, iwi_dma_map_addr, &sc->fw_physaddr, 0) !=3D 0) { =2D device_printf(sc->sc_dev, "could not load firmware DMA map\n"); =2D IWI_LOCK(sc); =2D goto fail3; =2D } IWI_LOCK(sc); =20 if (iwi_load_firmware(sc, &sc->fw_boot) !=3D 0) { device_printf(sc->sc_dev, "could not load boot firmware %s\n", sc->fw_boot.name); =2D goto fail4; + goto fail; } =20 if (iwi_load_ucode(sc, &sc->fw_uc) !=3D 0) { device_printf(sc->sc_dev, "could not load microcode %s\n", sc->fw_uc.name); =2D goto fail4; + goto fail; } =20 iwi_stop_master(sc); @@ -3174,15 +3213,10 @@ if (iwi_load_firmware(sc, &sc->fw_fw) !=3D 0) { device_printf(sc->sc_dev, "could not load main firmware %s\n", sc->fw_fw.name); =2D goto fail4; + goto fail; } sc->flags |=3D IWI_FLAG_FW_INITED; =20 =2D bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); =2D bus_dmamap_unload(sc->fw_dmat, sc->fw_map); =2D bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); =2D bus_dma_tag_destroy(sc->fw_dmat); =2D if (iwi_config(sc) !=3D 0) { device_printf(sc->sc_dev, "device configuration failed\n"); goto fail; @@ -3206,10 +3240,6 @@ sc->flags &=3D ~IWI_FLAG_FW_LOADING; return; =20 =2Dfail4: bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); =2D bus_dmamap_unload(sc->fw_dmat, sc->fw_map); =2Dfail3: bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); =2Dfail2: bus_dma_tag_destroy(sc->fw_dmat); fail: ifp->if_flags &=3D ~IFF_UP; sc->flags &=3D ~IWI_FLAG_FW_LOADING; iwi_stop(sc); Index: if_iwireg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/dev/iwi/if_iwireg.h,v retrieving revision 1.2.2.4 diff -u -r1.2.2.4 if_iwireg.h =2D-- if_iwireg.h 29 Oct 2006 08:29:31 -0000 1.2.2.4 +++ if_iwireg.h 18 Feb 2007 15:04:28 -0000 @@ -144,6 +144,9 @@ #define IWI_FW_GET_MAJOR(ver) ((ver) & 0xff) #define IWI_FW_GET_MINOR(ver) (((ver) & 0xff00) >> 8) =20 +/* max firmware size in command blocks (0x1fff) */ +#define IWI_FW_CB_MAX 26 + #define IWI_FW_MODE_UCODE 0 #define IWI_FW_MODE_BOOT 0 #define IWI_FW_MODE_BSS 0 --Boundary-01=_16G2FC0/L+z46iA Content-Type: text/x-diff; charset="iso-8859-1"; name="iwi.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="iwi.diff" Index: if_iwi.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/dev/iwi/if_iwi.c,v retrieving revision 1.46 diff -u -r1.46 if_iwi.c =2D-- if_iwi.c 15 Feb 2007 17:21:31 -0000 1.46 +++ if_iwi.c 18 Feb 2007 15:16:00 -0000 @@ -119,6 +119,8 @@ }; =20 static void iwi_dma_map_addr(void *, bus_dma_segment_t *, int, int); +static int iwi_alloc_fw_cb(struct iwi_softc *); +static void iwi_free_fw_cb(struct iwi_softc *); static int iwi_alloc_cmd_ring(struct iwi_softc *, struct iwi_cmd_ring *, int); static void iwi_reset_cmd_ring(struct iwi_softc *, struct iwi_cmd_ring *); @@ -323,6 +325,12 @@ goto fail; } =20 + if (iwi_alloc_fw_cb(sc) !=3D 0) { + device_printf(dev, + "could not allocate firmware command block\n"); + goto fail; + } + /* * Allocate rings. */ @@ -497,6 +505,7 @@ } iwi_put_firmware(sc); =20 + iwi_free_fw_cb(sc); iwi_free_cmd_ring(sc, &sc->cmdq); iwi_free_tx_ring(sc, &sc->txq[0]); iwi_free_tx_ring(sc, &sc->txq[1]); @@ -537,6 +546,57 @@ } =20 static int +iwi_alloc_fw_cb(struct iwi_softc *sc) +{ + int error; + + sc->fw_dma_size =3D IWI_CB_MAXDATALEN * IWI_FW_CB_MAX; + + error =3D bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 4, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + sc->fw_dma_size, 1, sc->fw_dma_size, 0, NULL, NULL, + &sc->fw_dmat); + if (error !=3D 0) { + device_printf(sc->sc_dev, + "could not create firmware DMA tag\n"); + goto fail; + } + + error =3D bus_dmamem_alloc(sc->fw_dmat, &sc->fw_virtaddr, 0, + &sc->fw_map); + if (error !=3D 0) { + device_printf(sc->sc_dev, + "could not allocate firmware DMA memory\n"); + goto fail; + } + + error =3D bus_dmamap_load(sc->fw_dmat, sc->fw_map, sc->fw_virtaddr, + sc->fw_dma_size, iwi_dma_map_addr, &sc->fw_physaddr, 0); + if (error !=3D 0) { + device_printf(sc->sc_dev, "could not load firmware DMA map\n"); + goto fail; + } + + return (0); +fail: iwi_free_fw_cb(sc); + return (error); +} + +static void +iwi_free_fw_cb(struct iwi_softc *sc) +{ + if (sc->fw_virtaddr !=3D NULL) { + bus_dmamap_sync(sc->fw_dmat, sc->fw_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fw_dmat, sc->fw_map); + bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); + } + + if (sc->fw_dmat !=3D NULL) + bus_dma_tag_destroy(sc->fw_dmat); +} + +static int iwi_alloc_cmd_ring(struct iwi_softc *sc, struct iwi_cmd_ring *ring, int co= unt) { int error; @@ -2439,6 +2499,14 @@ uint32_t sentinel, ctl, src, dst, sum, len, mlen, tmp; int ntries, error; =20 + if (fw->size > sc->fw_dma_size) { + device_printf(sc->sc_dev, + "to less dma memory for %s firmware (%d < %d)\n", + fw->name, sc->fw_dma_size, fw->size); + error =3D ENOMEM; + goto fail5; + } + /* copy firmware image to DMA memory */ memcpy(sc->fw_virtaddr, fw->data, fw->size); =20 @@ -3105,48 +3173,18 @@ goto fail; } =20 =2D /* allocate DMA memory for mapping firmware image */ =2D if (sc->fw_boot.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_boot.size; =2D if (sc->fw_fw.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_fw.size; =2D if (sc->fw_uc.size > sc->fw_dma_size) =2D sc->fw_dma_size =3D sc->fw_uc.size; =2D =2D if (bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 4, 0,=20 =2D BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL,=20 =2D sc->fw_dma_size, 1, sc->fw_dma_size, 0, NULL, NULL,=20 =2D &sc->fw_dmat) !=3D 0) { =2D device_printf(sc->sc_dev, =2D "could not create firmware DMA tag\n"); =2D IWI_LOCK(sc); =2D goto fail; =2D } =2D if (bus_dmamem_alloc(sc->fw_dmat, &sc->fw_virtaddr, 0, =2D &sc->fw_map) !=3D 0) { =2D device_printf(sc->sc_dev, =2D "could not allocate firmware DMA memory\n"); =2D IWI_LOCK(sc); =2D goto fail2; =2D } =2D if (bus_dmamap_load(sc->fw_dmat, sc->fw_map, sc->fw_virtaddr, =2D sc->fw_dma_size, iwi_dma_map_addr, &sc->fw_physaddr, 0) !=3D 0) { =2D device_printf(sc->sc_dev, "could not load firmware DMA map\n"); =2D IWI_LOCK(sc); =2D goto fail3; =2D } IWI_LOCK(sc); =20 if (iwi_load_firmware(sc, &sc->fw_boot) !=3D 0) { device_printf(sc->sc_dev, "could not load boot firmware %s\n", sc->fw_boot.name); =2D goto fail4; + goto fail; } =20 if (iwi_load_ucode(sc, &sc->fw_uc) !=3D 0) { device_printf(sc->sc_dev, "could not load microcode %s\n", sc->fw_uc.name); =2D goto fail4; + goto fail; } =20 iwi_stop_master(sc); @@ -3181,15 +3219,10 @@ if (iwi_load_firmware(sc, &sc->fw_fw) !=3D 0) { device_printf(sc->sc_dev, "could not load main firmware %s\n", sc->fw_fw.name); =2D goto fail4; + goto fail; } sc->flags |=3D IWI_FLAG_FW_INITED; =20 =2D bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); =2D bus_dmamap_unload(sc->fw_dmat, sc->fw_map); =2D bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); =2D bus_dma_tag_destroy(sc->fw_dmat); =2D if (iwi_config(sc) !=3D 0) { device_printf(sc->sc_dev, "device configuration failed\n"); goto fail; @@ -3213,10 +3246,6 @@ sc->flags &=3D ~IWI_FLAG_FW_LOADING; return; =20 =2Dfail4: bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); =2D bus_dmamap_unload(sc->fw_dmat, sc->fw_map); =2Dfail3: bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); =2Dfail2: bus_dma_tag_destroy(sc->fw_dmat); fail: ifp->if_flags &=3D ~IFF_UP; sc->flags &=3D ~IWI_FLAG_FW_LOADING; iwi_stop(sc); Index: if_iwireg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/dev/iwi/if_iwireg.h,v retrieving revision 1.13 diff -u -r1.13 if_iwireg.h =2D-- if_iwireg.h 23 Oct 2006 00:34:07 -0000 1.13 +++ if_iwireg.h 18 Feb 2007 15:15:37 -0000 @@ -144,6 +144,9 @@ #define IWI_FW_GET_MAJOR(ver) ((ver) & 0xff) #define IWI_FW_GET_MINOR(ver) (((ver) & 0xff00) >> 8) =20 +/* max firmware size in command blocks (0x1fff) */ +#define IWI_FW_CB_MAX 26 + #define IWI_FW_MODE_UCODE 0 #define IWI_FW_MODE_BOOT 0 #define IWI_FW_MODE_BSS 0 --Boundary-01=_16G2FC0/L+z46iA-- --nextPart1505776.Wia5angaEs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF2G66XyyEoT62BG0RAvJwAJ99xKCWQJoEOLKds+8e7COPmLuD2wCcDuQJ meb+m9sKDwbiy8H+aY62iME= =e93m -----END PGP SIGNATURE----- --nextPart1505776.Wia5angaEs-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 15:54:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83F7816A400 for ; Sun, 18 Feb 2007 15:54:52 +0000 (UTC) (envelope-from doginou@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.freebsd.org (Postfix) with ESMTP id C233B13C471 for ; Sun, 18 Feb 2007 15:54:51 +0000 (UTC) (envelope-from doginou@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id l1IGDXQG043612; Sun, 18 Feb 2007 17:13:33 +0100 (CET) (envelope-from doginou@dong.ci0.org) Received: (from doginou@localhost) by dong.ci0.org (8.13.8/8.13.8/Submit) id l1IGDWDR043611; Sun, 18 Feb 2007 17:13:32 +0100 (CET) (envelope-from doginou) Date: Sun, 18 Feb 2007 17:13:32 +0100 From: Olivier Houchard To: Max Laier Message-ID: <20070218161332.GA42920@ci0.org> References: <200702161738.35142.max@love2party.net> <20070216085132.A7944@xorpc.icir.org> <200702181620.26610.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702181620.26610.max@love2party.net> User-Agent: Mutt/1.4.1i Cc: Jeremie Le Hen , Luigi Rizzo , "V.Chukharev" , freebsd-net@freebsd.org Subject: Re: iwi leaks memory? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 15:54:52 -0000 On Sun, Feb 18, 2007 at 04:20:18PM +0100, Max Laier wrote: > On Friday 16 February 2007 17:51, Luigi Rizzo wrote: > > On Fri, Feb 16, 2007 at 05:38:28PM +0100, Max Laier wrote: > > ... > > > > > I'm under the impression that this is more a problem of increasing > > > fragmentation until we can't get a big enough unfragmented chunk. I > > > don't have any proof of this assumption yet. > > > > makes sense. > > As a matter of fact i wonder whether it wouldn't be smarter > > to allocate the dma-ble memory on the first request and > > keep it around until the driver is unloaded. > > > > If i read the code in iwi_load_firmware() correctly, > > the contiguous chunks cannot be longer than 8191 bytes, > > so a single contiguous buffer is not mandatory. > > I just don't know if we can write the firmware to the adapter > > with multiple operations (lists of command blocks) or > > it needs to be just a single list ? > > The linux driver uses one continuous buffer as well. I tried to hand in > separate buffers, but it failed to initialize the firmware. Attached is > a diff (for HEAD and RELENG_6) to allocate the DMA buffer once and keep > it around. As I said earlier: As long as the firmware is as (un)stable > as it is now, this might be the only sensible way. All in all it's not > that bad, as we "only" throw away 212966 bytes. > > Could you please confirm that this works for you? > Should do, that's what my patch did too :-) Mine tried to re-allocate memory only if the new firmware size was > the old one, not sure it's useful. Olivier From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 16:58:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B3C716A400; Sun, 18 Feb 2007 16:58:58 +0000 (UTC) (envelope-from chukharev@mail.ru) Received: from mx2.mail.ru (mx2-2.mail.ru [194.67.23.122]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC9013C46B; Sun, 18 Feb 2007 16:58:57 +0000 (UTC) (envelope-from chukharev@mail.ru) Received: from [85.156.232.99] (port=62592 helo=localhost) by mx2.mail.ru with asmtp id 1HIpNH-000PN0-00; Sun, 18 Feb 2007 19:58:56 +0300 Date: Sun, 18 Feb 2007 18:58:52 +0200 To: "Max Laier" , "Luigi Rizzo" From: "V.Chukharev" Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 References: <200702161738.35142.max@love2party.net> <20070216085132.A7944@xorpc.icir.org> <200702181620.26610.max@love2party.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <200702181620.26610.max@love2party.net> User-Agent: Opera Mail/9.10 (FreeBSD) Cc: freebsd-net@freebsd.org, Jeremie Le Hen , cognet@freebsd.org Subject: Re: iwi leaks memory? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 16:58:58 -0000 On Sun, 18 Feb 2007 17:20:18 +0200, Max Laier wrote: > The linux driver uses one continuous buffer as well. I tried to hand in > separate buffers, but it failed to initialize the firmware. Attached is > a diff (for HEAD and RELENG_6) to allocate the DMA buffer once and keep > it around. As I said earlier: As long as the firmware is as (un)stable > as it is now, this might be the only sensible way. All in all it's not > that bad, as we "only" throw away 212966 bytes. > > Could you please confirm that this works for you? Sorry, I cannot apply the patch. The versions seem to be correct. I even tried both patches... Regards, -- V. Chukharev From owner-freebsd-net@FreeBSD.ORG Sun Feb 18 23:12:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EE1F16A407 for ; Sun, 18 Feb 2007 23:12:38 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.freebsd.org (Postfix) with ESMTP id 25BA913C4AC for ; Sun, 18 Feb 2007 23:12:37 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id B1E2BBF8CE4; Mon, 19 Feb 2007 00:12:36 +0100 (CET) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id D21E8BD19; Sun, 18 Feb 2007 18:12:57 -0500 (EST) Date: Sun, 18 Feb 2007 18:12:57 -0500 From: Yann Berthier To: Max Laier Message-ID: <20070218231257.GF1384@bashibuzuk.net> References: <200702161738.35142.max@love2party.net> <20070216085132.A7944@xorpc.icir.org> <200702181620.26610.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702181620.26610.max@love2party.net> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: iwi leaks memory? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2007 23:12:38 -0000 On Sun, 18 Feb 2007, at 16:20, Max Laier wrote: > The linux driver uses one continuous buffer as well. I tried to hand in > separate buffers, but it failed to initialize the firmware. Attached is > a diff (for HEAD and RELENG_6) to allocate the DMA buffer once and keep > it around. As I said earlier: As long as the firmware is as (un)stable > as it is now, this might be the only sensible way. All in all it's not > that bad, as we "only" throw away 212966 bytes. > > Could you please confirm that this works for you? Patch applied and in use - iwi is now able to survive regular down/up link events. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 08:13:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30A6A16A400 for ; Mon, 19 Feb 2007 08:13:16 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5701813C48E for ; Mon, 19 Feb 2007 08:13:14 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 7353 invoked by uid 1004); 19 Feb 2007 08:13:13 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.11):. Processed in 0.088532 secs); 19 Feb 2007 08:13:13 -0000 Received: from unknown (HELO ?217.25.23.11?) (217.25.23.11) by ns0.azuni.net with AES256-SHA encrypted SMTP; 19 Feb 2007 08:13:12 -0000 Message-ID: <45D95C07.9060409@azuni.net> Date: Mon, 19 Feb 2007 12:12:55 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Santos References: <45D85EA3.2050102@azuni.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 08:13:16 -0000 Andre Santos wrote: > On 2/18/07, admin wrote: > >> Hi, I'm trying to use ipfw's limit clause to limit the number of >> connections a single IP can have at the same time in a transparent >> web-proxy environment: >> >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port >> 80 in via if0 setup limit src-addr 10 >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 >> ... the rest fwd... >> >> as I understand the manpage, when the current number of connectiions is >> below 10, the action "skipto" is performed, else, the packet is dropped >> and the search terminates. But... >> >> the problem is that the src-addr limit is not enforced as some clients >> somehow open a huge number (3-5 times the prescribed value) of >> www-connections to some single address Out There, forcing you to bump up >> certain sysctl variables (such as kern.ipc.nmbclusters, >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be >> going on? Is ipfw broken, or am I misusing it? >> >> OS: FreeBSD 6.2 > > > The following command worked here (6.2-RC1). Only one connection was > allowed to 1.2.3.4. > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 > > Use the command "ipfw -d show" to see what connections are matching > your dynamic rules. > # ipfw -d show | fgrep x.x.x.x | wc -l 20 $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l 113 Why is it that only 20 connections have been accounted for by ipfw's dynamic rules but there are actually 113 active connections from that IP at the moment? The limit src-addr is 75. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 11:08:28 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23F6E16A49C for ; Mon, 19 Feb 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0C54A13C4BC for ; Mon, 19 Feb 2007 11:08:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l1JB8R0n021419 for ; Mon, 19 Feb 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l1JB8QEt021415 for freebsd-net@FreeBSD.org; Mon, 19 Feb 2007 11:08:26 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Feb 2007 11:08:26 GMT Message-Id: <200702191108.l1JB8QEt021415@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 11:08:28 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 12:07:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30FFE16A408 for ; Mon, 19 Feb 2007 12:07:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8C6A813C471 for ; Mon, 19 Feb 2007 12:07:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id WAA27901; Mon, 19 Feb 2007 22:43:02 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 19 Feb 2007 22:43:00 +1100 (EST) From: Ian Smith To: admin In-Reply-To: <45D95C07.9060409@azuni.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Andre Santos Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 12:07:10 -0000 On Mon, 19 Feb 2007, admin wrote: > Andre Santos wrote: > > On 2/18/07, admin wrote: > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > >> connections a single IP can have at the same time in a transparent > >> web-proxy environment: > >> > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > >> 80 in via if0 setup limit src-addr 10 > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > >> ... the rest fwd... > >> > >> as I understand the manpage, when the current number of connectiions is > >> below 10, the action "skipto" is performed, else, the packet is dropped > >> and the search terminates. But... No, a packet is not dropped on a condition that fails a skipto test. skipto number Skip all subsequent rules numbered less than number. The search continues with the first rule numbered number or higher. You'll need a specific allow or deny rule; skipto does neither, it just branches to 401 if the condition is matched, otherwise proceeds to the next rule, which is also 401. This runs rule 401 and on, either way. > >> the problem is that the src-addr limit is not enforced as some clients > >> somehow open a huge number (3-5 times the prescribed value) of > >> www-connections to some single address Out There, forcing you to bump up > >> certain sysctl variables (such as kern.ipc.nmbclusters, > >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be > >> going on? Is ipfw broken, or am I misusing it? You've misread skipto, is all. As it stands, the counts will show how many packets passed the test, but all packets proceed to the next rule. I'd rephrase rules to use skipto only for branching on condition, or !condition, past specific allow and/or deny rules to deal with this. > >> OS: FreeBSD 6.2 > > > > > > The following command worked here (6.2-RC1). Only one connection was > > allowed to 1.2.3.4. > > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 > > > > Use the command "ipfw -d show" to see what connections are matching > > your dynamic rules. > > > > # ipfw -d show | fgrep x.x.x.x | wc -l > 20 > $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l > 113 > > Why is it that only 20 connections have been accounted for by ipfw's > dynamic rules but there are actually 113 active connections from that IP > at the moment? The limit src-addr is 75. See above. Sorry I didn't notice this when you first posted it. I've not yet used limit src-addr myself, but use skipto a lot :) Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 12:40:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21C8916A402 for ; Mon, 19 Feb 2007 12:40:27 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id 219A813C4BB for ; Mon, 19 Feb 2007 12:40:25 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 28259 invoked by uid 1004); 19 Feb 2007 12:40:24 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.11):. Processed in 0.309482 secs); 19 Feb 2007 12:40:24 -0000 Received: from unknown (HELO ?217.25.23.11?) (217.25.23.11) by ns0.azuni.net with AES256-SHA encrypted SMTP; 19 Feb 2007 12:40:23 -0000 Message-ID: <45D99AA2.7070406@azuni.net> Date: Mon, 19 Feb 2007 16:40:02 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Andre Santos Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 12:40:27 -0000 Ian Smith wrote: > On Mon, 19 Feb 2007, admin wrote: > > Andre Santos wrote: > > > On 2/18/07, admin wrote: > > > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > > >> connections a single IP can have at the same time in a transparent > > >> web-proxy environment: > > >> > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > > >> 80 in via if0 setup limit src-addr 10 > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > >> ... the rest fwd... > > >> > > >> as I understand the manpage, when the current number of connectiions is > > >> below 10, the action "skipto" is performed, else, the packet is dropped > > >> and the search terminates. But... > > No, a packet is not dropped on a condition that fails a skipto test. > The manpage doesn't make this point clear. limit {src-addr | src-port | dst-addr | dst-port} N The firewall will only allow N connections with the same set of parameters as specified in the rule. To limit the number of connections a user can open you can use the following type of rules: ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 ipfw add allow tcp from any to me setup limit src-addr 4 I'm assuming the packet gets silently dropped when the limit is overloaded but gets acted upon otherwise due to the stateful "limit" behaviour (keep-state in disguise). Just do a "skipto" when there's a state entry and that's it. And that's why the counter grows for established connections too, even though there's a "setup" modifier. skipto is a nice thing as it allows you to AND rules ;-) Besides, that's what my humble testing came up with - connections over the limit DO get dropped... if done nicely. As for the problem, it seems to me that all this noise is because of different timeouts in ipfw and TCP layer/whatever. The dynamic state entry for a connection expires while netstat -na still show the connection as ESTABLISHED, or, worse, the state entry is still there but the corresponding connection is in some half-closed state (FIN_WAIT_2, CLOSE_WAIT, LAST_ACK). The first case allows many more connections than "limit", while the second case won't let many good clients connect due to their buggy browsers not closing connections and letting the count build up. Could this be it? > skipto number > Skip all subsequent rules numbered less than number. The search > continues with the first rule numbered number or higher. > > You'll need a specific allow or deny rule; skipto does neither, it just > branches to 401 if the condition is matched, otherwise proceeds to the > next rule, which is also 401. This runs rule 401 and on, either way. > > > >> the problem is that the src-addr limit is not enforced as some clients > > >> somehow open a huge number (3-5 times the prescribed value) of > > >> www-connections to some single address Out There, forcing you to bump up > > >> certain sysctl variables (such as kern.ipc.nmbclusters, > > >> kern.ipc.maxsockets, etc.) to mitigate the DOS effects. What might be > > >> going on? Is ipfw broken, or am I misusing it? > > You've misread skipto, is all. As it stands, the counts will show how > many packets passed the test, but all packets proceed to the next rule. > > I'd rephrase rules to use skipto only for branching on condition, or > !condition, past specific allow and/or deny rules to deal with this. > > > >> OS: FreeBSD 6.2 > > > > > > > > > The following command worked here (6.2-RC1). Only one connection was > > > allowed to 1.2.3.4. > > > # ipfw add 1 allow tcp from any to 1.2.3.4 22 out via rl1 limit dst-addr 1 > > > > > > Use the command "ipfw -d show" to see what connections are matching > > > your dynamic rules. > > > > > > > # ipfw -d show | fgrep x.x.x.x | wc -l > > 20 > > $ netstat -na|fgrep x.x.x.x|fgrep ESTABLISHED|wc -l > > 113 > > > > Why is it that only 20 connections have been accounted for by ipfw's > > dynamic rules but there are actually 113 active connections from that IP > > at the moment? The limit src-addr is 75. > > See above. Sorry I didn't notice this when you first posted it. I've > not yet used limit src-addr myself, but use skipto a lot :) > > Cheers, Ian > > From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 14:20:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B3F516A400; Mon, 19 Feb 2007 14:20:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id A88E013C491; Mon, 19 Feb 2007 14:20:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id BAA02426; Tue, 20 Feb 2007 01:20:13 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 20 Feb 2007 01:20:12 +1100 (EST) From: Ian Smith To: admin In-Reply-To: <45D99AA2.7070406@azuni.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Andre Santos Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:20:29 -0000 On Mon, 19 Feb 2007, admin wrote: > Ian Smith wrote: > > On Mon, 19 Feb 2007, admin wrote: > > > Andre Santos wrote: > > > > On 2/18/07, admin wrote: > > > > > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > > > >> connections a single IP can have at the same time in a transparent > > > >> web-proxy environment: > > > >> > > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > > > >> 80 in via if0 setup limit src-addr 10 > > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > > >> ... the rest fwd... > > > >> > > > >> as I understand the manpage, when the current number of connectiions is > > > >> below 10, the action "skipto" is performed, else, the packet is dropped > > > >> and the search terminates. But... > > > > No, a packet is not dropped on a condition that fails a skipto test. > > > The manpage doesn't make this point clear. You pretty much have to read it all .. several times .. a year. One of the things you note is that each rule is tested until a packet is either allowed or denied by a rule, even until '65535 deny ip from any to any'. > limit {src-addr | src-port | dst-addr | dst-port} N > The firewall will only allow N connections with the same > set of parameters as specified in the rule. Yes, for this rule. It still needs to be applied to an allow or deny (or forward, divert etc, anything that terminates the search). > To limit the number of connections a user can open you can use the > following type of rules: > ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 > ipfw add allow tcp from any to me setup limit src-addr 4 Yes. Notice that these are allow rules, so the search terminates when successfully matched. It is assumed you'll later have rule/s denying what you've not allowed. True, this is not stated with every example. > I'm assuming the packet gets silently dropped when the limit is > overloaded but gets acted upon otherwise due to the stateful "limit" > behaviour (keep-state in disguise). Just do a "skipto" when there's a > state entry and that's it. And that's why the counter grows for > established connections too, even though there's a "setup" modifier. Can't tell without seeing your whole ruleset, but now that you know that the skipto rule has NOT dropped the setup packets that don't match that rule (including those exceeding the src-addr limit), I suspect you'll find another rule has allowed them, on some other condition, later on. > skipto is a nice thing as it allows you to AND rules ;-) or to OR, NAND or NOR :) Reminds one that a ruleset is procedural. > Besides, that's what my humble testing came up with - connections over > the limit DO get dropped... if done nicely. > > As for the problem, it seems to me that all this noise is because of > different timeouts in ipfw and TCP layer/whatever. The dynamic state > entry for a connection expires while netstat -na still show the > connection as ESTABLISHED, or, worse, the state entry is still there but > the corresponding connection is in some half-closed state (FIN_WAIT_2, > CLOSE_WAIT, LAST_ACK). The first case allows many more connections than > "limit", while the second case won't let many good clients connect due > to their buggy browsers not closing connections and letting the count > build up. Could this be it? I don't believe so. They can only have been established in the first place if the setup packet has been, somewhere in your ruleset, allowed. Here it seems they're allowed (at least the ones from x.x.x.x/x) by the fwd at 401 which has no 'setup' constraint, and will fwd both setup AND established packets from x.x.x.x/x .. other rules, y and z, presumably. Replaying .. trying not to do quite so much in one rule, but given you can't just 'allow' here, since you want to run your fwd rules later: > 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port \ > 80 in via if0 setup limit src-addr 10 00350 skipto 370 tcp from ${thatmob} to any dst-port 80 in via if0 00360 skipto 401 ip from any to any # bit clunky, but !(all that) 00370 skipto 401 tcp from any to any setup limit src-addr 10 # goodies 00380 deny tcp from any to any # else baddies > 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > ... the rest fwd... FWIW: not only have I never used limit src-addr, but neither forward with keep-state rules, so I could be talking ${hit} .. caveat bloggor. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 14:39:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90E1116A401 for ; Mon, 19 Feb 2007 14:39:47 +0000 (UTC) (envelope-from katherrafi@hcl.in) Received: from gws04.hcl.in (gws04.mail.hcl.in [203.105.186.20]) by mx1.freebsd.org (Postfix) with ESMTP id B340713C4A5 for ; Mon, 19 Feb 2007 14:39:46 +0000 (UTC) (envelope-from katherrafi@hcl.in) Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 1A7F6360008 for ; Mon, 19 Feb 2007 19:54:26 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id F0102360007for ; Mon, 19 Feb 2007 19:54:25 +0530 (IST) Received: from CHN-HCLT-EVS01.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 19:54:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Feb 2007 19:51:17 +0530 Message-ID: <6B2C2CD6EB6A2743950CB51B60DEB9462D9DF3@CHN-HCLT-EVS01.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interface routes Thread-Index: AcdUMTZF7T8AJQIiTMusFPKiLRVudA== From: "Kather Rafi -TLS,Chennai" To: X-OriginalArrivalTime: 19 Feb 2007 14:24:25.0904 (UTC) FILETIME=[A86AA300:01C75431] X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-9.6301 TC:1F TRN:50 TV:3.6.1039(15002.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Interface routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:39:47 -0000 Hi, I have doubts in interface routes,=20 1. If we are going to add an interface routes what will be the family it belongs to AF_INET or AF_LINK? 2. How it assigns the interface address as gateway address? Please let me give the details in kernel level coding. =20 Thanks and Regards , Kather Rafi Ibrahim =20 =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 14:57:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23DF416A401 for ; Mon, 19 Feb 2007 14:57:35 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 98BE913C441 for ; Mon, 19 Feb 2007 14:57:34 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 64721 invoked by uid 0); 19 Feb 2007 18:03:34 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 19 Feb 2007 15:03:34 -0000 Message-ID: <45D9BADB.6010405@webmail.sub.ru> Date: Mon, 19 Feb 2007 17:57:31 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: freebsd-net@freebsd.org, FreeBSD Stable Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 14:57:35 -0000 Hello! mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. Tried two completely different boxes, so it cannot be a hardware problem. I'm updating to 6.2 now, but have little hope. What can I turn on in kernel to fix it or at least to make computer reboot? Alex. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 15:50:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2891016A408; Mon, 19 Feb 2007 15:50:12 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.freebsd.org (Postfix) with ESMTP id 8234D13C474; Mon, 19 Feb 2007 15:50:11 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id F3D544271; Mon, 19 Feb 2007 15:25:50 +0000 (GMT) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id YcB9T6gCPs7E; Mon, 19 Feb 2007 15:25:45 +0000 (GMT) Received: from [10.0.2.11] (82-71-32-9.dsl.in-addr.zen.co.uk [82.71.32.9]) by mx0.thekeelecentre.com (Postfix) with ESMTP id BBAC8426B; Mon, 19 Feb 2007 15:25:44 +0000 (GMT) Message-ID: <45D9C174.2050802@thekeelecentre.com> Date: Mon, 19 Feb 2007 15:25:40 +0000 From: Richard Tector User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Alex Povolotsky References: <45D9BADB.6010405@webmail.sub.ru> In-Reply-To: <45D9BADB.6010405@webmail.sub.ru> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090602070701050100060705" Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 15:50:12 -0000 This is a cryptographically signed message in MIME format. --------------ms090602070701050100060705 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Alex Povolotsky wrote: > Hello! > > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. > Tried two completely different boxes, so it cannot be a hardware problem. > > I'm updating to 6.2 now, but have little hope. What can I turn on in > kernel to fix it or at least to make computer reboot? > Which version of mpd are you using? Have you tried the latest version from ports, 4.1? I've read it fixes a *lot* of problems found with the older versions. Richard --------------ms090602070701050100060705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHPDCC A5owggMDoAMCAQICAQcwDQYJKoZIhvcNAQEEBQAwgYExCzAJBgNVBAYTAlVLMRYwFAYDVQQI Ew1TdGFmZm9yZHNoaXJlMQ4wDAYDVQQHEwVLZWVsZTEZMBcGA1UEChMQVGhlIEtlZWxlIENl bnRyZTEvMC0GA1UEAxMmVGhlIEtlZWxlIENlbnRyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDYwOTI5MTQyNTM4WhcNMTAwOTI5MTQyNTM4WjCBijELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxGTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxFzAVBgNVBAMT DlJpY2hhcmQgVGVjdG9yMS8wLQYJKoZIhvcNAQkBFiByaWNoYXJkdGVjdG9yQHRoZWtlZWxl Y2VudHJlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxAE7t9Z0xg5iVOnqE2q7 UhaRoPrygXPXnZ4bHM8P2E4VKfpCP9tmU5rqP/zDwOKwUAFZsv1yHvzMj2d4S8nTP3eC75YY pztd1tiGIUyi2O1vtQuVrcogCC0Xe8TovubsjeosoEN6kujkTLhgWKj+/jDtb0ELiSwh7NnN CoStDvcCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wg R2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBR5NRc2TrF8Qfj9ZMKvq5m5Lh9IFTCB tgYDVR0jBIGuMIGrgBSNCaM0QC1N5Hiyb/MPAVd/ouQEEqGBh6SBhDCBgTELMAkGA1UEBhMC VUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBU aGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRl IEF1dGhvcml0eYIJAJZYbH4e6XXnMA0GCSqGSIb3DQEBBAUAA4GBABy7Pq1hPDwR2vUs9Jlh LHXE1xLe/COWwTjmZ95mnvsX6XL6eVEzuc0xE66Mf1pyFxDKXxTCBj+G/ialE9AYiXTJAAVJ uvhvkm/u1vXdlNlfQJDRnZKFxrZsIT03LIysq+Hb4qZDpQvgWUUyGib4Ze7pNXPp8HOtlTgB ICafws5LMIIDmjCCAwOgAwIBAgIBBzANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCVUsx FjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUg S2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1 dGhvcml0eTAeFw0wNjA5MjkxNDI1MzhaFw0xMDA5MjkxNDI1MzhaMIGKMQswCQYDVQQGEwJV SzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEZMBcGA1UEChMQVGhlIEtlZWxlIENlbnRyZTEX MBUGA1UEAxMOUmljaGFyZCBUZWN0b3IxLzAtBgkqhkiG9w0BCQEWIHJpY2hhcmR0ZWN0b3JA dGhla2VlbGVjZW50cmUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEATu31nTG DmJU6eoTartSFpGg+vKBc9ednhsczw/YThUp+kI/22ZTmuo//MPA4rBQAVmy/XIe/MyPZ3hL ydM/d4LvlhinO13W2IYhTKLY7W+1C5WtyiAILRd7xOi+5uyN6iygQ3qS6ORMuGBYqP7+MO1v QQuJLCHs2c0KhK0O9wIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHk1FzZOsXxB+P1kwq+r mbkuH0gVMIG2BgNVHSMEga4wgauAFI0JozRALU3keLJv8w8BV3+i5AQSoYGHpIGEMIGBMQsw CQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAX BgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5ggkAllhsfh7pdecwDQYJKoZIhvcNAQEEBQADgYEAHLs+rWE8 PBHa9Sz0mWEsdcTXEt78I5bBOOZn3mae+xfpcvp5UTO5zTETrox/WnIXEMpfFMIGP4b+JqUT 0BiJdMkABUm6+G+Sb+7W9d2U2V9AkNGdkoXGtmwhPTcsjKyr4dvipkOlC+BZRTIaJvhl7uk1 c+nwc62VOAEgJp/CzksxggMbMIIDFwIBATCBhzCBgTELMAkGA1UEBhMCVUsxFjAUBgNVBAgT DVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUgQ2Vu dHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0eQIB BzAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wNzAyMTkxNTI1NDBaMCMGCSqGSIb3DQEJBDEWBBRPa5iWyO2ILJknHu3HfTVqeba4 MTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmAYJKwYBBAGCNxAEMYGKMIGHMIGB MQswCQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUx GTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUg Q2VydGlmaWNhdGUgQXV0aG9yaXR5AgEHMIGaBgsqhkiG9w0BCRACCzGBiqCBhzCBgTELMAkG A1UEBhMCVUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYD VQQKExBUaGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRp ZmljYXRlIEF1dGhvcml0eQIBBzANBgkqhkiG9w0BAQEFAASBgJDSNsbzPXoEqmTi0XhBtoHu q2BCpXlvkmpwh+K7ikE4KzRIZAzUQDMX1HPDJzy1vg0g/8XYKBQg1WXqcENLJwC3xXcMktS3 m/ZZESiuqg3UgvTG1aGU/Lhe6y3OCmbOrW0qyeWvrNe+iiLekRaRco30J36BnXxl5EJN8Ytp FzmQAAAAAAAA --------------ms090602070701050100060705-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:00:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43B0716A400 for ; Mon, 19 Feb 2007 16:00:52 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 6D66813C48E for ; Mon, 19 Feb 2007 16:00:51 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 99111 invoked by uid 0); 19 Feb 2007 19:06:51 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 19 Feb 2007 16:06:51 -0000 Message-ID: <45D9C9B0.300@webmail.sub.ru> Date: Mon, 19 Feb 2007 19:00:48 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Richard Tector References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> In-Reply-To: <45D9C174.2050802@thekeelecentre.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:00:52 -0000 Richard Tector wrote: > Alex Povolotsky wrote: >> Hello! >> >> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >> reset. Tried two completely different boxes, so it cannot be a >> hardware problem. >> >> I'm updating to 6.2 now, but have little hope. What can I turn on in >> kernel to fix it or at least to make computer reboot? >> > Which version of mpd are you using? Have you tried the latest version > from ports, 4.1? I've read it fixes a *lot* of problems found with the > older versions. 3.18_5; Is mpd 4 100% backwards compartible? And, what's worse, I've heard of exactly the same problem on 4.0. Kernel _freeze_ should be something kernel-related, I fear. Alex. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:19:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90C9616A400; Mon, 19 Feb 2007 16:19:04 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.freebsd.org (Postfix) with ESMTP id E950113C49D; Mon, 19 Feb 2007 16:19:03 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 450AB41F0; Mon, 19 Feb 2007 16:19:03 +0000 (GMT) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id zTKOqn+-APXj; Mon, 19 Feb 2007 16:18:57 +0000 (GMT) Received: from [10.0.2.11] (82-71-32-9.dsl.in-addr.zen.co.uk [82.71.32.9]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 5C22241FF; Mon, 19 Feb 2007 16:18:54 +0000 (GMT) Message-ID: <45D9CDEA.6010106@thekeelecentre.com> Date: Mon, 19 Feb 2007 16:18:50 +0000 From: Richard Tector User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Alex Povolotsky References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> In-Reply-To: <45D9C9B0.300@webmail.sub.ru> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070007010304030708000500" Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:19:04 -0000 This is a cryptographically signed message in MIME format. --------------ms070007010304030708000500 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Alex Povolotsky wrote: > Richard Tector wrote: >> Alex Povolotsky wrote: >>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>> reset. Tried two completely different boxes, so it cannot be a >>> hardware problem. >>> >> Which version of mpd are you using? Have you tried the latest version >> from ports, 4.1? I've read it fixes a *lot* of problems found with the >> older versions. > > 3.18_5; Is mpd 4 100% backwards compartible? Yes, 4.x should work just fine with your 3.x configuration files. > And, what's worse, I've heard of exactly the same problem on 4.0. Kernel > _freeze_ should be something kernel-related, I fear. Quite possible. It involves putting the interfaces in promiscuous mode so could be due to a bug in your network card driver. What interfaces are you using? Richard --------------ms070007010304030708000500 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHPDCC A5owggMDoAMCAQICAQcwDQYJKoZIhvcNAQEEBQAwgYExCzAJBgNVBAYTAlVLMRYwFAYDVQQI Ew1TdGFmZm9yZHNoaXJlMQ4wDAYDVQQHEwVLZWVsZTEZMBcGA1UEChMQVGhlIEtlZWxlIENl bnRyZTEvMC0GA1UEAxMmVGhlIEtlZWxlIENlbnRyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDYwOTI5MTQyNTM4WhcNMTAwOTI5MTQyNTM4WjCBijELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxGTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxFzAVBgNVBAMT DlJpY2hhcmQgVGVjdG9yMS8wLQYJKoZIhvcNAQkBFiByaWNoYXJkdGVjdG9yQHRoZWtlZWxl Y2VudHJlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxAE7t9Z0xg5iVOnqE2q7 UhaRoPrygXPXnZ4bHM8P2E4VKfpCP9tmU5rqP/zDwOKwUAFZsv1yHvzMj2d4S8nTP3eC75YY pztd1tiGIUyi2O1vtQuVrcogCC0Xe8TovubsjeosoEN6kujkTLhgWKj+/jDtb0ELiSwh7NnN CoStDvcCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wg R2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBR5NRc2TrF8Qfj9ZMKvq5m5Lh9IFTCB tgYDVR0jBIGuMIGrgBSNCaM0QC1N5Hiyb/MPAVd/ouQEEqGBh6SBhDCBgTELMAkGA1UEBhMC VUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBU aGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRl IEF1dGhvcml0eYIJAJZYbH4e6XXnMA0GCSqGSIb3DQEBBAUAA4GBABy7Pq1hPDwR2vUs9Jlh LHXE1xLe/COWwTjmZ95mnvsX6XL6eVEzuc0xE66Mf1pyFxDKXxTCBj+G/ialE9AYiXTJAAVJ uvhvkm/u1vXdlNlfQJDRnZKFxrZsIT03LIysq+Hb4qZDpQvgWUUyGib4Ze7pNXPp8HOtlTgB ICafws5LMIIDmjCCAwOgAwIBAgIBBzANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCVUsx FjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUg S2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1 dGhvcml0eTAeFw0wNjA5MjkxNDI1MzhaFw0xMDA5MjkxNDI1MzhaMIGKMQswCQYDVQQGEwJV SzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEZMBcGA1UEChMQVGhlIEtlZWxlIENlbnRyZTEX MBUGA1UEAxMOUmljaGFyZCBUZWN0b3IxLzAtBgkqhkiG9w0BCQEWIHJpY2hhcmR0ZWN0b3JA dGhla2VlbGVjZW50cmUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEATu31nTG DmJU6eoTartSFpGg+vKBc9ednhsczw/YThUp+kI/22ZTmuo//MPA4rBQAVmy/XIe/MyPZ3hL ydM/d4LvlhinO13W2IYhTKLY7W+1C5WtyiAILRd7xOi+5uyN6iygQ3qS6ORMuGBYqP7+MO1v QQuJLCHs2c0KhK0O9wIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHk1FzZOsXxB+P1kwq+r mbkuH0gVMIG2BgNVHSMEga4wgauAFI0JozRALU3keLJv8w8BV3+i5AQSoYGHpIGEMIGBMQsw CQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAX BgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5ggkAllhsfh7pdecwDQYJKoZIhvcNAQEEBQADgYEAHLs+rWE8 PBHa9Sz0mWEsdcTXEt78I5bBOOZn3mae+xfpcvp5UTO5zTETrox/WnIXEMpfFMIGP4b+JqUT 0BiJdMkABUm6+G+Sb+7W9d2U2V9AkNGdkoXGtmwhPTcsjKyr4dvipkOlC+BZRTIaJvhl7uk1 c+nwc62VOAEgJp/CzksxggMbMIIDFwIBATCBhzCBgTELMAkGA1UEBhMCVUsxFjAUBgNVBAgT DVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUgQ2Vu dHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0eQIB BzAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wNzAyMTkxNjE4NTBaMCMGCSqGSIb3DQEJBDEWBBRyTRJvf4ftaegH0VmDQ0bVn0Tp 3TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmAYJKwYBBAGCNxAEMYGKMIGHMIGB MQswCQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUx GTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUg Q2VydGlmaWNhdGUgQXV0aG9yaXR5AgEHMIGaBgsqhkiG9w0BCRACCzGBiqCBhzCBgTELMAkG A1UEBhMCVUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYD VQQKExBUaGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRp ZmljYXRlIEF1dGhvcml0eQIBBzANBgkqhkiG9w0BAQEFAASBgKpJINsElUZdDs5P6Hfgu1sS wa2hhsU7pHzARNAt77EI2zUMWp2t9nh1O06kD4g1VOkzHodZ9dhIz50kbC6qyc2yg8r85IbG vNb1g+wEnVa0mmQUkD3CQTL+hS86pOIVwlejnwub+Jl/riJv8fWCc818jwQfPOw0vW7KqV2W kaWgAAAAAAAA --------------ms070007010304030708000500-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:28:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 625B116A409 for ; Mon, 19 Feb 2007 16:28:41 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 8973A13C4B7 for ; Mon, 19 Feb 2007 16:28:40 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 11860 invoked by uid 0); 19 Feb 2007 19:34:40 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 19 Feb 2007 16:34:40 -0000 Message-ID: <45D9D033.2020909@webmail.sub.ru> Date: Mon, 19 Feb 2007 19:28:35 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Richard Tector References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> In-Reply-To: <45D9CDEA.6010106@thekeelecentre.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:28:41 -0000 Richard Tector wrote: > Alex Povolotsky wrote: >> Richard Tector wrote: >>> Alex Povolotsky wrote: >>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>> reset. Tried two completely different boxes, so it cannot be a >>>> hardware problem. >>>> >>> Which version of mpd are you using? Have you tried the latest >>> version from ports, 4.1? I've read it fixes a *lot* of problems >>> found with the older versions. >> >> 3.18_5; Is mpd 4 100% backwards compartible? > > Yes, 4.x should work just fine with your 3.x configuration files. > >> And, what's worse, I've heard of exactly the same problem on 4.0. >> Kernel _freeze_ should be something kernel-related, I fear. > > Quite possible. It involves putting the interfaces in promiscuous mode > so could be due to a bug in your network card driver. What interfaces > are you using? Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. Can try em instead Alex. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:34:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF2C016A41F; Mon, 19 Feb 2007 16:34:17 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.freebsd.org (Postfix) with ESMTP id 23B2D13C4AC; Mon, 19 Feb 2007 16:34:17 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id C935941D3; Mon, 19 Feb 2007 16:34:15 +0000 (GMT) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id mRGpYW7aNc0u; Mon, 19 Feb 2007 16:34:05 +0000 (GMT) Received: from [10.0.2.11] (82-71-32-9.dsl.in-addr.zen.co.uk [82.71.32.9]) by mx0.thekeelecentre.com (Postfix) with ESMTP id DB91841CC; Mon, 19 Feb 2007 16:34:02 +0000 (GMT) Message-ID: <45D9D177.5050706@thekeelecentre.com> Date: Mon, 19 Feb 2007 16:33:59 +0000 From: Richard Tector User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Alex Povolotsky References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> <45D9D033.2020909@webmail.sub.ru> In-Reply-To: <45D9D033.2020909@webmail.sub.ru> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030201080202020507000905" Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:34:17 -0000 This is a cryptographically signed message in MIME format. --------------ms030201080202020507000905 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Alex Povolotsky wrote: > Richard Tector wrote: >> Alex Povolotsky wrote: >>> Richard Tector wrote: >>>> Alex Povolotsky wrote: >>>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>>> reset. Tried two completely different boxes, so it cannot be a >>>>> hardware problem. >>>>> >>>> Which version of mpd are you using? Have you tried the latest >>>> version from ports, 4.1? I've read it fixes a *lot* of problems >>>> found with the older versions. >>> >>> 3.18_5; Is mpd 4 100% backwards compartible? >> >> Yes, 4.x should work just fine with your 3.x configuration files. >> >>> And, what's worse, I've heard of exactly the same problem on 4.0. >>> Kernel _freeze_ should be something kernel-related, I fear. >> >> Quite possible. It involves putting the interfaces in promiscuous mode >> so could be due to a bug in your network card driver. What interfaces >> are you using? > > Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. Can > try em instead Or perhaps it doesn't. All I can remember is it requires the bpf netgraph module. If it's a hard lock rather than a panic, perhaps it's a problem with your hardware then? Memory perhaps? Richard --------------ms030201080202020507000905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHPDCC A5owggMDoAMCAQICAQcwDQYJKoZIhvcNAQEEBQAwgYExCzAJBgNVBAYTAlVLMRYwFAYDVQQI Ew1TdGFmZm9yZHNoaXJlMQ4wDAYDVQQHEwVLZWVsZTEZMBcGA1UEChMQVGhlIEtlZWxlIENl bnRyZTEvMC0GA1UEAxMmVGhlIEtlZWxlIENlbnRyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDYwOTI5MTQyNTM4WhcNMTAwOTI5MTQyNTM4WjCBijELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxGTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxFzAVBgNVBAMT DlJpY2hhcmQgVGVjdG9yMS8wLQYJKoZIhvcNAQkBFiByaWNoYXJkdGVjdG9yQHRoZWtlZWxl Y2VudHJlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxAE7t9Z0xg5iVOnqE2q7 UhaRoPrygXPXnZ4bHM8P2E4VKfpCP9tmU5rqP/zDwOKwUAFZsv1yHvzMj2d4S8nTP3eC75YY pztd1tiGIUyi2O1vtQuVrcogCC0Xe8TovubsjeosoEN6kujkTLhgWKj+/jDtb0ELiSwh7NnN CoStDvcCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wg R2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBR5NRc2TrF8Qfj9ZMKvq5m5Lh9IFTCB tgYDVR0jBIGuMIGrgBSNCaM0QC1N5Hiyb/MPAVd/ouQEEqGBh6SBhDCBgTELMAkGA1UEBhMC VUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBU aGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRl IEF1dGhvcml0eYIJAJZYbH4e6XXnMA0GCSqGSIb3DQEBBAUAA4GBABy7Pq1hPDwR2vUs9Jlh LHXE1xLe/COWwTjmZ95mnvsX6XL6eVEzuc0xE66Mf1pyFxDKXxTCBj+G/ialE9AYiXTJAAVJ uvhvkm/u1vXdlNlfQJDRnZKFxrZsIT03LIysq+Hb4qZDpQvgWUUyGib4Ze7pNXPp8HOtlTgB ICafws5LMIIDmjCCAwOgAwIBAgIBBzANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCVUsx FjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUg S2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1 dGhvcml0eTAeFw0wNjA5MjkxNDI1MzhaFw0xMDA5MjkxNDI1MzhaMIGKMQswCQYDVQQGEwJV SzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEZMBcGA1UEChMQVGhlIEtlZWxlIENlbnRyZTEX MBUGA1UEAxMOUmljaGFyZCBUZWN0b3IxLzAtBgkqhkiG9w0BCQEWIHJpY2hhcmR0ZWN0b3JA dGhla2VlbGVjZW50cmUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEATu31nTG DmJU6eoTartSFpGg+vKBc9ednhsczw/YThUp+kI/22ZTmuo//MPA4rBQAVmy/XIe/MyPZ3hL ydM/d4LvlhinO13W2IYhTKLY7W+1C5WtyiAILRd7xOi+5uyN6iygQ3qS6ORMuGBYqP7+MO1v QQuJLCHs2c0KhK0O9wIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHk1FzZOsXxB+P1kwq+r mbkuH0gVMIG2BgNVHSMEga4wgauAFI0JozRALU3keLJv8w8BV3+i5AQSoYGHpIGEMIGBMQsw CQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAX BgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5ggkAllhsfh7pdecwDQYJKoZIhvcNAQEEBQADgYEAHLs+rWE8 PBHa9Sz0mWEsdcTXEt78I5bBOOZn3mae+xfpcvp5UTO5zTETrox/WnIXEMpfFMIGP4b+JqUT 0BiJdMkABUm6+G+Sb+7W9d2U2V9AkNGdkoXGtmwhPTcsjKyr4dvipkOlC+BZRTIaJvhl7uk1 c+nwc62VOAEgJp/CzksxggMbMIIDFwIBATCBhzCBgTELMAkGA1UEBhMCVUsxFjAUBgNVBAgT DVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUgQ2Vu dHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0eQIB BzAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wNzAyMTkxNjMzNTlaMCMGCSqGSIb3DQEJBDEWBBQgLl3jg9UQdKpuGrJxL73NsNro 8zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmAYJKwYBBAGCNxAEMYGKMIGHMIGB MQswCQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUx GTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUg Q2VydGlmaWNhdGUgQXV0aG9yaXR5AgEHMIGaBgsqhkiG9w0BCRACCzGBiqCBhzCBgTELMAkG A1UEBhMCVUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYD VQQKExBUaGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRp ZmljYXRlIEF1dGhvcml0eQIBBzANBgkqhkiG9w0BAQEFAASBgLt5/9c9jSjMr54pUwoadgIC 0TYw4XxjBOO+Q1Puaj2yabTD0JGGQa8s+ZD8ScVqg0XLeg7kp/Efa1ww6TA5Q8kYVv3Dm8Z7 BaABleWFdqtUrfUDjnCYUeLQHo5M2EuotK4Mfu4uUTrLgKCHAi7Oj0SieZPnZ13l11AKExIN QFzxAAAAAAAA --------------ms030201080202020507000905-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:38:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9174116A401 for ; Mon, 19 Feb 2007 16:38:19 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id B845013C4A8 for ; Mon, 19 Feb 2007 16:38:18 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 43631 invoked by uid 1004); 19 Feb 2007 16:38:16 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.11):. Processed in 0.402665 secs); 19 Feb 2007 16:38:16 -0000 Received: from unknown (HELO ?217.25.23.11?) (217.25.23.11) by ns0.azuni.net with AES256-SHA encrypted SMTP; 19 Feb 2007 16:38:16 -0000 Message-ID: <45D9D25E.1050007@azuni.net> Date: Mon, 19 Feb 2007 20:37:50 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:38:19 -0000 Ian Smith wrote: > On Mon, 19 Feb 2007, admin wrote: > > Ian Smith wrote: > > > On Mon, 19 Feb 2007, admin wrote: > > > > Andre Santos wrote: > > > > > On 2/18/07, admin wrote: > > > > > > > > > >> Hi, I'm trying to use ipfw's limit clause to limit the number of > > > > >> connections a single IP can have at the same time in a transparent > > > > >> web-proxy environment: > > > > >> > > > > >> 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port > > > > >> 80 in via if0 setup limit src-addr 10 > > > > >> 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > > > >> ... the rest fwd... > > > > >> > > > > >> as I understand the manpage, when the current number of connectiions is > > > > >> below 10, the action "skipto" is performed, else, the packet is dropped > > > > >> and the search terminates. But... > > > > > > No, a packet is not dropped on a condition that fails a skipto test. > > > > > The manpage doesn't make this point clear. > > You pretty much have to read it all .. several times .. a year. One of > the things you note is that each rule is tested until a packet is either > allowed or denied by a rule, even until '65535 deny ip from any to any'. > > > limit {src-addr | src-port | dst-addr | dst-port} N > > The firewall will only allow N connections with the same > > set of parameters as specified in the rule. > > Yes, for this rule. It still needs to be applied to an allow or deny > (or forward, divert etc, anything that terminates the search). > > > To limit the number of connections a user can open you can use the > > following type of rules: > > ipfw add allow tcp from my-net/24 to any setup limit src-addr 10 > > ipfw add allow tcp from any to me setup limit src-addr 4 > > Yes. Notice that these are allow rules, so the search terminates when > successfully matched. It is assumed you'll later have rule/s denying > what you've not allowed. True, this is not stated with every example. > > > I'm assuming the packet gets silently dropped when the limit is > > overloaded but gets acted upon otherwise due to the stateful "limit" > > behaviour (keep-state in disguise). Just do a "skipto" when there's a > > state entry and that's it. And that's why the counter grows for > > established connections too, even though there's a "setup" modifier. > > Can't tell without seeing your whole ruleset, but now that you know that > the skipto rule has NOT dropped the setup packets that don't match that > rule (including those exceeding the src-addr limit), I suspect you'll > find another rule has allowed them, on some other condition, later on. > Wrong: the implied "check-state" done by the "limit" lets the connection through (i.e. performs the action) iff there's state recorded for it (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet incoming and the number of current states is trying to cross the limit, the SYN packet is implicitly dropped and the search terminates. This is not to say that I completely understand the things going on when the connections start building up (different timeouts?) but the above conclusion is based on what simulation has shown. The whole ruleset fits on one screen, there's an "allow ip from any to any" in the end, so I'm pretty sure I'm not crazy :-) > > As for the problem, it seems to me that all this noise is because of > > different timeouts in ipfw and TCP layer/whatever. The dynamic state > > entry for a connection expires while netstat -na still show the > > connection as ESTABLISHED, or, worse, the state entry is still there but > > the corresponding connection is in some half-closed state (FIN_WAIT_2, > > CLOSE_WAIT, LAST_ACK). The first case allows many more connections than > > "limit", while the second case won't let many good clients connect due > > to their buggy browsers not closing connections and letting the count > > build up. Could this be it? > > I don't believe so. They can only have been established in the first > place if the setup packet has been, somewhere in your ruleset, allowed. > Yup. Then, after setting up the connections, the state times out earlier than the actual connection shown by netstat! Gotta play a bit more with the *_lifetime sysctls... And yes (answering to someone else on the list), net.inet.ip.fw.dyn_keepalive is on: I don't tend to mess with the default values of things I don't understand or care about... only what's absolutely necessary. > Here it seems they're allowed (at least the ones from x.x.x.x/x) by the > fwd at 401 which has no 'setup' constraint, and will fwd both setup AND > established packets from x.x.x.x/x .. other rules, y and z, presumably. > > Replaying .. trying not to do quite so much in one rule, but given you > can't just 'allow' here, since you want to run your fwd rules later: > > > 00350 skipto 401 tcp from x.x.x.x/x,y.y.y.y/y,z.z.z.z/z to any dst-port \ > > 80 in via if0 setup limit src-addr 10 > > 00350 skipto 370 tcp from ${thatmob} to any dst-port 80 in via if0 > 00360 skipto 401 ip from any to any # bit clunky, but !(all that) > > 00370 skipto 401 tcp from any to any setup limit src-addr 10 # goodies > 00380 deny tcp from any to any # else baddies > > > 00401 fwd local.ip.ad.dr,8080 tcp from x.x.x.x/x to any dst-port 80 > > ... the rest fwd... Rule 380 is good for capturing bogus or late-coming connection packets (when state entry has already expired). Once again, its use for denying over-limit connection attempts is debatable as "limit" will already have done that. > > FWIW: not only have I never used limit src-addr, but neither forward > with keep-state rules, so I could be talking ${hit} .. caveat bloggor. > > Cheers, Ian > > I should've read the mail backwards :-) Then please don't pay any attention to what I wrote. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 16:43:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ABE916A41F for ; Mon, 19 Feb 2007 16:43:08 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id B909213C4A3 for ; Mon, 19 Feb 2007 16:43:07 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 18804 invoked by uid 0); 19 Feb 2007 19:49:08 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 19 Feb 2007 16:49:08 -0000 Message-ID: <45D9D399.3090005@webmail.sub.ru> Date: Mon, 19 Feb 2007 19:43:05 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Richard Tector References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> <45D9D033.2020909@webmail.sub.ru> <45D9D177.5050706@thekeelecentre.com> In-Reply-To: <45D9D177.5050706@thekeelecentre.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 16:43:08 -0000 Richard Tector wrote: > Alex Povolotsky wrote: >> Richard Tector wrote: >>> Alex Povolotsky wrote: >>>> Richard Tector wrote: >>>>> Alex Povolotsky wrote: >>>>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>>>> reset. Tried two completely different boxes, so it cannot be a >>>>>> hardware problem. >>>>>> >>>>> Which version of mpd are you using? Have you tried the latest >>>>> version from ports, 4.1? I've read it fixes a *lot* of problems >>>>> found with the older versions. >>>> >>>> 3.18_5; Is mpd 4 100% backwards compartible? >>> >>> Yes, 4.x should work just fine with your 3.x configuration files. >>> >>>> And, what's worse, I've heard of exactly the same problem on 4.0. >>>> Kernel _freeze_ should be something kernel-related, I fear. >>> >>> Quite possible. It involves putting the interfaces in promiscuous >>> mode so could be due to a bug in your network card driver. What >>> interfaces are you using? >> >> Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. >> Can try em instead > > Or perhaps it doesn't. All I can remember is it requires the bpf > netgraph module. > No, it just requires bpf module to allow tcpdump on ngXX. > If it's a hard lock rather than a panic, perhaps it's a problem with > your hardware then? Memory perhaps? Not possible. Two boxes without a single common thing, save maybe a network card. And works flawless without mpd. Alex. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 17:06:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18B2316A6DF for ; Mon, 19 Feb 2007 17:06:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9D30A13C481 for ; Mon, 19 Feb 2007 17:06:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.42.219] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1HJBxn0F0R-0007BC; Mon, 19 Feb 2007 18:06:12 +0100 From: Max Laier Organization: FreeBSD To: Alex Povolotsky Date: Mon, 19 Feb 2007 18:05:56 +0100 User-Agent: KMail/1.9.5 References: <45D9BADB.6010405@webmail.sub.ru> In-Reply-To: <45D9BADB.6010405@webmail.sub.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1233824.19YcUT9GPk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702191806.03621.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX18HwazMKMj1mZLdKy185i7W/R72L9XN/dNqvJORmBBUXt2jtrU4I8zwC4BPxjNQKrTNOzRYSitH+cflGi/to2rN4bLsZ0DrMwcTWiVLwB/DJQ== Cc: freebsd-net@freebsd.org Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 17:06:14 -0000 --nextPart1233824.19YcUT9GPk Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [ Removing -stable from CC ] On Monday 19 February 2007 15:57, Alex Povolotsky wrote: > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to > reset. Tried two completely different boxes, so it cannot be a hardware > problem. > > I'm updating to 6.2 now, but have little hope. What can I turn on in > kernel to fix it or at least to make computer reboot? How do you figure it's mpd related? Did you collect *any* debugging=20 information at all? How about enabling DDB and WITNESS? A "hanging"=20 system usually suggests a deadlock. WITNESS should turn up possible=20 causes. Also, could you check if setting debug.mpsafenet=3D0 in=20 loader.conf helps? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1233824.19YcUT9GPk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF2dj7XyyEoT62BG0RAnMmAJ9K1L9i6mSF2CCnRxonTPtQPZHNlQCdFtLb 01MyuiG3OUr7KCRfENx2Ii0= =UXUk -----END PGP SIGNATURE----- --nextPart1233824.19YcUT9GPk-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 17:29:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9251B16AA6D for ; Mon, 19 Feb 2007 17:29:18 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.freebsd.org (Postfix) with ESMTP id 65FFF13C467 for ; Mon, 19 Feb 2007 17:29:18 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 2266DD836; Mon, 19 Feb 2007 12:02:44 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 8FB0B61C8C; Mon, 19 Feb 2007 12:02:45 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17881.55349.540268.887090@canoe.dclg.ca> Date: Mon, 19 Feb 2007 12:02:45 -0500 To: freebsd-net@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Subject: Status of iwi vs. iwiNG? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 17:29:18 -0000 I'd like to know the status of the iwi driver vs. iwiNG. I've been using iwiNG for some time now and I don't see any notes in the CVS log of iwi that the changes have been merged. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 18:24:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C50CA16B693 for ; Mon, 19 Feb 2007 18:24:16 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id F412613C471 for ; Mon, 19 Feb 2007 18:24:15 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 63856 invoked by uid 0); 19 Feb 2007 21:30:15 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 19 Feb 2007 18:30:15 -0000 Message-ID: <45D9EB48.1040302@webmail.sub.ru> Date: Mon, 19 Feb 2007 21:24:08 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Max Laier References: <45D9BADB.6010405@webmail.sub.ru> <200702191806.03621.max@love2party.net> In-Reply-To: <200702191806.03621.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 18:24:17 -0000 Max Laier wrote: > [ Removing -stable from CC ] > > On Monday 19 February 2007 15:57, Alex Povolotsky wrote: > >> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >> reset. Tried two completely different boxes, so it cannot be a hardware >> problem. >> >> I'm updating to 6.2 now, but have little hope. What can I turn on in >> kernel to fix it or at least to make computer reboot? >> > > How do you figure it's mpd related? Did you collect *any* debugging > information at all? How about enabling DDB and WITNESS? A "hanging" > system usually suggests a deadlock. WITNESS should turn up possible > causes. Also, could you check if setting debug.mpsafenet=0 in > loader.conf helps? > > Well, I'll try new kernel tomorrow; I've rebuild non-SMP kernel, so mpsafenet should not be of any use? Alex. From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 20:29:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13DB616D0D1 for ; Mon, 19 Feb 2007 20:29:27 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4C25C13C441 for ; Mon, 19 Feb 2007 20:29:26 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 20988925; Mon, 19 Feb 2007 22:29:25 +0200 Message-ID: <45DA08A4.3040000@alkar.net> Date: Mon, 19 Feb 2007 22:29:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Povolotsky References: <1171909390.00691163.1171897201@10.7.7.3> In-Reply-To: <1171909390.00691163.1171897201@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 20:29:27 -0000 Hi. Alex Povolotsky wrote: > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. > Tried two completely different boxes, so it cannot be a hardware problem. > > I'm updating to 6.2 now, but have little hope. What can I turn on in > kernel to fix it or at least to make computer reboot? I didn't check this, but have heard that this can hapend if you are trying to send tunnel (pptp/l2tp/...) traffic inside this tunnel. It can make infinite loop and consume all possible resources. Check your routing table for possible traffic loop. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 20:37:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 666CF16D2A7 for ; Mon, 19 Feb 2007 20:37:50 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9CD3413C461 for ; Mon, 19 Feb 2007 20:37:49 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 20989099; Mon, 19 Feb 2007 22:37:48 +0200 Message-ID: <45DA0A9C.2070308@alkar.net> Date: Mon, 19 Feb 2007 22:37:48 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1171909390.00691163.1171897201@10.7.7.3> <1171913004.00691182.1171900802@10.7.7.3> <1171913005.00691192.1171901402@10.7.7.3> <1171913007.00691195.1171902602@10.7.7.3> <1171916581.00691204.1171903201@10.7.7.3> <1171916586.00691205.1171903801@10.7.7.3> In-Reply-To: <1171916586.00691205.1171903801@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 20:37:50 -0000 Richard Tector wrote: > Or perhaps it doesn't. All I can remember is it requires the bpf > netgraph module. ng_bpf is not from this opera. It does just packets filtering by bpf-like filter program and it is not related to interfaces and traffic capturing. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Mon Feb 19 23:14:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1676416F164; Mon, 19 Feb 2007 23:14:45 +0000 (UTC) (envelope-from a.pirko@inode.at) Received: from mailbackup.inode.at (mailbackup.inode.at [213.229.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id C0B0913C441; Mon, 19 Feb 2007 23:14:44 +0000 (UTC) (envelope-from a.pirko@inode.at) Received: from [62.99.145.5] (port=55252 helo=mx.inode.at) by mailbackup.inode.at with esmtp (Exim 4.62) (envelope-from ) id 1HJBk1-000431-3n; Mon, 19 Feb 2007 17:51:53 +0100 Received: from [85.124.26.15] (port=13810 helo=[192.168.1.11]) by smartmx-05.inode.at with esmtp (Exim 4.50) id 1HJBfv-00042r-1H; Mon, 19 Feb 2007 17:47:39 +0100 Message-ID: <45D9D4A9.5080400@inode.at> Date: Mon, 19 Feb 2007 17:47:37 +0100 From: Armin Pirkovitsch User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-net@freebsd.org, FreeBSD Stable References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> <45D9D033.2020909@webmail.sub.ru> In-Reply-To: <45D9D033.2020909@webmail.sub.ru> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2007 23:14:45 -0000 Alex Povolotsky wrote: > Richard Tector wrote: >> Alex Povolotsky wrote: >>> Richard Tector wrote: >>>> Alex Povolotsky wrote: >>>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>>> reset. Tried two completely different boxes, so it cannot be a >>>>> hardware problem. >>>>> >>>> Which version of mpd are you using? Have you tried the latest >>>> version from ports, 4.1? I've read it fixes a *lot* of problems >>>> found with the older versions. >>> >>> 3.18_5; Is mpd 4 100% backwards compartible? >> >> Yes, 4.x should work just fine with your 3.x configuration files. >> >>> And, what's worse, I've heard of exactly the same problem on 4.0. >>> Kernel _freeze_ should be something kernel-related, I fear. >> >> Quite possible. It involves putting the interfaces in promiscuous mode >> so could be due to a bug in your network card driver. What interfaces >> are you using? > > Proimisc?... hmm... fxp. Rock solid thing, as far as I can remember. Can > try em instead I have the same problem but use a sis nic - so I doubt it's the nic driver... (and if going to promiscuous mode was unstable on different drivers I guess some people would start to complain ;) ) (I have never encountered a crash when I started a sniffing program) -- Armin Pirkovitsch a.pirko@inode.at From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 06:01:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43E301730A1; Tue, 20 Feb 2007 06:01:06 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5886113C4A6; Tue, 20 Feb 2007 06:01:05 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([87.226.153.33]:34321 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3379171AbXBTFrv (ORCPT + 1 other); Tue, 20 Feb 2007 08:47:51 +0300 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <45DA8B83.3020202@yandex.ru> Date: Tue, 20 Feb 2007 08:47:47 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Alex Povolotsky References: <45D9BADB.6010405@webmail.sub.ru> In-Reply-To: <45D9BADB.6010405@webmail.sub.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 06:01:06 -0000 Alex Povolotsky ÐÉÛÅÔ: > mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to reset. > Tried two completely different boxes, so it cannot be a hardware problem. It's easy to reproduce? Can you try make debug-friendly kernel? http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html > I'm updating to 6.2 now, but have little hope. What can I turn on in > kernel to fix it or at least to make computer reboot? See the above links. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 09:07:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E799174CE3 for ; Tue, 20 Feb 2007 09:07:15 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id E6EED13C4B6 for ; Tue, 20 Feb 2007 09:07:14 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJQxu-0005yc-OV for freebsd-net@freebsd.org; Tue, 20 Feb 2007 01:07:14 -0800 Message-ID: <9056579.post@talk.nabble.com> Date: Tue, 20 Feb 2007 01:07:14 -0800 (PST) From: satimis To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: satimis@yahoo.com Subject: Unable to connect broadband X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 09:07:15 -0000 Hi folks, FreeBSD-6.2-amd64 Onboard NIC Motherboard ASUS M2N-E [url]http://www.excaliberpc.com/ASUS_M2N-E_nForce570_Ultra_Motherboard/M2N-E/partinfo-id-567211.html[/url] Fixed IP address IP address of server (LAN) - 192.168.0.10 Just finished "standard installation" to install the captioned OS. On "Choose Distributions" windown selected "All system sources, binaries and X Window System" On "Network interface information required" window, no NIC was found; [url]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-post.html[/url] so "PLIP0" was selected. Everything went throught w/o problem. On reboote "xterm" was started with evoking "startx. But unable to connect outside World. The onboard NIC seems not detected. # ifconfig[code]plip0: flags=108851 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 :: prefixlen 128 inet 127.0.0.1 netmask 0xff000000[/code] # ping 192.168.0.10[code]PING 192.168.0.10(192.168.0.10): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ......[/code] Please advise how to fix the problem. TIA B.R. satimis -- View this message in context: http://www.nabble.com/Unable-to-connect-broadband-tf3257481.html#a9056579 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 09:35:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29DC8174FD4 for ; Tue, 20 Feb 2007 09:35:18 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9031C13C478 for ; Tue, 20 Feb 2007 09:35:16 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 2735 invoked by uid 1004); 20 Feb 2007 09:35:15 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.4):. Processed in 0.010917 secs); 20 Feb 2007 09:35:15 -0000 Received: from unknown (HELO ?217.25.23.4?) (217.25.23.4) by ns0.azuni.net with AES256-SHA encrypted SMTP; 20 Feb 2007 09:35:15 -0000 Message-ID: <45DAC0CC.6060909@azuni.net> Date: Tue, 20 Feb 2007 13:35:08 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: setting TCP timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 09:35:18 -0000 Is it possible to tweak various TCP timeouts in FreeBSD 6.2? Such as: how long a connection can stay in a FIN_WAIT_2 state. TIA From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 11:02:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2AFA17B87D for ; Tue, 20 Feb 2007 11:02:04 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mailbox.rainbownet.com (85-18-201-116.ip.fastwebnet.it [85.18.201.116]) by mx1.freebsd.org (Postfix) with ESMTP id 759F813C442 for ; Tue, 20 Feb 2007 11:02:03 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from 192.168.42.11 ([87.3.40.94]) (authenticated user aturetta@rainbownet.com) by rainbownet.com (mailbox.rainbownet.com [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 11-md50000000428.tmp for ; Tue, 20 Feb 2007 11:51:03 +0100 Message-ID: <45DACAA9.70902@commit.it> Date: Tue, 20 Feb 2007 11:17:13 +0100 From: Angelo Turetta User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Joe Holden References: <45DA6F6C.6070104@joeholden.co.uk> In-Reply-To: <45DA6F6C.6070104@joeholden.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: aturetta@rainbownet.com X-Spam-Processed: mailbox.rainbownet.com, Tue, 20 Feb 2007 11:51:03 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 87.3.40.94 X-Return-Path: aturetta@commit.it X-MDaemon-Deliver-To: freebsd-net@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: NVIDIA MCP51 Ethernet Interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 11:02:05 -0000 Joe Holden wrote: > Hi collective, > > It's an Athlon 64 board, with an MCP51 NIC, this card is supported under > Linux using the forcedeth driver, having taken a look at if_nve.c, it > doesn't appear to be supported. It's supported by the nfe(4) driver, which has already been committed to 7-CURRENT. For 6-STABLE (and 6.2-RELEASE, previous releases did not even bootstrap on that chipset), please follow the discussions regarding nve/nfe at: http://www.freebsd.org/cgi/query-pr.cgi?pr=108861 and http://docs.freebsd.org/cgi/getmsg.cgi?fetch=127522+0+archive/2007/freebsd-net/20070211.freebsd-net Hope this helps Angelo Turetta From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 12:41:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2EDB16A9F3 for ; Tue, 20 Feb 2007 12:31:24 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.freebsd.org (Postfix) with ESMTP id AF71A13C4A5 for ; Tue, 20 Feb 2007 12:31:24 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from localhost (localhost [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 91AEEB8B3; Tue, 20 Feb 2007 12:31:23 +0000 (GMT) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhDwglqezdwI; Tue, 20 Feb 2007 12:31:17 +0000 (GMT) Received: from [192.168.10.147] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id C7D49B81C; Tue, 20 Feb 2007 12:31:16 +0000 (GMT) Message-ID: <45DAEA11.7090605@joeholden.co.uk> Date: Tue, 20 Feb 2007 12:31:13 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Angelo Turetta References: <45DA6F6C.6070104@joeholden.co.uk> <45DACAA9.70902@commit.it> In-Reply-To: <45DACAA9.70902@commit.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: NVIDIA MCP51 Ethernet Interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 12:41:42 -0000 Angelo Turetta wrote: > Joe Holden wrote: >> Hi collective, >> >> It's an Athlon 64 board, with an MCP51 NIC, this card is supported >> under Linux using the forcedeth driver, having taken a look at >> if_nve.c, it doesn't appear to be supported. > > It's supported by the nfe(4) driver, which has already been committed to > 7-CURRENT. > For 6-STABLE (and 6.2-RELEASE, previous releases did not even bootstrap > on that chipset), please follow the discussions regarding nve/nfe at: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=108861 > and > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=127522+0+archive/2007/freebsd-net/20070211.freebsd-net > > > Hope this helps > Angelo Turetta > Thanks, what about the IDE controller etc, are those all supported? My serial console for that machine isn't currently working, so I won't be able to check if it boots until its connected up. Thanks, Joe From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 13:30:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C821216DB28 for ; Tue, 20 Feb 2007 13:21:33 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id AF1D613C467 for ; Tue, 20 Feb 2007 13:21:33 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJUw1-0001mI-Fn for freebsd-net@freebsd.org; Tue, 20 Feb 2007 05:21:33 -0800 Message-ID: <9056579.post@talk.nabble.com> Date: Tue, 20 Feb 2007 01:07:14 -0800 (PST) From: satimis To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: satimis@yahoo.com Subject: Unable to connect broadband X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 13:30:56 -0000 Hi folks, FreeBSD-6.2-amd64 Onboard NIC Motherboard ASUS M2N-E [url]http://www.excaliberpc.com/ASUS_M2N-E_nForce570_Ultra_Motherboard/M2N-E/partinfo-id-567211.html[/url] Fixed IP address IP address of server (LAN) - 192.168.0.10 Just finished "standard installation" to install the captioned OS. On "Choose Distributions" windown selected "All system sources, binaries and X Window System" On "Network interface information required" window, no NIC was found; [url]http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-post.html[/url] so "PLIP0" was selected. Everything went throught w/o problem. On reboote "xterm" was started with evoking "startx. But unable to connect outside World. The onboard NIC seems not detected. # ifconfig[code]plip0: flags=108851 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 :: prefixlen 128 inet 127.0.0.1 netmask 0xff000000[/code] # ping 192.168.0.10[code]PING 192.168.0.10(192.168.0.10): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ......[/code] Please advise how to fix the problem. TIA B.R. satimis -- View this message in context: http://www.nabble.com/Unable-to-connect-broadband-tf3257481.html#a9056579 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 14:25:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F91016C15C for ; Tue, 20 Feb 2007 13:46:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 381D213CA8F for ; Tue, 20 Feb 2007 13:46:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 26BBD1B68B0; Tue, 20 Feb 2007 08:47:55 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 20 Feb 2007 08:47:55 -0500 X-Sasl-enc: 5J+wmo9PQXa53rWVDiWyeUB10Fy6iqWGb92HeYDpzBxg 1171979274 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 61EEB2BAFE; Tue, 20 Feb 2007 08:47:54 -0500 (EST) Message-ID: <45DAFBCA.8030904@FreeBSD.org> Date: Tue, 20 Feb 2007 13:46:50 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: satimis References: <9056579.post@talk.nabble.com> In-Reply-To: <9056579.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Unable to connect broadband X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 14:25:16 -0000 satimis wrote: > Hi folks, > > FreeBSD-6.2-amd64 > ... > The onboard NIC seems not detected. > In the absence of required information, I speculate your machine has msk(4) or another recent chipset which may be supported in FreeBSD-CURRENT but not FreeBSD-STABLE. Please post the full output of 'pciconf -lv' from booting a recent FreeSBIE version to the list and hopefully someone can offer more help. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 15:08:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C631F170150 for ; Tue, 20 Feb 2007 14:23:53 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9425213C48D for ; Tue, 20 Feb 2007 14:23:53 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l1KENa0p073785; Tue, 20 Feb 2007 06:23:36 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l1KENaMp073784; Tue, 20 Feb 2007 06:23:36 -0800 (PST) (envelope-from rizzo) Date: Tue, 20 Feb 2007 06:23:36 -0800 From: Luigi Rizzo To: David Gilbert Message-ID: <20070220062336.B73545@xorpc.icir.org> References: <17881.55349.540268.887090@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <17881.55349.540268.887090@canoe.dclg.ca>; from dgilbert@dclg.ca on Mon, Feb 19, 2007 at 12:02:45PM -0500 Cc: freebsd-net@freebsd.org Subject: Re: Status of iwi vs. iwiNG? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 15:08:26 -0000 On Mon, Feb 19, 2007 at 12:02:45PM -0500, David Gilbert wrote: > I'd like to know the status of the iwi driver vs. iwiNG. I've been > using iwiNG for some time now and I don't see any notes in the CVS log > of iwi that the changes have been merged. what/where is iwiNG ? luigi From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 15:11:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BCB116E1AD for ; Tue, 20 Feb 2007 14:44:10 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id D792B13C471 for ; Tue, 20 Feb 2007 14:44:07 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-235-229.51-151.net24.it [151.51.229.235]) (authenticated bits=128) by parrot.aev.net (8.13.8/8.13.8) with ESMTP id l1KEod9T086689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Feb 2007 15:50:45 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l1KEifBI059180 for ; Tue, 20 Feb 2007 15:44:41 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45DB0928.9050803@netfence.it> Date: Tue, 20 Feb 2007 15:43:52 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 212.31.247.179 Subject: ntop anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 15:11:47 -0000 Hello. I've installed ntop on a FreeBSD 6.1 machine, it works, but always says that no traffic was collected (yes). Any hint? Is this port working, or, as it was in the past, broken? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 16:14:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07FB016A916 for ; Tue, 20 Feb 2007 16:14:03 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF1B13C441 for ; Tue, 20 Feb 2007 16:14:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.29.26] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1HJXcp2wEY-0000ip; Tue, 20 Feb 2007 17:13:59 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 20 Feb 2007 17:13:48 +0100 User-Agent: KMail/1.9.5 References: <17881.55349.540268.887090@canoe.dclg.ca> <20070220062336.B73545@xorpc.icir.org> In-Reply-To: <20070220062336.B73545@xorpc.icir.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5427776.UGy9PlW1O4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702201713.55025.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 X-Provags-ID2: V01U2FsdGVkX1+DrwmLU3+sws88Q/B1CZxBkjdCNsT+WdzfFMKp7V7zfzq3tp0DVEf6Rvwb33ETZ8tNy9QrIQUIQANuNT9H2eTkPYeuZGr/qgEUgCuRCXajMg== Cc: Luigi Rizzo , David Gilbert Subject: Re: Status of iwi vs. iwiNG? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 16:14:03 -0000 --nextPart5427776.UGy9PlW1O4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 20 February 2007 15:23, Luigi Rizzo wrote: > On Mon, Feb 19, 2007 at 12:02:45PM -0500, David Gilbert wrote: > > I'd like to know the status of the iwi driver vs. iwiNG. I've been > > using iwiNG for some time now and I don't see any notes in the CVS > > log of iwi that the changes have been merged. > > what/where is iwiNG ? The code David probably referers to was committed in "if_iwi.c rev. 1.35,=20 Thu Apr 27 21:43:37 2006 UTC (9 months, 3 weeks ago)" and has been=20 availabe from http://people.freebsd.org/~mlaier/new_iwi/ before. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5427776.UGy9PlW1O4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF2x5DXyyEoT62BG0RAqraAJ9T1B7PB43PU/Q5wfKJhwxmpkxapwCfV7o/ GHmgFD2rNgtgvn53iugyHp0= =v0EW -----END PGP SIGNATURE----- --nextPart5427776.UGy9PlW1O4-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 16:35:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26F8216AE66 for ; Tue, 20 Feb 2007 16:35:27 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 2244213C4AA for ; Tue, 20 Feb 2007 16:35:26 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 13580 invoked by uid 0); 20 Feb 2007 19:41:19 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 20 Feb 2007 16:41:19 -0000 Message-ID: <45DB2342.5000301@webmail.sub.ru> Date: Tue, 20 Feb 2007 19:35:14 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <45D9BADB.6010405@webmail.sub.ru> <45DA8B83.3020202@yandex.ru> In-Reply-To: <45DA8B83.3020202@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 16:35:28 -0000 Andrey V. Elsukov wrote: > Alex Povolotsky ÐÉÛÅÔ: >> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >> reset. Tried two completely different boxes, so it cannot be a >> hardware problem. > > It's easy to reproduce? Can you try make debug-friendly kernel? RELATIVELY easy. It happens about once a day or more often; but it requires someone to press Reset. > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html > Thanks a lot, I've added invariants and witness; if it won't yield any information, I'll try more. So far, this cursed thing is working with some load for 2 hours, that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; any serialconsole setup is useless since it is also a main gateway. If it dies, nothing but physical access can help. Alex. From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 17:35:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0884316A717 for ; Tue, 20 Feb 2007 17:35:10 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C4D8513C4B5 for ; Tue, 20 Feb 2007 17:35:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l1KH8qHv098856; Tue, 20 Feb 2007 12:08:52 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id l1KH8q13026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2007 12:08:52 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200702201708.l1KH8q13026920@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Feb 2007 12:08:51 -0500 To: Alex Povolotsky , "Andrey V. Elsukov" From: Mike Tancsa In-Reply-To: <45DB2342.5000301@webmail.sub.ru> References: <45D9BADB.6010405@webmail.sub.ru> <45DA8B83.3020202@yandex.ru> <45DB2342.5000301@webmail.sub.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org, FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 17:35:10 -0000 At 11:35 AM 2/20/2007, Alex Povolotsky wrote: >Thanks a lot, I've added invariants and witness; if it won't yield >any information, I'll try more. > >So far, this cursed thing is working with some load for 2 hours, >that's much. It does NOT, surely NOT try to tunnel tunnelled >traffic; any serialconsole setup is useless since it is also a main >gateway. If it dies, nothing but physical access can help. Although not a hard fast rule, I have found that if the box locks up to the point where a BREAK on the serial console does not send it to the debugger prompt, is usually a sign of a hardware lockup as opposed to a software bug. What is the chipset of the MB ? Does ichwd work with it to reset it ? ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 18:07:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B75616AAC9 for ; Tue, 20 Feb 2007 18:07:35 +0000 (UTC) (envelope-from satimis@yahoo.com) Received: from web35203.mail.mud.yahoo.com (web35203.mail.mud.yahoo.com [66.163.179.82]) by mx1.freebsd.org (Postfix) with SMTP id D2C9213C47E for ; Tue, 20 Feb 2007 18:07:34 +0000 (UTC) (envelope-from satimis@yahoo.com) Received: (qmail 48951 invoked by uid 60001); 20 Feb 2007 17:40:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KALB8ZTRcbjXnDbZDwoSm38nFMPTJ4vQSfu8EwJ9zSAHFnshp0vCf+0MspSV6RdeUGnt5chNLKatkbxEPjzId9+i/mz0ojJAKsMOoNOZ2OUUufwxbyTwfnlndMFOCbabnRKv/3Pce7V4GYsKV56UX1jZiSgPVt96as0unl5eA0I=; X-YMail-OSG: gGyzsfkVM1kRLCa8c180jvWvYs6CLmnOwRNN3qM21PH9XqQFOPJJF7DrWKuFT6Q.Z7bqzFOAdrorFt1IJ.vN4IAWsRGe8AdgvdvMBXoh.MDO9ZjbSf9xF9u4fs_TljTRgH5wS6AQhkxZOtw- Received: from [220.232.213.178] by web35203.mail.mud.yahoo.com via HTTP; Wed, 21 Feb 2007 01:40:53 CST Date: Wed, 21 Feb 2007 01:40:53 +0800 (CST) From: Stephen Liu To: "Bruce M. Simpson" In-Reply-To: <45DAFBCA.8030904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <446919.47820.qm@web35203.mail.mud.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Unable to connect broadband X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 18:07:35 -0000 Hi Bruce, > Please post the full output of 'pciconf -lv' from booting a recent > FreeSBIE version to the list and hopefully someone can offer more > help. Ran; # pciconf -lv > /home/satimis/pciconf.txt I have the file created containing all output. My problem is how to copy it here, no floppy drive on the FreeBSD-6.2-amd64 box. There is another HD, running slamd64-11.0 Linux, connected to SATA-1 slot of the PC. FreeBSD-6.2-amd64 is connected to SATA-2 slot. I booted SATA-2 running FreeBSD. I can't find the HD on SATA-1 # df only displaying HD on SATA-2 (FreeBSD). # ls /dev ad4 ad4s1 ad4s2 ad4s3 ad4s4 ad4s5 ad4s6 I suppose they are the HD connect to SATA-1. # mount /dev/ad4s2 /mnt ....... incorrect super block Tried /ad4s3/4/5/6 with the same result I can't mount the HD on SATA-1 to copy the file on slamd64-11.0 box. Then I can copy its content here when running slamd64 Linux. I put a thumb-drive on FreeBSD box but I can't find it. # fdisk -l did not work on FreeBSD Please help. I have only xterm windows running on FreeBSD box. TIA B.R. Stephen Liu Send instant messages to your online friends http://uk.messenger.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 19:25:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7629F16C3D5 for ; Tue, 20 Feb 2007 19:25:19 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id A29F213C4AA for ; Tue, 20 Feb 2007 19:25:18 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 82529 invoked by uid 0); 20 Feb 2007 22:31:20 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 20 Feb 2007 19:31:20 -0000 Message-ID: <45DB4B1B.1050605@webmail.sub.ru> Date: Tue, 20 Feb 2007 22:25:15 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Mike Tancsa References: <45D9BADB.6010405@webmail.sub.ru> <45DA8B83.3020202@yandex.ru> <45DB2342.5000301@webmail.sub.ru> <200702201708.l1KH8q13026920@lava.sentex.ca> In-Reply-To: <200702201708.l1KH8q13026920@lava.sentex.ca> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" , FreeBSD Stable Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 19:25:19 -0000 Mike Tancsa wrote: > At 11:35 AM 2/20/2007, Alex Povolotsky wrote: > >> Thanks a lot, I've added invariants and witness; if it won't yield >> any information, I'll try more. >> >> So far, this cursed thing is working with some load for 2 hours, >> that's much. It does NOT, surely NOT try to tunnel tunnelled traffic; >> any serialconsole setup is useless since it is also a main gateway. >> If it dies, nothing but physical access can help. > > Although not a hard fast rule, I have found that if the box locks up > to the point where a BREAK on the serial console does not send it to > the debugger prompt, is usually a sign of a hardware lockup as opposed > to a software bug. > Well... I'll try to get to the box and try serial console.. > What is the chipset of the MB ? Does ichwd work with it to reset it ? Whoops! Thanks, I'll give a try device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' you mean this thing, yes? Alex. From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 21:52:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CE6316CED8; Tue, 20 Feb 2007 21:52:21 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [217.206.238.167]) by mx1.freebsd.org (Postfix) with ESMTP id 14F4A13C441; Tue, 20 Feb 2007 21:51:12 +0000 (UTC) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 641214128; Tue, 20 Feb 2007 21:51:00 +0000 (GMT) X-Virus-Scanned: by amavisd-new at mx0.thekeelecentre.com Received: from mx0.thekeelecentre.com ([217.206.238.167]) by localhost (mailfil.mx0.thekeelecentre.com [217.206.238.165]) (amavisd-new, port 10024) with ESMTP id Ph21XULxnTLb; Tue, 20 Feb 2007 21:50:57 +0000 (GMT) Received: from [10.0.2.11] (82-71-32-9.dsl.in-addr.zen.co.uk [82.71.32.9]) by mx0.thekeelecentre.com (Postfix) with ESMTP id 9C5F54073; Tue, 20 Feb 2007 21:50:56 +0000 (GMT) Message-ID: <45DB6D3A.3070009@thekeelecentre.com> Date: Tue, 20 Feb 2007 21:50:50 +0000 From: Richard Tector User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Sten Daniel Soersdal References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> <45DB6BD2.7090508@gmail.com> In-Reply-To: <45DB6BD2.7090508@gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090007030108010006000105" Cc: freebsd-net@freebsd.org, FreeBSD Stable , Alex Povolotsky Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 21:52:22 -0000 This is a cryptographically signed message in MIME format. --------------ms090007030108010006000105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sten Daniel Soersdal wrote: > Richard Tector wrote: >> Alex Povolotsky wrote: >>> Richard Tector wrote: >>>> Alex Povolotsky wrote: >>>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>>> reset. Tried two completely different boxes, so it cannot be a >>>>> hardware problem. >>>>> >>>> Which version of mpd are you using? Have you tried the latest version >>>> from ports, 4.1? I've read it fixes a *lot* of problems found with >>>> the older versions. >>> 3.18_5; Is mpd 4 100% backwards compartible? >> Yes, 4.x should work just fine with your 3.x configuration files. >> >>> And, what's worse, I've heard of exactly the same problem on 4.0. >>> Kernel _freeze_ should be something kernel-related, I fear. >> Quite possible. It involves putting the interfaces in promiscuous mode >> so could be due to a bug in your network card driver. What interfaces >> are you using? >> > > I'm not sure why mpd would want to put any interface in promiscuous > mode. Neither pppoe, pptp nor l2tp would require promiscuous mode as > they use either strictly unicast or ethernet broadcast. > > Perhaps you could provide some information as the situation where > promiscuous mode is necessary? > It doesn't. Was my mistake. It's been a while since I've used it first hand and I just remembered the requirement of ng_bpf, as I explained in a later mail. Richard --------------ms090007030108010006000105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHPDCC A5owggMDoAMCAQICAQcwDQYJKoZIhvcNAQEEBQAwgYExCzAJBgNVBAYTAlVLMRYwFAYDVQQI Ew1TdGFmZm9yZHNoaXJlMQ4wDAYDVQQHEwVLZWVsZTEZMBcGA1UEChMQVGhlIEtlZWxlIENl bnRyZTEvMC0GA1UEAxMmVGhlIEtlZWxlIENlbnRyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkw HhcNMDYwOTI5MTQyNTM4WhcNMTAwOTI5MTQyNTM4WjCBijELMAkGA1UEBhMCVUsxFjAUBgNV BAgTDVN0YWZmb3Jkc2hpcmUxGTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxFzAVBgNVBAMT DlJpY2hhcmQgVGVjdG9yMS8wLQYJKoZIhvcNAQkBFiByaWNoYXJkdGVjdG9yQHRoZWtlZWxl Y2VudHJlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxAE7t9Z0xg5iVOnqE2q7 UhaRoPrygXPXnZ4bHM8P2E4VKfpCP9tmU5rqP/zDwOKwUAFZsv1yHvzMj2d4S8nTP3eC75YY pztd1tiGIUyi2O1vtQuVrcogCC0Xe8TovubsjeosoEN6kujkTLhgWKj+/jDtb0ELiSwh7NnN CoStDvcCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wg R2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBR5NRc2TrF8Qfj9ZMKvq5m5Lh9IFTCB tgYDVR0jBIGuMIGrgBSNCaM0QC1N5Hiyb/MPAVd/ouQEEqGBh6SBhDCBgTELMAkGA1UEBhMC VUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBU aGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRl IEF1dGhvcml0eYIJAJZYbH4e6XXnMA0GCSqGSIb3DQEBBAUAA4GBABy7Pq1hPDwR2vUs9Jlh LHXE1xLe/COWwTjmZ95mnvsX6XL6eVEzuc0xE66Mf1pyFxDKXxTCBj+G/ialE9AYiXTJAAVJ uvhvkm/u1vXdlNlfQJDRnZKFxrZsIT03LIysq+Hb4qZDpQvgWUUyGib4Ze7pNXPp8HOtlTgB ICafws5LMIIDmjCCAwOgAwIBAgIBBzANBgkqhkiG9w0BAQQFADCBgTELMAkGA1UEBhMCVUsx FjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUg S2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1 dGhvcml0eTAeFw0wNjA5MjkxNDI1MzhaFw0xMDA5MjkxNDI1MzhaMIGKMQswCQYDVQQGEwJV SzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEZMBcGA1UEChMQVGhlIEtlZWxlIENlbnRyZTEX MBUGA1UEAxMOUmljaGFyZCBUZWN0b3IxLzAtBgkqhkiG9w0BCQEWIHJpY2hhcmR0ZWN0b3JA dGhla2VlbGVjZW50cmUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEATu31nTG DmJU6eoTartSFpGg+vKBc9ednhsczw/YThUp+kI/22ZTmuo//MPA4rBQAVmy/XIe/MyPZ3hL ydM/d4LvlhinO13W2IYhTKLY7W+1C5WtyiAILRd7xOi+5uyN6iygQ3qS6ORMuGBYqP7+MO1v QQuJLCHs2c0KhK0O9wIDAQABo4IBFTCCAREwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYd T3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHk1FzZOsXxB+P1kwq+r mbkuH0gVMIG2BgNVHSMEga4wgauAFI0JozRALU3keLJv8w8BV3+i5AQSoYGHpIGEMIGBMQsw CQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUxGTAX BgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5ggkAllhsfh7pdecwDQYJKoZIhvcNAQEEBQADgYEAHLs+rWE8 PBHa9Sz0mWEsdcTXEt78I5bBOOZn3mae+xfpcvp5UTO5zTETrox/WnIXEMpfFMIGP4b+JqUT 0BiJdMkABUm6+G+Sb+7W9d2U2V9AkNGdkoXGtmwhPTcsjKyr4dvipkOlC+BZRTIaJvhl7uk1 c+nwc62VOAEgJp/CzksxggMbMIIDFwIBATCBhzCBgTELMAkGA1UEBhMCVUsxFjAUBgNVBAgT DVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYDVQQKExBUaGUgS2VlbGUgQ2Vu dHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRpZmljYXRlIEF1dGhvcml0eQIB BzAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wNzAyMjAyMTUwNTBaMCMGCSqGSIb3DQEJBDEWBBT7EDl0JkrPWxnGZ1yus/fLNvmA szBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmAYJKwYBBAGCNxAEMYGKMIGHMIGB MQswCQYDVQQGEwJVSzEWMBQGA1UECBMNU3RhZmZvcmRzaGlyZTEOMAwGA1UEBxMFS2VlbGUx GTAXBgNVBAoTEFRoZSBLZWVsZSBDZW50cmUxLzAtBgNVBAMTJlRoZSBLZWVsZSBDZW50cmUg Q2VydGlmaWNhdGUgQXV0aG9yaXR5AgEHMIGaBgsqhkiG9w0BCRACCzGBiqCBhzCBgTELMAkG A1UEBhMCVUsxFjAUBgNVBAgTDVN0YWZmb3Jkc2hpcmUxDjAMBgNVBAcTBUtlZWxlMRkwFwYD VQQKExBUaGUgS2VlbGUgQ2VudHJlMS8wLQYDVQQDEyZUaGUgS2VlbGUgQ2VudHJlIENlcnRp ZmljYXRlIEF1dGhvcml0eQIBBzANBgkqhkiG9w0BAQEFAASBgEyDhF9Dr1zUzot96AKjXrHM NlsDXepTmqYxarmKeXtBGiwJbPpsnAZZP+LaAibgkTQjdDbC5FnV4dMA2aauYB17VbP4yHgl 6Up/i0LyvF9RS6/LXWpM7oe8lJMjAQLWec2ECVsGKYpYGZ50/h9nIMADmUuVRXeE23riNkUX J+lRAAAAAAAA --------------ms090007030108010006000105-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 22:11:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CBBD16B821 for ; Tue, 20 Feb 2007 22:11:47 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id F25BE13C4A7 for ; Tue, 20 Feb 2007 22:11:46 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so495740ana for ; Tue, 20 Feb 2007 14:11:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EwDe4hsfQbdGZ28QCZu6J0jiHNZz03IB1przwnbvQleJdIfyz+wZKsduMIt7Fjq73h455zf2bb7mfrAwrkkAYp5z7HRe2G22+vgyKmW2j+1fkhFY9HKLE4KNGJhcRm+pPP63mYQMK3iLFWN6JraVCmDWEOkAuCDbHUn45wBJ51E= Received: by 10.100.139.9 with SMTP id m9mr3149653and.1172007930521; Tue, 20 Feb 2007 13:45:30 -0800 (PST) Received: from ?192.168.11.5? ( [65.33.136.99]) by mx.google.com with ESMTP id c13sm2663897anc.2007.02.20.13.45.29; Tue, 20 Feb 2007 13:45:29 -0800 (PST) Message-ID: <45DB6BD2.7090508@gmail.com> Date: Tue, 20 Feb 2007 16:44:50 -0500 From: Sten Daniel Soersdal User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Richard Tector References: <45D9BADB.6010405@webmail.sub.ru> <45D9C174.2050802@thekeelecentre.com> <45D9C9B0.300@webmail.sub.ru> <45D9CDEA.6010106@thekeelecentre.com> In-Reply-To: <45D9CDEA.6010106@thekeelecentre.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, FreeBSD Stable , Alex Povolotsky Subject: Re: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 22:11:47 -0000 Richard Tector wrote: > Alex Povolotsky wrote: >> Richard Tector wrote: >>> Alex Povolotsky wrote: >>>> mpd (fresh) on FreeBSD 6.1p12 sometimes hangs system, totally, to >>>> reset. Tried two completely different boxes, so it cannot be a >>>> hardware problem. >>>> >>> Which version of mpd are you using? Have you tried the latest version >>> from ports, 4.1? I've read it fixes a *lot* of problems found with >>> the older versions. >> >> 3.18_5; Is mpd 4 100% backwards compartible? > > Yes, 4.x should work just fine with your 3.x configuration files. > >> And, what's worse, I've heard of exactly the same problem on 4.0. >> Kernel _freeze_ should be something kernel-related, I fear. > > Quite possible. It involves putting the interfaces in promiscuous mode > so could be due to a bug in your network card driver. What interfaces > are you using? > I'm not sure why mpd would want to put any interface in promiscuous mode. Neither pppoe, pptp nor l2tp would require promiscuous mode as they use either strictly unicast or ethernet broadcast. Perhaps you could provide some information as the situation where promiscuous mode is necessary? -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 22:45:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4AE716C8FB for ; Tue, 20 Feb 2007 22:45:34 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id AFA7013C494 for ; Tue, 20 Feb 2007 22:45:34 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 26A031BBB5A for ; Tue, 20 Feb 2007 17:46:41 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Tue, 20 Feb 2007 17:46:41 -0500 X-Sasl-enc: aHUfBxpDz2l7FmFF9pjoDXx91Vx12lzG1oQLHwfvVpKh 1172011600 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5F9FD18F25 for ; Tue, 20 Feb 2007 17:46:39 -0500 (EST) Message-ID: <45DB7A0B.80608@incunabulum.net> Date: Tue, 20 Feb 2007 22:45:31 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: If you run IS-IS please contact me X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 22:45:34 -0000 Anyone out there running IS-IS on a FreeBSD machine, please contact me. It's my understanding that IS-IS requires link-layer multicast support. Therefore I would like to hear from anyone who is running an implementation of it on FreeBSD successfully. I want to make sure it continues to operate in the 6.2-STABLE and 7.0-CURRENT code bases, given that we plan a lot of changes to Ethernet and how it works in those code bases. If you could let me know which implementation of IS-IS you're using, how long you've been running it for, how large the network you route with IS-IS is, and which FreeBSD releases you have been using, that would be most useful. Thank you in advance! Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 23:20:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A858F16D1C8 for ; Tue, 20 Feb 2007 23:20:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 83F5B13C4B5 for ; Tue, 20 Feb 2007 23:20:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 20 Feb 2007 14:55:47 -0800 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id DF12E125B2B; Tue, 20 Feb 2007 15:19:58 -0800 (PST) Message-ID: <45DB821D.4050508@elischer.org> Date: Tue, 20 Feb 2007 15:19:57 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: admin References: <45D9D25E.1050007@azuni.net> In-Reply-To: <45D9D25E.1050007@azuni.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ian Smith , freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 23:20:00 -0000 admin wrote: > > Wrong: the implied "check-state" done by the "limit" lets the connection > through (i.e. performs the action) iff there's state recorded for it > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > incoming and the number of current states is trying to cross the limit, > the SYN packet is implicitly dropped and the search terminates. > > This is not to say that I completely understand the things going on when > the connections start building up (different timeouts?) but the above > conclusion is based on what simulation has shown. The whole ruleset fits > on one screen, there's an "allow ip from any to any" in the end, so I'm > pretty sure I'm not crazy :-) One thing to keep in mind is that a 'check-state' rule works by effectively jumping to the rule that did the 'keep-state' and re-executing it.. (and incrementing its stats). From owner-freebsd-net@FreeBSD.ORG Tue Feb 20 23:38:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40CE916A851 for ; Tue, 20 Feb 2007 23:38:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 021BE13C48D for ; Tue, 20 Feb 2007 23:38:15 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 034A01BBD08; Tue, 20 Feb 2007 18:39:23 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 20 Feb 2007 18:39:23 -0500 X-Sasl-enc: iHGVRLwZPMpb74k9VAKXl+BmrP8RXh/enu/1kbAEmyqq 1172014762 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4F5822D075; Tue, 20 Feb 2007 18:39:22 -0500 (EST) Message-ID: <45DB8666.7060804@FreeBSD.org> Date: Tue, 20 Feb 2007 23:38:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Jouke Witteveen References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> <45C7A1F9.20306@FreeBSD.org> <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> In-Reply-To: <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------010709030902010104020002" Cc: freebsd-net@freebsd.org Subject: Re: ioctl: SIOCADDMULTI (howto?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 23:38:16 -0000 This is a multi-part message in MIME format. --------------010709030902010104020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is a better patch for the netstat output. I haven't had time to look at the kernel yet. If this patch is good for you I'll commit it on -CURRENT. It cleans up the group membership output significantly and displays the Link-layer information separately. If anyone 'out there' has been relying on this output in scripts, please tell me. BMS --------------010709030902010104020002 Content-Type: text/x-patch; name="netstat-mcast.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstat-mcast.diff" --- mcast.c.orig Sat Feb 17 18:12:28 2007 +++ mcast.c Tue Feb 20 23:26:41 2007 @@ -71,21 +71,39 @@ #define MYIFNAME_SIZE 128 void -ifmalist_dump(void) +ifmalist_dump_af(struct ifmaddrs *ifmap, int af) { - struct ifmaddrs *ifmap, *ifma; + struct ifmaddrs *ifma; sockunion_t *psa; char myifname[MYIFNAME_SIZE]; char addrbuf[INET6_ADDRSTRLEN]; char *pcolon; void *addr; - char *pifname, *plladdr, *pgroup; + char *pafname, *pifname, *plladdr, *pgroup; - if (getifmaddrs(&ifmap)) - err(EX_OSERR, "getifmaddrs"); + if (!((af == AF_INET) || (af == AF_LINK) +#ifdef INET6 + || (af == AF_INET6) +#endif + )) + return; + + switch (af) { + case AF_INET: + pafname = "IPv4"; + break; + case AF_INET6: + pafname = "IPv6"; + break; + case AF_LINK: + pafname = "Link-layer"; + break; + } - fputs("IPv4/IPv6 Multicast Group Memberships\n", stdout); - fprintf(stdout, "%-20s\t%-16s\t%s\n", "Group", "Gateway", "Netif"); + fprintf(stdout, "%s Multicast Group Memberships\n", pafname); + fprintf(stdout, "%-20s\t%-16s\t%s\n", "Group", + "Next Hop/L2 Address", + "Netif"); for (ifma = ifmap; ifma; ifma = ifma->ifma_next) { @@ -94,16 +112,32 @@ /* Group address */ psa = (sockunion_t *)ifma->ifma_addr; + if (psa->sa.sa_family != af) + continue; switch (psa->sa.sa_family) { case AF_INET: pgroup = inet_ntoa(psa->sin.sin_addr); break; +#ifdef INET6 case AF_INET6: addr = &psa->sin6.sin6_addr; inet_ntop(psa->sa.sa_family, addr, addrbuf, sizeof(addrbuf)); pgroup = addrbuf; break; +#endif + case AF_LINK: + if ((psa->sdl.sdl_alen == ETHER_ADDR_LEN) || + (psa->sdl.sdl_type == IFT_ETHER)) { + pgroup = +ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data); + } else { + pgroup = addr2ascii(AF_LINK, + &psa->sdl, + sizeof(struct sockaddr_dl), + addrbuf); + } + break; default: continue; /* XXX */ } @@ -116,14 +150,20 @@ plladdr = inet_ntoa(psa->sin.sin_addr); break; case AF_LINK: - if (psa->sdl.sdl_type == IFT_ETHER) - plladdr = ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data); - else - plladdr = link_ntoa(&psa->sdl); + if (psa->sdl.sdl_type == IFT_ETHER) { + plladdr = +ether_ntoa((struct ether_addr *)&psa->sdl.sdl_data); + } else { + plladdr = addr2ascii(AF_LINK, + &psa->sdl, + sizeof(struct sockaddr_dl), + addrbuf); + } break; } - } else + } else { plladdr = ""; + } /* Interface upon which the membership exists */ psa = (sockunion_t *)ifma->ifma_name; @@ -143,6 +183,23 @@ fprintf(stdout, "%-20s\t%-16s\t%s\n", pgroup, plladdr, pifname); } +} + +void +ifmalist_dump(void) +{ + struct ifmaddrs *ifmap; + + if (getifmaddrs(&ifmap)) + err(EX_OSERR, "getifmaddrs"); + + ifmalist_dump_af(ifmap, AF_LINK); + fputs("\n", stdout); + ifmalist_dump_af(ifmap, AF_INET); + fputs("\n", stdout); +#ifdef INET6 + ifmalist_dump_af(ifmap, AF_INET6); +#endif freeifmaddrs(ifmap); } --------------010709030902010104020002-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 00:34:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9273516A408 for ; Wed, 21 Feb 2007 00:34:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 67A3A13C428 for ; Wed, 21 Feb 2007 00:34:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id D50DE1BC0AE; Tue, 20 Feb 2007 19:36:04 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 20 Feb 2007 19:36:04 -0500 X-Sasl-enc: pN4VO6AjsnpnuAwzu4+pwzRNFlhWua09u5iJxpi1bzYk 1172018163 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 762422D07D; Tue, 20 Feb 2007 19:36:03 -0500 (EST) Message-ID: <45DB93AE.7030804@FreeBSD.org> Date: Wed, 21 Feb 2007 00:34:54 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Jouke Witteveen References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> <45C7A1F9.20306@FreeBSD.org> <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> In-Reply-To: <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------000101000609080301020806" Cc: freebsd-net@freebsd.org Subject: Re: ioctl: SIOCADDMULTI (howto?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 00:34:57 -0000 This is a multi-part message in MIME format. --------------000101000609080301020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jouke Witteveen wrote: > > I hope someone can find a spare minute to look at if_findmulti. It > would help me quite much. I verified with mtest that FreeBSD cannot delete an AF_LINK multicast membership, reproduced with both 7-CURRENT and 6.2-RELEASE. if_findmulti() appears to be doing a possibly incorrect comparison. sa_equal() is not valid for use with AF_LINK in some cases, as sockaddr_dl has deeper structure than a simple array of bytes. Thanks for finding this bug -- it would have affected XORP's IS-IS implementation further on in time. Further testing would be appreciated. If the fix is good I will merge, though it should perhaps be a more general fix for sa_equal(). BMS --------------000101000609080301020806 Content-Type: text/x-patch; name="ethermcast.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ethermcast.diff" Index: src/sys/net/if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.265 diff -u -p -r1.265 if.c --- src/sys/net/if.c 30 Nov 2006 15:02:01 -0000 1.265 +++ src/sys/net/if.c 21 Feb 2007 00:34:12 -0000 @@ -2123,8 +2123,16 @@ if_findmulti(struct ifnet *ifp, struct s IF_ADDR_LOCK_ASSERT(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - if (sa_equal(ifma->ifma_addr, sa)) - break; + if (sa->sa_family == AF_LINK) { + struct sockaddr_dl *sdl = (struct sockaddr_dl *)sa; + + if (bcmp(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), + LLADDR(sdl), sdl->sdl_alen) == 0) + break; + } else { + if (sa_equal(ifma->ifma_addr, sa)) + break; + } } return ifma; --------------000101000609080301020806-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 07:39:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7100316E01B for ; Wed, 21 Feb 2007 07:39:08 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id F0CC213C4A7 for ; Wed, 21 Feb 2007 07:39:07 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 25557 invoked by uid 0); 21 Feb 2007 10:45:10 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 21 Feb 2007 07:45:10 -0000 Message-ID: <45DBF718.4090104@webmail.sub.ru> Date: Wed, 21 Feb 2007 10:39:04 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 07:39:08 -0000 Hello! Is there anybody here who can say "I'm running mpd with 400 pptp connections, and it works without a flaw"? I mean 400 ACTIVE connections. If yes, I'll ask lots of questions. If no, I'll have to look for other pptp server. Cannot afford CISCO right now. Alex. From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 07:56:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1FFA916AA93; Wed, 21 Feb 2007 07:56:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF8F13C442; Wed, 21 Feb 2007 07:56:22 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id SAA13714; Wed, 21 Feb 2007 18:56:03 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 21 Feb 2007 18:56:02 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <45DB821D.4050508@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: admin , freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 07:56:25 -0000 On Tue, 20 Feb 2007, Julian Elischer wrote: > admin wrote: > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > through (i.e. performs the action) iff there's state recorded for it > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > incoming and the number of current states is trying to cross the limit, > > the SYN packet is implicitly dropped and the search terminates. > > > > This is not to say that I completely understand the things going on when > > the connections start building up (different timeouts?) but the above > > conclusion is based on what simulation has shown. The whole ruleset fits > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > pretty sure I'm not crazy :-) > > One thing to keep in mind is that a 'check-state' rule works by effectively > jumping to the rule that did the 'keep-state' and re-executing it.. > (and incrementing its stats). What if the action of the rule that does the 'keep-state' (here a limit src-addr) is a skipto, rather than an allow / fwd / divert etc rule that would terminate the search? Does 're-executing' here imply anything about whether the skipto's conditional branch is or is not taken? I bought into this because admin said that more connections were being allowed than the limit src-addr clause should allow, and I assumed that the skipto branch was not being taken on over-limit packets, and that the following fwd rule (allowing any type of packets including SYN) was being executed, which would account for what he'd said was happening. admin above asserts that my assumption was wrong, and that in a match beyond the limit number of connections for that src/dest address, the setup packet is 'implicitly dropped and the search terminates', and while I can't find that stated as such in ipfw(8), he may be right. Which still doesn't explain why connections from a particular IP beyond his specified limit are allowed to be established, as originally stated. [shrug] Over to the ipfw gurus. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 08:27:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4693C16A56B for ; Wed, 21 Feb 2007 08:27:04 +0000 (UTC) (envelope-from admin@azuni.net) Received: from mail.azuni.net (ns0.azuni.net [217.25.25.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7A21913C481 for ; Wed, 21 Feb 2007 08:27:02 +0000 (UTC) (envelope-from admin@azuni.net) Received: (qmail 83913 invoked by uid 1004); 21 Feb 2007 08:27:01 -0000 Received: from admin@azuni.net by mail.azuni.net by uid 89 with qmail-scanner-1.20 (clamscan: 0.65. spamassassin: 2.63. Clear:RC:1(217.25.23.4):. Processed in 0.129857 secs); 21 Feb 2007 08:27:01 -0000 Received: from unknown (HELO ?217.25.23.4?) (217.25.23.4) by ns0.azuni.net with AES256-SHA encrypted SMTP; 21 Feb 2007 08:27:01 -0000 Message-ID: <45DC024F.7040604@azuni.net> Date: Wed, 21 Feb 2007 12:26:55 +0400 From: admin Organization: UniNet User-Agent: Debian Thunderbird 1.0.2 (X11/20070113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer , freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 08:27:04 -0000 Ian Smith wrote: > On Tue, 20 Feb 2007, Julian Elischer wrote: > > admin wrote: > > > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > > through (i.e. performs the action) iff there's state recorded for it > > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > > incoming and the number of current states is trying to cross the limit, > > > the SYN packet is implicitly dropped and the search terminates. > > > > > > This is not to say that I completely understand the things going on when > > > the connections start building up (different timeouts?) but the above > > > conclusion is based on what simulation has shown. The whole ruleset fits > > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > > pretty sure I'm not crazy :-) > > > > One thing to keep in mind is that a 'check-state' rule works by effectively > > jumping to the rule that did the 'keep-state' and re-executing it.. > > (and incrementing its stats). > > What if the action of the rule that does the 'keep-state' (here a limit > src-addr) is a skipto, rather than an allow / fwd / divert etc rule that > would terminate the search? Does 're-executing' here imply anything > about whether the skipto's conditional branch is or is not taken? > > I bought into this because admin said that more connections were being > allowed than the limit src-addr clause should allow, and I assumed that > the skipto branch was not being taken on over-limit packets, and that > the following fwd rule (allowing any type of packets including SYN) was > being executed, which would account for what he'd said was happening. > > admin above asserts that my assumption was wrong, and that in a match > beyond the limit number of connections for that src/dest address, the > setup packet is 'implicitly dropped and the search terminates', and > while I can't find that stated as such in ipfw(8), he may be right. > > Which still doesn't explain why connections from a particular IP beyond > his specified limit are allowed to be established, as originally stated. > I've changed "limit src-addr N" to "limit src-addr dst-addr N" - to key the limit on client parties trying to pose some single external IP address under attack (and, admittedly, the transparent proxy down with it :)) Some bit of scripting below allows me to monitor ipfw's dynamic rules usage keyed by src-addr+dst-addr, sorted by rule count (top 10 users): ipfw -d show | sed -n '/^## Dynamic rules /,$p' | tail -n+2 | awk '$5 == "LIMIT" { k=sprintf("%s %s", $7, $10); a[k]++ } END { for (i in a) {printf "%3d %s\n", a[i], i }}' | sort -nr -k1,1 | head Typical output: 32 client1.ip.ad.dr x.x.x.x 30 client1.ip.ad.dr y.y.y.y 20 client1.ip.ad.dr z.z.z.z 14 client2.ip.ad.dr e.f.g.h ... it shows that client1.ip.ad.dr has 32 connections to x.x.x.x, 30 connections to y.y.y.y, etc. And here's the thing: when under "attack", netstat -na | fgrep client1.ip.ad.dr shows a huge number of connections to some single x.x.x.x, port 80 in the ESTABLISHED state - 2, 3 times the value of limit - with full send queue usage (as determined by net.inet.tcp.sendspace) - all opening at a very fast pace!! The ipfw -d script, though, shows that the limit is not yet even crossed! Only when the netstat's connection count gets to 4-5 times the limit does ipfw start to realize something's wrong and drop packets - the usage count shown by the script above is then strictly that of "limit src-addr N"! It _must_ some different timeouts, I don't know _which_ timeouts though. True, some buggy web-browsers of many "good" clients leave the connection in the FIN_WAIT_2 state until timed out - and this still counts as open (eats up a socket etc.) - that's why I was forced to change "limit src-addr N" to "limit src-addr dst-addr N" to better get the idea. > [shrug] Over to the ipfw gurus. > Ditto. > Cheers, Ian > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 09:02:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF72D16A4FD for ; Wed, 21 Feb 2007 09:02:15 +0000 (UTC) (envelope-from mendonan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 4863913C441 for ; Wed, 21 Feb 2007 09:02:15 +0000 (UTC) (envelope-from mendonan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so880031ugh for ; Wed, 21 Feb 2007 01:02:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FXQT2oIgYgKLOQrUqDAUobx0Il+lTzk2gyBb13/HNUnqRN4nBDKBOJE3dbGZKciRIktWgFGppID1+7BQUylDERMxhsuXU2a4DpK+dnsjU7c4epEZ2iNTq6dIWodLbE9ouWZL74mN7G/5IwDSsko6nrM5UXwM/pE26yScpT7RcMs= Received: by 10.78.171.13 with SMTP id t13mr40209hue.1172046799530; Wed, 21 Feb 2007 00:33:19 -0800 (PST) Received: by 10.78.202.7 with HTTP; Wed, 21 Feb 2007 00:33:19 -0800 (PST) Message-ID: <94c7120b0702210033s9beb479y129ba88b9fc67aa2@mail.gmail.com> Date: Wed, 21 Feb 2007 16:33:19 +0800 From: "Senandung Mendonan" To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94c7120b0608181236j2475301ds1379510f94b12d34@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> <94c7120b0610112005g62c0a137j97a3adf0d97c2ba5@mail.gmail.com> <94c7120b0611061011v6ff0dcbfh34778d4760a619cf@mail.gmail.com> Subject: Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 09:02:15 -0000 Hi list, A late followup on this issue. Due to physical location constraints and production environment, I finally have the chance to relook into this issue. I'm planning to perform these actions tomorrow:- 1. Apply Doug's IPMI patches from http://www.ambrisko.com/doug/bge_ipmi.patch (actually the 6.2-specific version at http://www.ambrisko.com/doug/bge_ipmi_6.2.patch ) 2. If situation persists, a "short test on the DEVICE_POLLING facility, and post the kern.polling.lost_polls", as recommended by David in his last message in this thread. However, I'm running out of time -- the customer already demanded a solution last year :) . Therefore, if above fails, I need to donate one of these NICs to anyone out there (preferably the driver developers), who's willing to figure out the necessary kludges or whatever to make it work (FOC or paid for). Anyone interested, please reply to me privately. Thank you! :) p.s. the summary of this issue is available in my blog here:- http://absolute-p.ath.cx/2006/10/05/freebsd-problem-with-ibm-netxtreme-1000-t-gigaethernet-adapter/ On 11/7/06, MQ wrote: > > > 2006/11/6, Senandung Mendonan : > > > > Hi David / list, > > > > Just to drop a note that this situation still persists, even with the > > latest 6.2-BETA3. I have issued a pr. In addition, I'm willing to send > > you (or anyone in the list) the NIC in question for troubleshooting. > > > > Would very much welcome a helping hand.. > > > > Thanks... :) > > > > On 10/12/06, Senandung Mendonan wrote: > > > David / list, > > > > > > Some new developments/leads on this issue:- > > > > > > On 8/21/06, Senandung Mendonan wrote: > > > > > > > > > If you could attach a dump of dmesg that shows the messages from the > > > > > driver that might help too. > > > > > > > > Here's the dmesg for the dual-port version:- > > > > > > > > pci5: on pcib4 > > > > bge0: mem > > > > 0xdcff0000-0xdcffffff irq 48 at device 1.0 on pci5 > > > > miibus0: on bge0 > > > > brgphy0: on miibus0 > > > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > > > 1000baseTX-FDX, auto > > > > bge0: Ethernet address: 00:10:18:11:2a:0d > > > > bge1: mem > > > > 0xdcfe0000-0xdcfeffff irq 49 at device 1.1 on pci5 > > > > miibus1: on bge1 > > > > brgphy1: on miibus1 > > > > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > > > > 1000baseTX-FDX, auto > > > > bge1: Ethernet address: 00:10:18:11:2a:0a > > > > > > > > > > > > > > After deploying on a few servers, we realized some of the servers work > > > OK, and some not, although the cards are apparently same model, with > > > same dmesg shown above. > > > > > > Upon closer inspection, we found out that the two NICs' chipsets > > > differ in minor revision:- > > > > > > 1. The working NIC:- > > > > > > Broadcom BCM5704CKRB TS0341 P13 706741 B (manufactured 23/12/2004, > > > older revision of the same BCM5704C chipset supported by the FreeBSD > > > bge driver. > > > > > > ( Picture: > http://absolute-p.ath.cx/wp-content/uploads/2006/10/old-23-12-2004.jpg > > > ) > > > > > > 2. The intermittent NIC:- > > > > > > Broadcom BCM5704CKRB CS0424 P20 723153B B (unknown manufacture date, > > > but probably newer than the working NIC). > > > > > > ( Picture: > http://absolute-p.ath.cx/wp-content/uploads/2006/10/new.jpg > ) > > > > > > I have yet to try a 6.2 kernel, the site has no internet connections > > > and a bit far, so takes a while for me to try that. In the meantime, > > > perhaps with the chipset details you have some ideas? > > > > > > Thanks. > > > > > > --mendonan > > > "Yang mimpikan secangkir kopi panas dengan selimut.." > > > (Dreaming of a cup of hot coffee, and a blanket..") > > > > > > > > > -- > > --mendonan > > "Yang mimpikan secangkir kopi panas dengan selimut.." > > (Dreaming of a cup of hot coffee, and a blanket..") > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to " > freebsd-net-unsubscribe@freebsd.org" > > > > > Would you please have a short test on the DEVICE_POLLING facility, and post > the kern.polling.lost_polls after booting for a while here? > -- --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..") From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 09:22:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C886C16DF16 for ; Wed, 21 Feb 2007 09:22:16 +0000 (UTC) (envelope-from falcon@tcm.by) Received: from mail.tcm.by (mail.tcm.by [84.201.224.251]) by mx1.freebsd.org (Postfix) with ESMTP id 4316513C461 for ; Wed, 21 Feb 2007 09:22:16 +0000 (UTC) (envelope-from falcon@tcm.by) Received: from skipped_antispam (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E7F66FFB2 for ; Wed, 21 Feb 2007 10:56:55 +0200 (EET) Received: from skipped_antivirus (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 04AEDFFA7 for ; Wed, 21 Feb 2007 10:56:55 +0200 (EET) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B02EFFFA for ; Wed, 21 Feb 2007 10:56:53 +0200 (EET) Received: from falcon (unknown [192.168.1.200]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcm.by (Postfix) with ESMTP id A5E0DFFEE; Wed, 21 Feb 2007 10:56:52 +0200 (EET) Date: Wed, 21 Feb 2007 10:56:50 +0200 From: "Denis V. Klimkov" X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1817063378.20070221105650@tcm.by> To: Alex Povolotsky In-Reply-To: <45DB2342.5000301@webmail.sub.ru> References: <45D9BADB.6010405@webmail.sub.ru> <45DA8B83.3020202@yandex.ru> <45DB2342.5000301@webmail.sub.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re[2]: mpd sometimes hangs the whole system? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 09:22:16 -0000 Hello Alex, Tuesday, February 20, 2007, 6:35:14 PM, you wrote: AP> RELATIVELY easy. It happens about once a day or more often; but it AP> requires someone to press Reset. I had the same problem with mpd4.0b3 and mpd4.0b4 and Freebsd built from RELENG_6 branch at the beggining of the year. I used it with em cards. No solution found. Tried both SMP and UP kernels with the same result. Now running mpd3.18 under Freebsd 5.5 with no problems. I can add just my 5 cents: when the system locked I could access it via ssh from the remote computer linked to this system via PPTP. And I saw 100% of CPU used by interrupts from em0. Got no access from local console, no ssh from LAN, only can do something very slowly from PPTP connected host. Cannot investigate more because it was production server. Maybe I'll try later using the last release of mpd. -- Denis V. Klimkov Network Administrator TelecomMedia LLC http://www.tcm.by From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 11:40:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE19416EB12 for ; Wed, 21 Feb 2007 11:40:51 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7661A13C46B for ; Wed, 21 Feb 2007 11:40:51 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21048979; Wed, 21 Feb 2007 13:40:50 +0200 Message-ID: <45DC2FC1.3030408@alkar.net> Date: Wed, 21 Feb 2007 13:40:49 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Alex Povolotsky References: <1172056982.00691952.1172043601@10.7.7.3> In-Reply-To: <1172056982.00691952.1172043601@10.7.7.3> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 11:40:52 -0000 Alex Povolotsky wrote: > Is there anybody here who can say "I'm running mpd with 400 pptp > connections, and it works without a flaw"? I am running >100 mpd servers, and they work without a flaw. > I mean 400 ACTIVE connections. And I have >10k PPPoE users and some amount of PPTP. I have >700 ACTIVE PPPoE on some servers. > If yes, I'll ask lots of questions. If no, I'll have to look for other > pptp server. Cannot afford CISCO right now. Have you tried latest mpd4.1? Do you know anything better? -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 12:12:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A601216EAF3 for ; Wed, 21 Feb 2007 12:12:34 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id D2ECB13C441 for ; Wed, 21 Feb 2007 12:12:33 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 41477 invoked by uid 0); 21 Feb 2007 15:18:36 +0300 Received: from unknown (HELO localhost) (88.212.205.2) by techno.sub.ru with SMTP; 21 Feb 2007 12:18:36 -0000 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id q8ooxBEwdLIl; Wed, 21 Feb 2007 15:18:23 +0300 (MSK) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@213.247.139.99) by techno.sub.ru with SMTP; 21 Feb 2007 12:18:22 -0000 Message-ID: <45DC3718.7010804@webmail.sub.ru> Date: Wed, 21 Feb 2007 15:12:08 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> In-Reply-To: <45DC2FC1.3030408@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 12:12:34 -0000 Alexander Motin wrote: > Alex Povolotsky wrote: >> Is there anybody here who can say "I'm running mpd with 400 pptp >> connections, and it works without a flaw"? > > I am running >100 mpd servers, and they work without a flaw. > >> I mean 400 ACTIVE connections. > > And I have >10k PPPoE users and some amount of PPTP. I have >700 > ACTIVE PPPoE on some servers. > Hmm... May I ask you to show your dmesg, kernel config and mpd configs? I have heard several rumors about system lockup with mpd. >> If yes, I'll ask lots of questions. If no, I'll have to look for >> other pptp server. Cannot afford CISCO right now. > > Have you tried latest mpd4.1? Do you know anything better? > Not _yet_. I do not know anything better, but I cannot make mpd on 100+ active connections to work. And I'm not the only dumb one, as far as I've found Alex. From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 12:23:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA33F16AABE for ; Wed, 21 Feb 2007 12:23:26 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 51BB713C47E for ; Wed, 21 Feb 2007 12:23:26 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21050604; Wed, 21 Feb 2007 14:23:25 +0200 Message-ID: <45DC39BC.5020707@alkar.net> Date: Wed, 21 Feb 2007 14:23:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Alex Povolotsky References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> In-Reply-To: <45DC3718.7010804@webmail.sub.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 12:23:26 -0000 Alex Povolotsky wrote: > Hmm... May I ask you to show your dmesg, kernel config and mpd configs? > I have heard several rumors about system lockup with mpd. I have heard only one and that person answered me that problem was solved by avoiding of routing loop, when tunnel traffic was routed inside the same tunnel. I have written this in my answer to 'mpd sometimes hangs the whole system' thread. Have you red it? > Hmm... May I ask you to show your dmesg, kernel config and mpd configs? Nothing special. Latest 6-STABLE, latest mpd4.1, latest libpdel port. Two em Ethernets, single P4/i386 CPU at Intel mobo. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 13:10:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD97216CBEC for ; Wed, 21 Feb 2007 13:10:18 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id D9D6C13C478 for ; Wed, 21 Feb 2007 13:10:17 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 74390 invoked by uid 0); 21 Feb 2007 16:16:19 +0300 Received: from unknown (HELO localhost) (88.212.205.2) by techno.sub.ru with SMTP; 21 Feb 2007 13:16:19 -0000 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id a5o2vifIsSYd; Wed, 21 Feb 2007 16:16:14 +0300 (MSK) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@213.247.139.99) by techno.sub.ru with SMTP; 21 Feb 2007 13:16:14 -0000 Message-ID: <45DC44AF.30005@webmail.sub.ru> Date: Wed, 21 Feb 2007 16:10:07 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> In-Reply-To: <45DC39BC.5020707@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 13:10:18 -0000 Alexander Motin wrote: > Alex Povolotsky wrote: >> Hmm... May I ask you to show your dmesg, kernel config and mpd >> configs? I have heard several rumors about system lockup with mpd. > > I have heard only one and that person answered me that problem was > solved by avoiding of routing loop, when tunnel traffic was routed > inside the same tunnel. I have written this in my answer to 'mpd > sometimes hangs the whole system' thread. Have you red it? > yes; and it's 100% not my case. > > Hmm... May I ask you to show your dmesg, kernel config and mpd > configs? > > Nothing special. Latest 6-STABLE, latest mpd4.1, latest libpdel port. > Two em Ethernets, single P4/i386 CPU at Intel mobo. > Hmm. Will check mpd4.1, and try to use em to listen on... And, again, please show me your mpd.conf Alex. From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 13:16:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEFAB16F208 for ; Wed, 21 Feb 2007 13:16:50 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5224C13C4A5 for ; Wed, 21 Feb 2007 13:16:50 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21051999; Wed, 21 Feb 2007 15:16:49 +0200 Message-ID: <45DC4640.8030309@alkar.net> Date: Wed, 21 Feb 2007 15:16:48 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Alex Povolotsky References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> In-Reply-To: <45DC44AF.30005@webmail.sub.ru> Content-Type: multipart/mixed; boundary="------------040804090901040904090307" Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 13:16:50 -0000 This is a multi-part message in MIME format. --------------040804090901040904090307 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Alex Povolotsky wrote: > And, again, please show me your mpd.conf Attached. -- Alexander Motin mav@alkar.net Optima Telecom --------------040804090901040904090307 Content-Type: text/plain; name="mpd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mpd.conf" default: log -bund -fsm -lcp set console ip 127.0.0.1 set console user xxx yyy set console open set netflow node netflow set netflow hook 200 new -N b0 l0 load server_default new -N b1 l1 load server_default new -N b2 l2 load server_default .... new -N b897 l897 load server_default new -N b898 l898 load server_default new -N b899 l899 load server_default server_default: set bundle no multilink set bundle yes noretry set iface enable tcpmssfix set ipcp ranges lo0 127.0.0.2/32 set ipcp dns 195.248.191.67 195.248.191.72 set ipcp no vjcomp set link mtu 1492 set link mru 1492 set link accmap 0x00000000 set link keep-alive 30 100 set link max-redial -1 set link deny pap set link enable pap set link no chap set link no eap set link no acfcomp set link no protocomp set auth disable internal set auth enable radius-auth set auth enable radius-acct set radius server x.x.x.x yyy 1645 1646 set radius timeout 7 set radius retries 5 set radius me vlan110 --------------040804090901040904090307-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 14:50:29 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F097716F7D9 for ; Wed, 21 Feb 2007 14:50:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id CA78513C49D for ; Wed, 21 Feb 2007 14:50:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id BCCFF1BF315 for ; Wed, 21 Feb 2007 09:51:43 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 21 Feb 2007 09:51:43 -0500 X-Sasl-enc: aRNeuZQtZ23MH6NcvAbIlHbi4g7o98bn9BDO+b4n2LsT 1172069503 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 572A0293E4 for ; Wed, 21 Feb 2007 09:51:43 -0500 (EST) Message-ID: <45DC5C33.8020806@incunabulum.net> Date: Wed, 21 Feb 2007 14:50:27 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: NetworkRfcCompliance is born X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 14:50:30 -0000 http://wiki.freebsd.org/NetworkRfcCompliance Please begin wiki-whacking! BMS From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 14:54:45 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 354D316D15E for ; Wed, 21 Feb 2007 14:54:45 +0000 (UTC) (envelope-from satimis@yahoo.com) Received: from web35206.mail.mud.yahoo.com (web35206.mail.mud.yahoo.com [66.163.179.85]) by mx1.freebsd.org (Postfix) with SMTP id EAB5A13C478 for ; Wed, 21 Feb 2007 14:54:44 +0000 (UTC) (envelope-from satimis@yahoo.com) Received: (qmail 51043 invoked by uid 60001); 21 Feb 2007 14:54:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=J6XuYdIJaqyhwBNE5GfZQyu9FT8E9L1nqOhk/flfKj3e7lyKCS543ytFcFSQigrgv4k2bJuJfPJasfw4tGjH6jA78ggmDCajLbvJ3rW7GbV1Yo8qEqN3Sta9cc144mzKpz7CaubaCI5QYqzegeIlVZmscKQob8fI3jNjgHKxIj4=; X-YMail-OSG: QR3OpbwVM1ndsVwSXfvuqf2dy5pzpMBZ9gfGtka2q6L16lzMK8P6LCiBrQsXHnqNF9hNJ15aExGa01JIR7qV6u.tkDw8WpXREJPYLp28MJz1R2QXsSI.qZCD5gXCvNZQXCMVC5JqfVHJ_aw- Received: from [220.232.213.178] by web35206.mail.mud.yahoo.com via HTTP; Wed, 21 Feb 2007 22:54:44 CST Date: Wed, 21 Feb 2007 22:54:44 +0800 (CST) From: Stephen Liu To: "Bruce M. Simpson" In-Reply-To: <45DAFBCA.8030904@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <379864.40944.qm@web35206.mail.mud.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: Unable to connect broadband X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 14:54:45 -0000 --- "Bruce M. Simpson" wrote: > satimis wrote: > > Hi folks, > > > > FreeBSD-6.2-amd64 > > ... > > The onboard NIC seems not detected. > > > In the absence of required information, I speculate your machine has > msk(4) or another recent chipset which may be supported in > FreeBSD-CURRENT but not FreeBSD-STABLE. > > Please post the full output of 'pciconf -lv' from booting a recent > FreeSBIE version to the list and hopefully someone can offer more > help. Hi Bruce, I get a floppy drive temporarily connected to the FreeBSD-6.2-amd64 box and have the output file of "pciconf -lv" copied to a floppy. # mount /dev/fd0 /mnt # cat /mnt/pciconf.txt none0@pci0:0:0: class=0x050000 card=0x82391043 chip=0x036910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x82391043 chip=0x036010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-ISA none1@pci0:1:1: class=0x0c0500 card=0x82391043 chip=0x036810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = SMBus none2@pci0:1:2: class=0x050000 card=0x82391043 chip=0x036a10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM ohci0@pci0:2:0: class=0x0c0310 card=0x82391043 chip=0x036c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB ehci0@pci0:2:1: class=0x0c0320 card=0x82391043 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB atapci0@pci0:4:0: class=0x01018a card=0x82391043 chip=0x036e10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA atapci1@pci0:5:0: class=0x010185 card=0x82391043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA atapci2@pci0:5:1: class=0x010185 card=0x82391043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA atapci3@pci0:5:2: class=0x010185 card=0x82391043 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA pcib1@pci0:6:0: class=0x060401 card=0x000000b8 chip=0x037010de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI none3@pci0:6:1: class=0x040300 card=0x81f61043 chip=0x037110de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = multimedia none4@pci0:8:0: class=0x068000 card=0x82391043 chip=0x037310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge pcib2@pci0:10:0: class=0x060400 card=0x00000040 chip=0x037610de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:11:0: class=0x060400 card=0x00000040 chip=0x037410de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:12:0: class=0x060400 card=0x00000040 chip=0x037410de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:13:0: class=0x060400 card=0x00000040 chip=0x037810de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:14:0: class=0x060400 card=0x00000040 chip=0x037510de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib7@pci0:15:0: class=0x060400 card=0x00000040 chip=0x037710de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI hostb0@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI none5@pci7:0:0: class=0x030000 card=0x81f31043 chip=0x01df10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = display subclass = VGA Advice would be appreciated. TIA B.R. Stephen Send instant messages to your online friends http://uk.messenger.yahoo.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 15:12:15 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81E1C16E774 for ; Wed, 21 Feb 2007 15:12:15 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 56E8F13C4A6 for ; Wed, 21 Feb 2007 15:12:15 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l1LFCFfQ089214; Wed, 21 Feb 2007 07:12:15 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l1LFCF16089213; Wed, 21 Feb 2007 07:12:15 -0800 (PST) (envelope-from rizzo) Date: Wed, 21 Feb 2007 07:12:14 -0800 From: Luigi Rizzo To: Bruce M Simpson Message-ID: <20070221071214.B88996@xorpc.icir.org> References: <45DC5C33.8020806@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45DC5C33.8020806@incunabulum.net>; from bms@incunabulum.net on Wed, Feb 21, 2007 at 02:50:27PM +0000 Cc: net@freebsd.org Subject: Re: NetworkRfcCompliance is born X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 15:12:15 -0000 On Wed, Feb 21, 2007 at 02:50:27PM +0000, Bruce M Simpson wrote: > http://wiki.freebsd.org/NetworkRfcCompliance before it is too late to change, maybe it is the case to spell RFC as all capital letters ? As it is now, i misread it as NetworkRfCompliance and thought it was something related to radio/wireless stuff... cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 15:15:08 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF14416DF98 for ; Wed, 21 Feb 2007 15:15:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id A803A13C478 for ; Wed, 21 Feb 2007 15:15:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 83BA51BF939; Wed, 21 Feb 2007 10:15:40 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 21 Feb 2007 10:15:40 -0500 X-Sasl-enc: uOA30/E/vVjnp64Qh3Lj9N2T1XLM8XLShy2do4Zhr7k9 1172070940 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id DBA6E135F3; Wed, 21 Feb 2007 10:15:39 -0500 (EST) Message-ID: <45DC61CF.6000206@incunabulum.net> Date: Wed, 21 Feb 2007 15:14:23 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Luigi Rizzo References: <45DC5C33.8020806@incunabulum.net> <20070221071214.B88996@xorpc.icir.org> In-Reply-To: <20070221071214.B88996@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: NetworkRfcCompliance is born X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 15:15:08 -0000 Luigi Rizzo wrote: > On Wed, Feb 21, 2007 at 02:50:27PM +0000, Bruce M Simpson wrote: > >> http://wiki.freebsd.org/NetworkRfcCompliance >> > > before it is too late to change, maybe it is the case to > spell RFC as all capital letters ? > It would surely be better named NetworkStandardsCompliance as IEEE stuff appears inevitably also. I am pressed for time at the moment, so, other volunteers very welcome to do so... BMS From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 17:20:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 804C317005B for ; Wed, 21 Feb 2007 17:20:05 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 43A7013C4A5 for ; Wed, 21 Feb 2007 17:20:05 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2603650nzh for ; Wed, 21 Feb 2007 09:20:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=atYESYwvZKfjV+iAGtXf08sx0AevqHhivnIa85s0WaKVkUn3hdNvCudikzC6YuW5ezknZWMNULM1HOviRNUTPlvUFaGaUt87D7CbREbIxRZubkc5gl18HTpWDnNOzszX70um042AVwYwkLq7mJTXhzNKBvcPEmzBvcCFLej3akU= Received: by 10.65.232.19 with SMTP id j19mr14303341qbr.1172076947077; Wed, 21 Feb 2007 08:55:47 -0800 (PST) Received: from ?192.168.0.199? ( [70.81.172.47]) by mx.google.com with ESMTP id e14sm5700249qba.2007.02.21.08.55.46; Wed, 21 Feb 2007 08:55:46 -0800 (PST) Message-ID: <45DC7991.8070103@gmail.com> Date: Wed, 21 Feb 2007 11:55:45 -0500 From: Martin Turgeon User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-bugs@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Strange /etc/rc.d/netif behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 17:20:05 -0000 Hi, I'm not sure if this is really a bug but it doesn't look all fine to me. When I do a /etc/rc.d/netif restart it does restart the network interfaces but doesn't replace the default route that it just erased even if it is specified in rc.conf correctly. I found that I should also restart routed but it looks strange to me. I know that the /etc/netstart script did it all but it's written in it that it's obsolete so I don't want to use it. So, is this normal and if so what is the best way to restart both a the same time. Thanks Martin From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 19:17:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 310C817072D for ; Wed, 21 Feb 2007 19:17:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 10E9713C4A6 for ; Wed, 21 Feb 2007 19:17:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 21 Feb 2007 10:52:43 -0800 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id BBA27125B5D; Wed, 21 Feb 2007 11:17:01 -0800 (PST) Message-ID: <45DC9AAC.8090301@elischer.org> Date: Wed, 21 Feb 2007 11:17:00 -0800 From: Julian Elischer User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: admin , freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 19:17:03 -0000 Ian Smith wrote: > On Tue, 20 Feb 2007, Julian Elischer wrote: > > admin wrote: > > > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > > through (i.e. performs the action) iff there's state recorded for it > > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > > incoming and the number of current states is trying to cross the limit, > > > the SYN packet is implicitly dropped and the search terminates. > > > > > > This is not to say that I completely understand the things going on when > > > the connections start building up (different timeouts?) but the above > > > conclusion is based on what simulation has shown. The whole ruleset fits > > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > > pretty sure I'm not crazy :-) > > > > One thing to keep in mind is that a 'check-state' rule works by effectively > > jumping to the rule that did the 'keep-state' and re-executing it.. > > (and incrementing its stats). > > What if the action of the rule that does the 'keep-state' (here a limit > src-addr) is a skipto, rather than an allow / fwd / divert etc rule that > would terminate the search? Does 're-executing' here imply anything > about whether the skipto's conditional branch is or is not taken? if the keep-state rule is a skipto then the check-state will skip to.. I use that in some rules. here's a snippet that I have when acting as a filtering transparent bridge, with DNS replies (from the outside) being diverted to a snooper. The bridge is between em2 (inside) and em3 (outside). 01200 17588453 1257728932 skipto 1210 udp from any to any dst-port 53 recv em2 01201 16192860 2721432229 skipto 1220 udp from any 53 to any recv em3 01202 43658738 21537916245 skipto 1250 ip from any to any 01210 34023270 3994649771 skipto 1240 ip from any to any keep-state 01220 0 0 check-state 01229 2364 441701 deny ip from any to any 01240 16190496 2720990528 divert 5001 udp from any 53 to any recv em3 01242 17832774 1273659243 deny ip from any to any (note this requires patches to allow divert from a bridge.) It's convoluted I know but it only (well, mostly) diverts packets from the outside that are part of a conversation that was started already (probably by a dns request from inside) DNS packets from the outside that are not a response to something we already asked for are discarded (a DOS protection) note that all the packets that went to the check-state, (1220) ended up going back to 1210 where they did the skipto 1240 and were filtered again. > > I bought into this because admin said that more connections were being > allowed than the limit src-addr clause should allow, and I assumed that > the skipto branch was not being taken on over-limit packets, and that > the following fwd rule (allowing any type of packets including SYN) was > being executed, which would account for what he'd said was happening. > > admin above asserts that my assumption was wrong, and that in a match > beyond the limit number of connections for that src/dest address, the > setup packet is 'implicitly dropped and the search terminates', and > while I can't find that stated as such in ipfw(8), he may be right. > > Which still doesn't explain why connections from a particular IP beyond > his specified limit are allowed to be established, as originally stated. > > [shrug] Over to the ipfw gurus. > > Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 20:36:29 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DA4416A412; Wed, 21 Feb 2007 20:36:29 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id DD0BA13C4BA; Wed, 21 Feb 2007 20:36:28 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l1LKaSnu082231; Wed, 21 Feb 2007 20:36:28 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l1LKaSq2082227; Wed, 21 Feb 2007 20:36:28 GMT (envelope-from remko) Date: Wed, 21 Feb 2007 20:36:28 GMT From: Remko Lodder Message-Id: <200702212036.l1LKaSq2082227@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/109406: Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 20:36:29 -0000 Synopsis: Broadcom WLAN driver 4.100.15.5 doesn't work with Ndisgen Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Feb 21 20:36:28 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=109406 From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 20:47:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCEF616A401; Wed, 21 Feb 2007 20:47:28 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id DEA4113C461; Wed, 21 Feb 2007 20:47:27 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (25qape8rw2utfuqy@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l1LKW7Ns071370; Wed, 21 Feb 2007 12:32:07 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l1LKW7nx071369; Wed, 21 Feb 2007 12:32:07 -0800 (PST) (envelope-from jmg) Date: Wed, 21 Feb 2007 12:32:07 -0800 From: John-Mark Gurney To: Martin Turgeon Message-ID: <20070221203207.GF73385@funkthat.com> Mail-Followup-To: Martin Turgeon , freebsd-bugs@freebsd.org, freebsd-net@freebsd.org References: <45DC7991.8070103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45DC7991.8070103@gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Strange /etc/rc.d/netif behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 20:47:28 -0000 Martin Turgeon wrote this message on Wed, Feb 21, 2007 at 11:55 -0500: > I'm not sure if this is really a bug but it doesn't look all fine to me. > When I do a /etc/rc.d/netif restart it does restart the network > interfaces but doesn't replace the default route that it just erased > even if it is specified in rc.conf correctly. I found that I should also > restart routed but it looks strange to me. I know that the /etc/netstart > script did it all but it's written in it that it's obsolete so I don't > want to use it. > > So, is this normal and if so what is the best way to restart both a the > same time. Why don't you restart /etc/rc.d/routing too? That will repopulate the default route(s) for you.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 20:56:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCBDF16A401 for ; Wed, 21 Feb 2007 20:56:32 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 9094913C428 for ; Wed, 21 Feb 2007 20:56:32 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2654884nzh for ; Wed, 21 Feb 2007 12:56:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AIEZffpsak2r1TPjzEhX497FLv7sCN6AFyzC2aEjIharHfGT/hL/W+dEAoH6eeCRzwtEIOhiGPl5cBbIu0z6Hk0+MUdgA6CbAODGoAWkp/0wRqlt5Be0/S+DSIE/itoVXUq0Bz/tgYww1pdhYoyAbMd/TDfiDMmOms01fd6Astg= Received: by 10.65.192.16 with SMTP id u16mr14791619qbp.1172091391828; Wed, 21 Feb 2007 12:56:31 -0800 (PST) Received: from ?192.168.0.199? ( [70.81.172.47]) by mx.google.com with ESMTP id q13sm5896272qbq.2007.02.21.12.56.31; Wed, 21 Feb 2007 12:56:31 -0800 (PST) Message-ID: <45DCB1F9.3020009@gmail.com> Date: Wed, 21 Feb 2007 15:56:25 -0500 From: Martin Turgeon User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kevin Downey References: <45DC7991.8070103@gmail.com> <1d3ed48c0702211233y1e0dc2bfydb1dc0c50ccaf7cc@mail.gmail.com> In-Reply-To: <1d3ed48c0702211233y1e0dc2bfydb1dc0c50ccaf7cc@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Strange /etc/rc.d/netif behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 20:56:32 -0000 Kevin Downey a écrit : > On 2/21/07, Martin Turgeon wrote: >> Hi, >> >> I'm not sure if this is really a bug but it doesn't look all fine to me. >> When I do a /etc/rc.d/netif restart it does restart the network >> interfaces but doesn't replace the default route that it just erased >> even if it is specified in rc.conf correctly. I found that I should also >> restart routed but it looks strange to me. I know that the /etc/netstart >> script did it all but it's written in it that it's obsolete so I don't >> want to use it. >> >> So, is this normal and if so what is the best way to restart both a the >> same time. >> >> Thanks >> >> Martin >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > /etc/rc.d/routing ? Exactly, sorry for the lack of details... From owner-freebsd-net@FreeBSD.ORG Wed Feb 21 21:02:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A738516A402 for ; Wed, 21 Feb 2007 21:02:19 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6884A13C461 for ; Wed, 21 Feb 2007 21:02:19 +0000 (UTC) (envelope-from turgeon.martin@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so2656396nzh for ; Wed, 21 Feb 2007 13:02:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Bvucbo0Ewq/4bzysqYDVi/FQwM89G6wL/xcDWRN3gwKzN2eoodp+s22SGZ67eyehFRUfvxDy92eh//U7iZY1Bih+ADqJLCLFXRqWsPjX1ZkNckenp+5keZHz9XzFTi3zYCJ83A6dGvNrd8dLz6Z8UJXZ2xTcdBInJqQaYwKmd0k= Received: by 10.65.233.18 with SMTP id k18mr14779392qbr.1172091738761; Wed, 21 Feb 2007 13:02:18 -0800 (PST) Received: from ?192.168.0.199? ( [70.81.172.47]) by mx.google.com with ESMTP id f18sm5839567qba.2007.02.21.13.02.18; Wed, 21 Feb 2007 13:02:18 -0800 (PST) Message-ID: <45DCB354.9000809@gmail.com> Date: Wed, 21 Feb 2007 16:02:12 -0500 From: Martin Turgeon User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Martin Turgeon , freebsd-bugs@freebsd.org, freebsd-net@freebsd.org References: <45DC7991.8070103@gmail.com> <20070221203207.GF73385@funkthat.com> In-Reply-To: <20070221203207.GF73385@funkthat.com> Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Strange /etc/rc.d/netif behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2007 21:02:19 -0000 John-Mark Gurney a écrit : Martin Turgeon wrote this message on Wed, Feb 21, 2007 at 11:55 -0500: I'm not sure if this is really a bug but it doesn't look all fine to me. When I do a /etc/rc.d/netif restart it does restart the network interfaces but doesn't replace the default route that it just erased even if it is specified in rc.conf correctly. I found that I should also restart routed but it looks strange to me. I know that the /etc/netstart script did it all but it's written in it that it's obsolete so I don't want to use it. So, is this normal and if so what is the best way to restart both a the same time. Why don't you restart /etc/rc.d/routing too? That will repopulate the default route(s) for you.. That is exactly what I did but I would like to know if it is the expected behaviour and what is the best way to automate this. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 09:13:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8AE316A400 for ; Thu, 22 Feb 2007 09:13:22 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 1CA5813C471 for ; Thu, 22 Feb 2007 09:13:21 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 39847 invoked by uid 0); 22 Feb 2007 12:19:26 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 22 Feb 2007 09:19:26 -0000 Message-ID: <45DD5EAE.9030001@webmail.sub.ru> Date: Thu, 22 Feb 2007 12:13:18 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> <45DC4640.8030309@alkar.net> In-Reply-To: <45DC4640.8030309@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 09:13:23 -0000 Alexander Motin wrote: > Alex Povolotsky wrote: >> And, again, please show me your mpd.conf > > Attached. > Thanks a lot; watchdog is armed, WITNESS and INVARIANTS on, running... Alex. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 14:41:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0736C16A401 for ; Thu, 22 Feb 2007 14:41:59 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 881B113C48D for ; Thu, 22 Feb 2007 14:41:58 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-235-229.51-151.net24.it [151.51.229.235]) (authenticated bits=128) by parrot.aev.net (8.13.8/8.13.8) with ESMTP id l1MEmeP7089002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Feb 2007 15:48:46 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l1MEgkWF035371 for ; Thu, 22 Feb 2007 15:42:46 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45DDABA6.60407@netfence.it> Date: Thu, 22 Feb 2007 15:41:42 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 212.31.247.179 Subject: Bridge and NAT problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 14:41:59 -0000 Hello. I've got the following problem... My host is configured like this: fxp0: internal interface, requires NAT rl1: public interface, with static IP xl0: bridged to rl1, with some public IP behind ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw 50 divert 8668 ip from any to any via rl1 Internal <-> Internet works, as Internet <-> Bridged does. Internal <-> Bridged does not work. Let's suppose I'm pinging from the inside to a bridged machine: the ICMP packet comes in through fxp0 and is allowed, gets NATted going out by rule 50 and reaches the target hosts (I guess bridging is also happening to send it out via xl0 instead of rl1). The target answers to the public IP of this box and the packet comes in via xl0, so it's not back-NATted and gets lost. I then tought of diverting to natd every packet through xl0 (i.e. 60 divert 8668 ip from any to any via xl0), but this doesn't work either. The packet gets to natd by means of rule 60, but natd does not recognize it as an answer to a previously examined packet. From man pages I understood that natd does not take interface into account, but only source and destination IP:port. Then, what's wrong? Any suggestion? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 15:50:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF4E016A401 for ; Thu, 22 Feb 2007 15:50:21 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 093DB13C491 for ; Thu, 22 Feb 2007 15:50:20 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 33001 invoked by uid 0); 22 Feb 2007 18:56:25 +0300 Received: from unknown (HELO localhost) (88.212.205.2) by techno.sub.ru with SMTP; 22 Feb 2007 15:56:25 -0000 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id jsrjUXz4jgUH; Thu, 22 Feb 2007 18:56:19 +0300 (MSK) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@213.247.139.99) by techno.sub.ru with SMTP; 22 Feb 2007 15:56:19 -0000 Message-ID: <45DDBBB3.3020900@webmail.sub.ru> Date: Thu, 22 Feb 2007 18:50:11 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> <45DC4640.8030309@alkar.net> In-Reply-To: <45DC4640.8030309@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 15:50:21 -0000 Alexander Motin wrote: > Alex Povolotsky wrote: >> And, again, please show me your mpd.conf > > Attached. Thanks, it seems to be more or less stable; however, throughput is quite little, lots of packets lost and "No buffer space available" on attempt to ping VPN addresses (only VPN is affected). I guess I should tune some kernel tunable, but what specific one? Alex. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 16:11:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CDF916A401 for ; Thu, 22 Feb 2007 16:11:32 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC5C13C4A7 for ; Thu, 22 Feb 2007 16:11:31 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21089294; Thu, 22 Feb 2007 18:10:58 +0200 Message-ID: <45DDC091.3060903@alkar.net> Date: Thu, 22 Feb 2007 18:10:57 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Alex Povolotsky References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> <45DC4640.8030309@alkar.net> <45DDBBB3.3020900@webmail.sub.ru> In-Reply-To: <45DDBBB3.3020900@webmail.sub.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 16:11:32 -0000 Alex Povolotsky wrote: > Thanks, it seems to be more or less stable; however, throughput is quite > little, lots of packets lost and "No buffer space available" on attempt > to ping VPN addresses (only VPN is affected). Have you tried to disable PPTP windowing in mpd config? ENOBUFS is the errno used by ng_pptp node's windowing code when outgoing window is full. It is not related to any system tunables. Maximum window size in current ng_pptp is 16 packets. It can be small for LFNs and can reduce speed. > I guess I should tune some kernel tunable, but what specific one? I can recomend you to set net.graph.maxdgram=524288 net.graph.recvspace=524288 to make 'ngctl list' command work, but it is not critical. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 16:44:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C528416A403 for ; Thu, 22 Feb 2007 16:44:29 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 0ACCD13C442 for ; Thu, 22 Feb 2007 16:44:28 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 52883 invoked by uid 0); 22 Feb 2007 19:50:33 +0300 Received: from unknown (HELO localhost) (88.212.205.2) by techno.sub.ru with SMTP; 22 Feb 2007 16:50:33 -0000 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id 6lV9XLCRpmI4; Thu, 22 Feb 2007 19:50:25 +0300 (MSK) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@213.247.139.99) by techno.sub.ru with SMTP; 22 Feb 2007 16:50:25 -0000 Message-ID: <45DDC852.9060503@webmail.sub.ru> Date: Thu, 22 Feb 2007 19:44:02 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> <45DC4640.8030309@alkar.net> <45DDBBB3.3020900@webmail.sub.ru> <45DDC091.3060903@alkar.net> In-Reply-To: <45DDC091.3060903@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 16:44:29 -0000 Alexander Motin wrote: > Alex Povolotsky wrote: >> Thanks, it seems to be more or less stable; however, throughput is >> quite little, lots of packets lost and "No buffer space available" on >> attempt to ping VPN addresses (only VPN is affected). > > Have you tried to disable PPTP windowing in mpd config? ENOBUFS is the > errno used by ng_pptp node's windowing code when outgoing window is > full. It is not related to any system tunables. Maximum window size in > current ng_pptp is 16 packets. It can be small for LFNs and can reduce > speed. > >> I guess I should tune some kernel tunable, but what specific one? > > I can recomend you to set > net.graph.maxdgram=524288 > net.graph.recvspace=524288 > to make 'ngctl list' command work, but it is not critical. > Whoops! After disabling windowing and setting net.graph's, mpd4 refuses to work Feb 22 19:41:43 gw mpd: can't create socket node: No buffer space available Feb 22 19:41:43 gw mpd: pptp0: killing connection with 172.23.115.234 1735 Feb 22 19:41:44 gw mpd: PPTP connection from 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: pptp0: attached to connection with 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: [pptp7] Accepting PPTP connection Feb 22 19:41:44 gw mpd: [pptp7] opening link "pptp7"... Feb 22 19:41:44 gw mpd: [pptp7] link: OPEN event Feb 22 19:41:44 gw mpd: [pptp7] LCP: Open event Feb 22 19:41:44 gw mpd: [pptp7] LCP: state change Initial --> Starting Feb 22 19:41:44 gw mpd: [pptp7] LCP: LayerStart Feb 22 19:41:44 gw mpd: [pptp7] attaching to peer's outgoing call Feb 22 19:41:44 gw mpd: [pptp7] can't attach pptpgre node: Bad file descriptor Feb 22 19:41:44 gw mpd: pptp0-0: killing channel Feb 22 19:41:44 gw mpd: [pptp7] PPTP call cancelled in state CONNECTING Feb 22 19:41:44 gw mpd: pptp0: closing connection with 172.23.114.214 2955 Feb 22 19:41:44 gw mpd: [pptp7] can't shutdown "bypass.link0": Bad file descript or Feb 22 19:41:44 gw mpd: [pptp7] link: DOWN event Feb 22 19:41:44 gw mpd: [pptp7] LCP: Close event Feb 22 19:41:44 gw mpd: [pptp7] LCP: state change Starting --> Initial Feb 22 19:41:44 gw mpd: [pptp7] LCP: LayerFinish and no ng interfaces ever created lowering both tunables to 128000 solved the problem, will look more. Alex. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 16:50:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F84316A400 for ; Thu, 22 Feb 2007 16:50:25 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 59F8F13C46B for ; Thu, 22 Feb 2007 16:50:25 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.26.75] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1MGoLwc026098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Feb 2007 08:50:25 -0800 Message-ID: <45DDC9CD.1020207@freebsd.org> Date: Thu, 22 Feb 2007 08:50:21 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45DDABA6.60407@netfence.it> In-Reply-To: <45DDABA6.60407@netfence.it> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig833EAB9C2153DA397D505D32" Subject: Re: Bridge and NAT problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 16:50:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig833EAB9C2153DA397D505D32 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Andrea Venturoli wrote: > Hello. > I've got the following problem... > My host is configured like this: >=20 > fxp0: internal interface, requires NAT > rl1: public interface, with static IP > xl0: bridged to rl1, with some public IP behind >=20 > ipfw diverts any traffic through rl1 to natd, i.e. I have in ipfw > 50 divert 8668 ip from any to any via rl1 >=20 >=20 > Internal <-> Internet works, as Internet <-> Bridged does. > Internal <-> Bridged does not work. >=20 > Let's suppose I'm pinging from the inside to a bridged machine: the ICM= P=20 > packet comes in through fxp0 and is allowed, gets NATted going out by=20 > rule 50 and reaches the target hosts (I guess bridging is also happenin= g=20 > to send it out via xl0 instead of rl1). > The target answers to the public IP of this box and the packet comes in= =20 > via xl0, so it's not back-NATted and gets lost. >=20 > I then tought of diverting to natd every packet through xl0 (i.e. 60=20 > divert 8668 ip from any to any via xl0), but this doesn't work either. = > The packet gets to natd by means of rule 60, but natd does not recogniz= e=20 > it as an answer to a previously examined packet. > From man pages I understood that natd does not take interface into=20 > account, but only source and destination IP:port. Then, what's wrong? >=20 > Any suggestion? You didn't say which bridging driver or version of FreeBSD you're using, but it sounds to me like you're using bridge(4), right? This is a fairly well known problem, which I wrote a little bit about here: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html (This message describes a scenario with ipf, but it applies equally well I think to ipfw.) If you can, try switching to using if_bridge(4). You (probably) want to assign the public NAT address to the bridge0 interface, and leave the physical interfaces making up the bridges (xl0 and rl1 in your case) unnumbered. I've had good experiences with this type of configuration. Bruce. --------------enig833EAB9C2153DA397D505D32 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3cnN2MoxcVugUsMRAqRSAJ0Vhuo9W1jVAialwnteIzNFGEszPQCfbBy8 wNml5KF/g9GqOssUNb26JZo= =3aLo -----END PGP SIGNATURE----- --------------enig833EAB9C2153DA397D505D32-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 17:15:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D86716A402 for ; Thu, 22 Feb 2007 17:15:49 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id A696F13C4AA for ; Thu, 22 Feb 2007 17:15:48 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21090870; Thu, 22 Feb 2007 19:15:47 +0200 Message-ID: <45DDCFC1.5030608@alkar.net> Date: Thu, 22 Feb 2007 19:15:45 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Povolotsky References: <1172056982.00691952.1172043601@10.7.7.3> <45DC2FC1.3030408@alkar.net> <45DC3718.7010804@webmail.sub.ru> <45DC39BC.5020707@alkar.net> <45DC44AF.30005@webmail.sub.ru> <45DC4640.8030309@alkar.net> <45DDBBB3.3020900@webmail.sub.ru> <45DDC091.3060903@alkar.net> <45DDC852.9060503@webmail.sub.ru> In-Reply-To: <45DDC852.9060503@webmail.sub.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd success stories, anyone? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 17:15:49 -0000 Alex Povolotsky wrote: > After disabling windowing and setting net.graph's, mpd4 refuses to work > and no ng interfaces ever created > > lowering both tunables to 128000 solved the problem, will look more. Oops! I have missed kern.ipc.maxsockbuf=1048576 , which is required before those two tunes. But as I have said that options is not required for mpd itself. It's just usefull for 'ngctl list' command. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 17:22:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E1B016A403 for ; Thu, 22 Feb 2007 17:22:42 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA7113C428 for ; Thu, 22 Feb 2007 17:22:41 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-235-229.51-151.net24.it [151.51.229.235]) (authenticated bits=128) by parrot.aev.net (8.13.8/8.13.8) with ESMTP id l1MHTT23010559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Feb 2007 18:29:35 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l1MHNZAt066220; Thu, 22 Feb 2007 18:23:35 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45DDD156.3020805@netfence.it> Date: Thu, 22 Feb 2007 18:22:30 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.9 (X11/20070119) MIME-Version: 1.0 To: "Bruce A. Mah" References: <45DDABA6.60407@netfence.it> <45DDC9CD.1020207@freebsd.org> In-Reply-To: <45DDC9CD.1020207@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: Bridge and NAT problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 17:22:42 -0000 Bruce A. Mah wrote: > You didn't say which bridging driver or version of FreeBSD you're using, > but it sounds to me like you're using bridge(4), right? Yes. > This is a > fairly well known problem, which I wrote a little bit about here: > > http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.html > > (This message describes a scenario with ipf, but it applies equally well > I think to ipfw.) Read that. So I guess my analysis was wrong in that I thought natd was not reconverting packets; from what you say I understand the problem is that this packets are not diverted to natd, right? The details are right now beyond my understanding... > If you can, try switching to using if_bridge(4). I cannot right now, since I have to wait to be physically at this box, but I could try in the future. Do you see any drawback? > You (probably) want to > assign the public NAT address to the bridge0 interface, and leave the > physical interfaces making up the bridges (xl0 and rl1 in your case) > unnumbered. I've had good experiences with this type of configuration. Ok. So I would only need to create the bridge0 interface as per man page sysctl net.link.bridge.ipfw=1 sysctl net.link.bridge.pfil_onlyip=0 change every reference to rl1 in my ipfw ruleset to bridge0 Anything else? Would everything work the same as now (apart from this "feature" which is causing me troubles)? bye & Thanks a lot av. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 17:26:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A59A16A400; Thu, 22 Feb 2007 17:26:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3732413C442; Thu, 22 Feb 2007 17:26:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id EAA06297; Fri, 23 Feb 2007 04:25:46 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 23 Feb 2007 04:25:46 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <45DC9AAC.8090301@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: admin , freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: ipfw limit src-addr woes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 17:26:13 -0000 On Wed, 21 Feb 2007, Julian Elischer wrote: > Ian Smith wrote: > > On Tue, 20 Feb 2007, Julian Elischer wrote: > > > admin wrote: > > > > > > > Wrong: the implied "check-state" done by the "limit" lets the connection > > > > through (i.e. performs the action) iff there's state recorded for it > > > > (src-addr+src-port+dst-addr+dst-port). If however it's a SYN packet > > > > incoming and the number of current states is trying to cross the limit, > > > > the SYN packet is implicitly dropped and the search terminates. > > > > > > > > This is not to say that I completely understand the things going on when > > > > the connections start building up (different timeouts?) but the above > > > > conclusion is based on what simulation has shown. The whole ruleset fits > > > > on one screen, there's an "allow ip from any to any" in the end, so I'm > > > > pretty sure I'm not crazy :-) > > > > > > One thing to keep in mind is that a 'check-state' rule works by effectively > > > jumping to the rule that did the 'keep-state' and re-executing it.. > > > (and incrementing its stats). > > > > What if the action of the rule that does the 'keep-state' (here a limit > > src-addr) is a skipto, rather than an allow / fwd / divert etc rule that > > would terminate the search? Does 're-executing' here imply anything > > about whether the skipto's conditional branch is or is not taken? > > if the keep-state rule is a skipto then the check-state will skip to.. > I use that in some rules. > > here's a snippet that I have when acting as a filtering transparent bridge, > with DNS replies (from the outside) being diverted to a snooper. > The bridge is between em2 (inside) and em3 (outside). > > 01200 17588453 1257728932 skipto 1210 udp from any to any dst-port 53 recv em2 > 01201 16192860 2721432229 skipto 1220 udp from any 53 to any recv em3 > 01202 43658738 21537916245 skipto 1250 ip from any to any > 01210 34023270 3994649771 skipto 1240 ip from any to any keep-state > 01220 0 0 check-state > 01229 2364 441701 deny ip from any to any > 01240 16190496 2720990528 divert 5001 udp from any 53 to any recv em3 > 01242 17832774 1273659243 deny ip from any to any > > (note this requires patches to allow divert from a bridge.) > It's convoluted I know but it only (well, mostly) diverts packets from > the outside that are part of a conversation that was started already > (probably by a dns request from inside) DNS packets from the outside > that are not a response to something we already asked for are discarded > (a DOS protection) > > note that all the packets that went to the check-state, (1220) ended up > going back to 1210 where they did the skipto 1240 and were filtered again. Thanks Julian, great illustration! After much chewing I've got most of the marrow, but have buried this bone where I can dig it up again (woof) Re admin's issue, I notice that the em3 packets failing check-state still require denying at 1229, such that p(kts)1201 - p1229 = p1240. Do you have any earlier rules jumping into here too, as the 1210 packet counts don't quite add up; ie p1210 > (p1200 + p1240) by ~244k packets? Re 1242, are these (mostly) diverted packets reentering the firewall? After snooping, how do the clients get their DNS replies if they're denied here, or does your divert code reinsert those elsewhere? And where do the then ~1.2M extra denied packets denied here come from? Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 20:12:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFDF416A400 for ; Thu, 22 Feb 2007 20:12:03 +0000 (UTC) (envelope-from chekorn@yahoo.com) Received: from web52305.mail.yahoo.com (web52305.mail.yahoo.com [206.190.48.148]) by mx1.freebsd.org (Postfix) with SMTP id 8039613C48D for ; Thu, 22 Feb 2007 20:12:03 +0000 (UTC) (envelope-from chekorn@yahoo.com) Received: (qmail 41201 invoked by uid 60001); 22 Feb 2007 19:45:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ebgIsnbt+noduPeg1v/bL1ewVKV/plVAXnSu4uI+8Iax9nRZW2jSqRKEHqgkkrfjngxMuowRzFexERs1Yt4kGj9Mk+MluWX54kFoN9oUzLYk8RaPSJP1K5K525RF1tRCiLfGiR2a3FzS4AjklXQNyhyKIx8ZQwtXyg3KTEG7uyM=; X-YMail-OSG: kOd_6SoVM1lW11OGh3wWPW_2gix7pk8pnDaRuaBiz85t4ZUNeauKMUsmDJpsufBqqMrS6ZEm1na31y542XBJ4vSZVCW7yYE_wIKYzPIuHU40RXrXAYHEaNjgcZx3EiT068.480ogNGVZKUsi.M4ID1MC Received: from [208.251.106.83] by web52305.mail.yahoo.com via HTTP; Thu, 22 Feb 2007 11:45:22 PST Date: Thu, 22 Feb 2007 11:45:22 -0800 (PST) From: Jeremy Nelson To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <784231.40396.qm@web52305.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 5.4-RELEASE and 5.5-RELEASE Slow routing table response X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 20:12:04 -0000 I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This server has been up and running beautifully for about a year and a half with no issues. Just the other day I had a user try to connect to a host on the Internet and her connection was failing. At first I thought that it was the receiving host's issue because we were having no other Internet connection issues through the proxy. However, I ran a test connection from my home and found that everything worked fine. After investigating the issue I found that if I ran a "route get xxx.xxx.xxx.xxx" on my proxy server it would take 1.25 minutes for the route to come back. This same delay was also experienced if I tried to use telnet to open a connection to the remote host. After about 1.25 minutes the session would open successfully. So I ran "route monitor" and found that when I execute the "route get" command the RTM_GET returns the appropriate route almost immediately but there is still a substantial delay in the "route get" command displaying the response. I ran this test on three other 5.4 and one 5.5 servers and found that they all had the same issue. However, if I ran the same "route get" command on a 5.3 server it works just fine. After all of my testing I wanted to know exactly what IP address range was affected and found that it is limited to just 60 address within a specific range (I can provide the range). Any help you could provide would be greatly appreciated. --------------------------------- Don't get soaked. Take a quick peak at the forecast with theYahoo! Search weather shortcut. From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 20:40:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F73A16A405 for ; Thu, 22 Feb 2007 20:40:32 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3168713C4B9 for ; Thu, 22 Feb 2007 20:40:32 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 199602AD5540; Thu, 22 Feb 2007 20:20:52 +0000 (UTC) Received: from [69.31.99.11] (pool011.dhcp.your.org [69.31.99.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 6EBC6A0A44F; Thu, 22 Feb 2007 20:20:51 +0000 (UTC) In-Reply-To: <784231.40396.qm@web52305.mail.yahoo.com> References: <784231.40396.qm@web52305.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevin Day Date: Thu, 22 Feb 2007 14:20:58 -0600 To: Jeremy Nelson X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: 5.4-RELEASE and 5.5-RELEASE Slow routing table response X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 20:40:32 -0000 On Feb 22, 2007, at 1:45 PM, Jeremy Nelson wrote: > I have an Internet proxy that is running FreeBSD 5.4-RELEASE. This > server has been up and running beautifully for about a year and a > half with no issues. > > Just the other day I had a user try to connect to a host on the > Internet and her connection was failing. At first I thought that > it was the receiving host's issue because we were having no other > Internet connection issues through the proxy. However, I ran a > test connection from my home and found that everything worked fine. > > After investigating the issue I found that if I ran a "route get > xxx.xxx.xxx.xxx" on my proxy server it would take 1.25 minutes for > the route to come back. This same delay was also experienced if I > tried to use telnet to open a connection to the remote host. After > about 1.25 minutes the session would open successfully. > > So I ran "route monitor" and found that when I execute the "route > get" command the RTM_GET returns the appropriate route almost > immediately but there is still a substantial delay in the "route > get" command displaying the response. > > I ran this test on three other 5.4 and one 5.5 servers and found > that they all had the same issue. However, if I ran the same > "route get" command on a 5.3 server it works just fine. > > After all of my testing I wanted to know exactly what IP address > range was affected and found that it is limited to just 60 address > within a specific range (I can provide the range). > > Any help you could provide would be greatly appreciated. > > This is almost definitely a DNS issue. Try "route -n get" or "telnet -N" and see if it still happens. -- Kevin From owner-freebsd-net@FreeBSD.ORG Thu Feb 22 21:31:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7AD516A403 for ; Thu, 22 Feb 2007 21:31:12 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id DD3DD13C442 for ; Thu, 22 Feb 2007 21:31:11 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 35621 invoked by uid 0); 23 Feb 2007 00:37:16 +0300 Received: from tarkhil.rostokino.net (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 22 Feb 2007 21:37:16 -0000 Message-ID: <45DE0B9C.8080000@webmail.sub.ru> Date: Fri, 23 Feb 2007 00:31:08 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Fighting mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2007 21:31:12 -0000 Hello! Thanks to all who helped, I'm progressing. The box seems to be unstable, however, it reboots with watchdog, not freeze. After boot, I'm getting a message Feb 22 20:58:12 gw kernel: Memory modified after free 0xc4524000(2048) val=a028c0de @ 0xc4524000 Feb 22 20:58:12 gw kernel: Memory modified after free 0xc4525800(2048) val=a028c0de @ 0xc4525800 Feb 22 20:58:12 gw kernel: Memory modified after free 0xc452d800(2048) val=a028c0de @ 0xc452d800 I guess something is wrong with some part of kernel. I'll happily accept any help in tracing the problem source. I'll look at average uptime. FreeBSD 6.2-RELEASE-p1, mpd 4.1 Alex. From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 02:01:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57A0516A402 for ; Fri, 23 Feb 2007 02:01:10 +0000 (UTC) (envelope-from x_element108@btinternet.com) Received: from smtp807.mail.ukl.yahoo.com (smtp807.mail.ukl.yahoo.com [217.12.12.197]) by mx1.freebsd.org (Postfix) with SMTP id B4D9013C441 for ; Fri, 23 Feb 2007 02:01:09 +0000 (UTC) (envelope-from x_element108@btinternet.com) Received: (qmail 90216 invoked from network); 23 Feb 2007 01:34:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=ku8m9ddlLUvNIZvV/WpOlv+A3xgFcMfvGQGhHeyt50kr7hECMr46vxrexYklGTyltSdxiU/e1mN3WGd0wdKIDULUcs126vLFNJbZGM+aOKfm/WVOuUEeGljMJg0EhsLERtb7bEkHHw47xd5CGUXZvjAYCtuwbFBF0b01FXFutnU= ; Received: from unknown (HELO ?192.168.1.67?) (x_element108@btinternet.com@86.133.112.228 with plain) by smtp807.mail.ukl.yahoo.com with SMTP; 23 Feb 2007 01:34:27 -0000 X-YMail-OSG: UwMZjaYVM1lw0_5ZHCujtmnbXX4mwC7zbPkeiNl39Y4BQDwjSDl9hHT_o3x2tmJjuLPVxKXJYGFvsqbli83oNvIz1ZWV6PIN9DrlHeKord5VyDhMAkrXeDECuPANR9T4xYdvB8A53gip Message-ID: <45DE4477.1010903@btinternet.com> Date: Fri, 23 Feb 2007 01:33:43 +0000 From: "Rajen Jani (BT Yahoo! Broadband)" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Remote Install using FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 02:01:10 -0000 Hello everyone, I was wondering if you could help me with this one. I am trying to do this one without any luck. How do you remote install FReeBSD using FreeBSD? There doesn't seem to be any documentation around to help me. No Step 1, Step 2 , Step 3 guide. I have searched the web and the nearest I came to was a guy using isc-DHCP program which wasn't included in the original FreeBSD installation. I download it to carry on with the rest of the steps but it doesn't do well with make install clean. If anyone has done it alternatively, please let me know. The laptop that is going to be the client has PXE boot built in the BIOS. Regards, Rajen From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 02:53:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9383916A400 for ; Fri, 23 Feb 2007 02:53:25 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9FC13C47E for ; Fri, 23 Feb 2007 02:53:25 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HKPxb-000Psd-NF; Fri, 23 Feb 2007 10:15:00 +0800 Message-ID: <45DE4E23.6000702@micom.mng.net> Date: Fri, 23 Feb 2007 10:14:59 +0800 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: "Rajen Jani (BT Yahoo! Broadband)" References: <45DE4477.1010903@btinternet.com> In-Reply-To: <45DE4477.1010903@btinternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Remote Install using FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 02:53:25 -0000 Rajen Jani (BT Yahoo! Broadband) wrote: > Hello everyone, > > I was wondering if you could help me with this one. I am > trying to do this one without any luck. How do you remote > install FReeBSD using FreeBSD? There doesn't seem to be any > documentation around to help me. No Step 1, Step 2 , Step 3 guide. > I have searched the web and the nearest I came to was a guy using > isc-DHCP program which wasn't included in the original FreeBSD > installation. I download it to carry on with the rest of the steps but > it doesn't do well with make install clean. > > If anyone has done it alternatively, please let me know. The laptop that > is going to be the client has PXE boot built in the BIOS. > Did you check FreeBSD handbook? Ganbold > Regards, > > > Rajen > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 05:54:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9667E16A401 for ; Fri, 23 Feb 2007 05:54:35 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mx1.freebsd.org (Postfix) with ESMTP id 813E213C428 for ; Fri, 23 Feb 2007 05:54:35 +0000 (UTC) (envelope-from pramod@juniper.net) Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 22 Feb 2007 21:26:04 -0800 X-IronPort-AV: i="4.14,208,1170662400"; d="scan'208"; a="679980926:sNHT47194444" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 21:26:03 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Feb 2007 21:26:02 -0800 Message-ID: <5EB31780BD297F46812C8F495FA08F620A86FF54@electron.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sleeping thread Thread-Index: AcdWS3/cInQ5751jQiWLiwe40yrmigAvm6AA From: "Pramod Srinivasan" To: X-OriginalArrivalTime: 23 Feb 2007 05:26:03.0704 (UTC) FILETIME=[1C751380:01C7570B] Subject: sleeping thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 05:54:35 -0000 Hi Folks, I am coming across a weird issue with FreeBSD 6.1, any help appreciated. The problem is the following: One thread (1) does a setsockopt, grabs a lock in udp_usrreq, calls copyin which hits a pagefault, this leads to that thread sleeping by calling msleep. msleep(f01cd488,c09fe6a0,44,c0956c79,0) at bwait(f01cd488,44,c0956c79) at vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at vop_stdgetpages(fcd6d98c) at Another thread (netisr) which is processing some udp packet tries to grab the same lock but since it's already held by thread 1, tries to propagate the priority and panics because there is a check in the code in propagate_priority which causes the panic /* * If the thread is asleep, then we are probably about * to deadlock. To make debugging this easier, just * panic and tell the user which thread misbehaved so * they can hopefully get a stack trace from the truly * misbehaving thread. */ if (TD_IS_SLEEPING(td)) { printf( "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n", td->td_tid, td->td_proc->p_pid); #ifdef DDB db_trace_thread(td, -1); #endif panic("sleeping thread"); } Below is the output with witness turned on.... Not sure how to go forward with this, any pointers? Thanks, Pramod lock order reversal: (sleepable after non-sleepable) 1st 0xc0a20a8c udp (udp) @ src/sys/netinet/udp_usrreq.c:1523 2nd 0xccdbee54 user map (user map) @ src/sys/vm/vm_map.c:3005 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c09c1b40,c09c16e0,c0978c6c) at witness_checkorder(ccdbee54,9,c09305b4,bbd) at _sx_xlock(ccdbee54,c09305a8,bbd) at _vm_map_lock_read(ccdbee10,c09305a8,bbd,1d6d9b4,ccdd76a8) at vm_map_lookup(fcd6da40,8097000,1,fcd6da44,fcd6da34) at vm_fault(ccdbee10,8097000,1,0,ccdd5000) at trap_pfault(fcd6db08,0,8097940) at trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at calltrap() at --- trap 0xc, eip =3D 0xc08a5e06, esp =3D 0xfcd6db48, ebp =3D 0xfcd6db68 = --- slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at kern_setsockopt(ccdd5000,6,0,6d,8097940) at setsockopt(ccdd5000,fcd6dd04,5,2,292) at syscall(3b,3b,3b,0,7a6c) at Xint0x80_syscall() at --- syscall (105, FreeBSD ELF32, setsockopt), eip =3D 0x881d1787, esp = =3D 0xbfbfddec, ebp =3D 0xbfbfde48 --- Acquiring lockmgr lock "isofs" with the following non-sleepable locks held: exclusive sleep mutex udp r =3D 0 (0xc0a20a8c) locked @ src/sys/netinet/udp_usrreq.c:1523 KDB: stack backtrace: kdb_backtrace(1,1,1,3041,ccd0bd6c) at witness_warn(5,c09b211c,c09416bb,c09406a1) at lockmgr(ccd0bd48,3041,ccd0bd6c,ccdd5000,fcd6d918) at vop_stdlock(fcd6d938,3041,ccd0bcf0,fcd6d954,c058e20c) at VOP_LOCK_APV(c09704e0,fcd6d938) at vn_lock(ccd0bcf0,3041,ccdd5000,ccd0bcf0,3041) at vget(ccd0bcf0,3041,ccdd5000) at vnode_pager_lock(ccdf1840,ccdf1840,ccdf1840,0,c0930058) at vm_fault(ccdbee10,8097000,1,0,ccdd5000) at trap_pfault(fcd6db08,0,8097940) at trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at calltrap() at --- trap 0xc, eip =3D 0xc08a5e06, esp =3D 0xfcd6db48, ebp =3D 0xfcd6db68 = --- slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at kern_setsockopt(ccdd5000,6,0,6d,8097940) at setsockopt(ccdd5000,fcd6dd04,5,2,292) at syscall(3b,3b,3b,0,7a6c) at Xint0x80_syscall() at --- syscall (105, FreeBSD ELF32, setsockopt), eip =3D 0x881d1787, esp = =3D 0xbfbfddec, ebp =3D 0xbfbfde48 --- Sleeping on "vnsrd" with the following non-sleepable locks held: exclusive sleep mutex udp r =3D 0 (0xc0a20a8c) locked @ src/sys/netinet/udp_usrreq.c:1523 KDB: stack backtrace: kdb_backtrace(1,1,1,ccdd763c,ccdd5000) at witness_warn(5,c09fe6a0,c0942b95,c0956c79) at msleep(f01cd488,c09fe6a0,44,c0956c79,0) at bwait(f01cd488,44,c0956c79) at vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at vop_stdgetpages(fcd6d98c) at VOP_GETPAGES_APV(c09704e0,fcd6d98c) at vnode_pager_getpages(c10487bc,fcd6da50,1,0) at vm_fault(ccdbee10,8097000,1,0,ccdd5000) at trap_pfault(fcd6db08,0,8097940) at trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at calltrap() at --- trap 0xc, eip =3D 0xc08a5e06, esp =3D 0xfcd6db48, ebp =3D 0xfcd6db68 = --- slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at kern_setsockopt(ccdd5000,6,0,6d,8097940) at setsockopt(ccdd5000,fcd6dd04,5,2,292) at syscall(3b,3b,3b,0,7a6c) at Xint0x80_syscall() at --- syscall (105, FreeBSD ELF32, setsockopt), eip =3D 0x881d1787, esp = =3D 0xbfbfddec, ebp =3D 0xbfbfde48 --- Sleeping thread (tid 100087, pid 4302) owns a non-sleepable lock panic: sleeping thread db_log_stack_trace_cmd(c09b2de0) at 0 panic(c0943cde,c08f8bec,186f7,10ce,c09b2ae0) at 0 propagate_priority(cc727c00,c09b6bf0,c0a20a8c,cc727c00,c09089b0) at 0 turnstile_wait(c0a20a8c,ccdd5000,c0a20a8c,2,c08f60ec,225) at 0 _mtx_lock_sleep(c0a20a8c,cc727c00,0,c09089b0,10c) at 0 _mtx_lock_flags(c0a20a8c,0,c09089b0,10c,0) at 0 udp_input(ccd34b00,14,0,4,4) at 0 ip_input(cca7d180,ccd34b00,1,c08f60ec,c0a1be10) at 0 netisr_processqueue(c0a1b738) at 0 swi_net(0) at 0 ithread_execute_handlers(cc726428,cc724500) at 0 ithread_loop(cc70e740,f8de1d38,cc70e740,c051a45a,0) at 0 fork_exit(c051a45a,cc70e740,f8de1d38) at 0 fork_trampoline() at 0 --- trap 0x1, eip =3D 0, esp =3D 0xf8de1d6c, ebp =3D 0 --- KDB: enter: panic [thread pid 14 tid 100002 ] Stopped at kdb_enter+0x37: pushl $-0x1 db> =20 From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 06:06:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5761A16A401 for ; Fri, 23 Feb 2007 06:06:33 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4089813C478 for ; Fri, 23 Feb 2007 06:06:33 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1N66WCB015311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Feb 2007 22:06:32 -0800 Message-ID: <45DE8465.8090507@freebsd.org> Date: Thu, 22 Feb 2007 22:06:29 -0800 From: "Bruce A. Mah" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45DDABA6.60407@netfence.it> <45DDC9CD.1020207@freebsd.org> <45DDD156.3020805@netfence.it> In-Reply-To: <45DDD156.3020805@netfence.it> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB793ED9C54D3406FEB908C49" Subject: Re: Bridge and NAT problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 06:06:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB793ED9C54D3406FEB908C49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Andrea Venturoli wrote: > Bruce A. Mah wrote: >=20 >> You didn't say which bridging driver or version of FreeBSD you're usin= g, >> but it sounds to me like you're using bridge(4), right? >=20 > Yes. >=20 >=20 >=20 >> This is a >> fairly well known problem, which I wrote a little bit about here: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2004-December/006075.ht= ml >> >> (This message describes a scenario with ipf, but it applies equally we= ll >> I think to ipfw.) >=20 > Read that. > So I guess my analysis was wrong in that I thought natd was not=20 > reconverting packets; from what you say I understand the problem is tha= t=20 > this packets are not diverted to natd, right? > The details are right now beyond my understanding... Without more details it's difficult to say. Not to be overly critical, but "does not work" from your original post isn't real helpful, unfortunately. If you had packet traces of, say, attempted pings, that would give a lot more data to help say exactly what the problem is. It just sounds *very* similar to a problem I spent a lot of time working on.= >> If you can, try switching to using if_bridge(4). >=20 > I cannot right now, since I have to wait to be physically at this box, = > but I could try in the future. Do you see any drawback? None I can think of. Note that bridge(4) is deprecated in RELENG_6 and is gone entirely from HEAD (in favor of if_bridge(4)). if_bridge(4) is also more featureful and is being actively worked on. >> You (probably) want to >> assign the public NAT address to the bridge0 interface, and leave the >> physical interfaces making up the bridges (xl0 and rl1 in your case) >> unnumbered. I've had good experiences with this type of configuration= =2E >=20 > Ok. > So I would only need to > create the bridge0 interface as per man page > sysctl net.link.bridge.ipfw=3D1 > sysctl net.link.bridge.pfil_onlyip=3D0 > change every reference to rl1 in my ipfw ruleset to bridge0 >=20 > Anything else? > Would everything work the same as now (apart from this "feature" which = > is causing me troubles)? I think that'll work, yes. (Caveat: If you are doing other filtering in ipfw you might need to make some additional adjustments, but if all you're doing is NAT/divert, "change every reference to rl1 ... to bridge0" should work just fine.) Bruce. --------------enigB793ED9C54D3406FEB908C49 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3oRo2MoxcVugUsMRAgNXAKDjMr75CynlS6dPtMdTdE0Cg6hn1QCfWz6W YBphZyECbTdX2CTpQKKI9G8= =DtSh -----END PGP SIGNATURE----- --------------enigB793ED9C54D3406FEB908C49-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 07:45:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00AD716A400 for ; Fri, 23 Feb 2007 07:45:06 +0000 (UTC) (envelope-from mav@alkar.net) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7A58713C471 for ; Fri, 23 Feb 2007 07:45:03 +0000 (UTC) (envelope-from mav@alkar.net) Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 21107145; Fri, 23 Feb 2007 09:45:02 +0200 Message-ID: <45DE9B7D.8070200@alkar.net> Date: Fri, 23 Feb 2007 09:45:01 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Alex Povolotsky References: <1172193780.00692898.1172180402@10.7.7.3> In-Reply-To: <1172193780.00692898.1172180402@10.7.7.3> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fighting mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 07:45:06 -0000 To somehow limit searching area, I think you should try to disable all possible additional functions like netflow, tee, DialOnDemand, tcpmssfix, nat, vjcomp, compression, encryption and everything else you have and can disable for some time without harm. -- Alexander Motin mav@alkar.net Optima Telecom From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 12:42:29 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8659D16A40A; Fri, 23 Feb 2007 12:42:29 +0000 (UTC) (envelope-from anders@FreeBSD.org) Received: from fupp.net (totem.fix.no [80.91.36.20]) by mx1.freebsd.org (Postfix) with ESMTP id 49D6B13C4CB; Fri, 23 Feb 2007 12:42:29 +0000 (UTC) (envelope-from anders@FreeBSD.org) Received: from localhost (totem.fix.no [80.91.36.20]) by fupp.net (Postfix) with ESMTP id 28C868D984C; Fri, 23 Feb 2007 13:17:04 +0100 (CET) Received: from fupp.net ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id Sy-AlWyCd874; Fri, 23 Feb 2007 13:17:03 +0100 (CET) Received: by fupp.net (Postfix, from userid 1000) id CD8898D9919; Fri, 23 Feb 2007 13:17:03 +0100 (CET) Date: Fri, 23 Feb 2007 13:17:03 +0100 From: Anders Nordby To: gnn@freebsd.org Message-ID: <20070223121703.GA86159@fupp.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: net@FreeBSD.org Subject: Re: Networking FreeBSD Wiki X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 12:42:29 -0000 Hi, George, maybe there should be a separate category in GNATS also, for network issues? On Thu, Feb 08, 2007 at 05:07:31PM -0800, gnn@freebsd.org wrote: > I've started a Wiki page in the FreeBSD Wiki in an attempt to > coordinate some of the clean up work and networking projects that > aren't already covered. Please see: > > http://wiki.freebsd.org/Networking > > and update (if you're a committer) or email me corrections etc. > > Best, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Anders. From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 15:05:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71A6516A402 for ; Fri, 23 Feb 2007 15:05:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0787313C48E for ; Fri, 23 Feb 2007 15:05:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5C440476B7; Fri, 23 Feb 2007 10:05:12 -0500 (EST) Date: Fri, 23 Feb 2007 15:05:12 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pramod Srinivasan In-Reply-To: <5EB31780BD297F46812C8F495FA08F620A86FF54@electron.jnpr.net> Message-ID: <20070223145802.S88189@fledge.watson.org> References: <5EB31780BD297F46812C8F495FA08F620A86FF54@electron.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: sleeping thread X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 15:05:15 -0000 On Thu, 22 Feb 2007, Pramod Srinivasan wrote: > I am coming across a weird issue with FreeBSD 6.1, any help appreciated. > > The problem is the following: > > One thread (1) does a setsockopt, grabs a lock in udp_usrreq, calls copyin > which hits a pagefault, this leads to that thread sleeping by calling > msleep. Performing copying/copyout while holding a mutex, especially one also required from interrupt or software interrupt context, is a bug for precisely the reason you describe here: interrupt context can get blocked waiting on an unbounded operation such as a disk read. However, I'm slightly confused by your stacktrace: in FreeBSD 6.1, there is no udp_ctloutput(), only a udp_ctlinput(). This aside, there have been a number of problems relating to ip_ctloutput() holding locks over calls to copy in and out socket buffer arguments. I believe these are mostly fixed in 7.x, and actually largely fixed in 6.x, although possibly after 6.1. The basic approach to fixing this is to either not acquire the locks until after the copy operation, or release them before the operation. This turns out to be a bit tricky, because certain pointers remain stable only while the locks are held, so the pointers may need to be re-derived or re-validated with the locks acquired. Diffing ip_ctloutput.c between 6.1 and 6.2 will most likely give you a sense of what is required: http://fxr.watson.org/fxr/diff/netinet/ip_output.c?v=RELENG61;diffval=RELENG62;diffvar=v In particular, look at the comment at the start of ip_ctloutput(). Robert N M Watson Computer Laboratory University of Cambridge > > msleep(f01cd488,c09fe6a0,44,c0956c79,0) at > bwait(f01cd488,44,c0956c79) at > vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at > vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at > vop_stdgetpages(fcd6d98c) at > > Another thread (netisr) which is processing some udp packet tries to > grab the same lock but since it's already held by thread 1, tries to > propagate the priority and panics because there is a check in the code > in propagate_priority which causes the panic > > /* > * If the thread is asleep, then we are probably about > * to deadlock. To make debugging this easier, just > * panic and tell the user which thread misbehaved so > * they can hopefully get a stack trace from the truly > * misbehaving thread. > */ > if (TD_IS_SLEEPING(td)) { > printf( > "Sleeping thread (tid %d, pid %d) owns a non-sleepable > lock\n", > td->td_tid, td->td_proc->p_pid); > #ifdef DDB > db_trace_thread(td, -1); > #endif > panic("sleeping thread"); > } > > Below is the output with witness turned on.... > > Not sure how to go forward with this, any pointers? > > Thanks, > Pramod > > lock order reversal: (sleepable after non-sleepable) > 1st 0xc0a20a8c udp (udp) @ src/sys/netinet/udp_usrreq.c:1523 > 2nd 0xccdbee54 user map (user map) @ src/sys/vm/vm_map.c:3005 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c09c1b40,c09c16e0,c0978c6c) at > witness_checkorder(ccdbee54,9,c09305b4,bbd) at > _sx_xlock(ccdbee54,c09305a8,bbd) at > _vm_map_lock_read(ccdbee10,c09305a8,bbd,1d6d9b4,ccdd76a8) at > vm_map_lookup(fcd6da40,8097000,1,fcd6da44,fcd6da34) at > vm_fault(ccdbee10,8097000,1,0,ccdd5000) at > trap_pfault(fcd6db08,0,8097940) at > trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at > calltrap() at > --- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 --- > slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at > ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at > udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at > sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at > kern_setsockopt(ccdd5000,6,0,6d,8097940) at > setsockopt(ccdd5000,fcd6dd04,5,2,292) at > syscall(3b,3b,3b,0,7a6c) at > Xint0x80_syscall() at > --- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x881d1787, esp = > 0xbfbfddec, ebp = 0xbfbfde48 --- > Acquiring lockmgr lock "isofs" with the following non-sleepable locks > held: > exclusive sleep mutex udp r = 0 (0xc0a20a8c) locked @ > src/sys/netinet/udp_usrreq.c:1523 > KDB: stack backtrace: > kdb_backtrace(1,1,1,3041,ccd0bd6c) at > witness_warn(5,c09b211c,c09416bb,c09406a1) at > lockmgr(ccd0bd48,3041,ccd0bd6c,ccdd5000,fcd6d918) at > vop_stdlock(fcd6d938,3041,ccd0bcf0,fcd6d954,c058e20c) at > VOP_LOCK_APV(c09704e0,fcd6d938) at > vn_lock(ccd0bcf0,3041,ccdd5000,ccd0bcf0,3041) at > vget(ccd0bcf0,3041,ccdd5000) at > vnode_pager_lock(ccdf1840,ccdf1840,ccdf1840,0,c0930058) at > vm_fault(ccdbee10,8097000,1,0,ccdd5000) at > trap_pfault(fcd6db08,0,8097940) at > trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at > calltrap() at > --- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 --- > slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at > ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at > udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at > sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at > kern_setsockopt(ccdd5000,6,0,6d,8097940) at > setsockopt(ccdd5000,fcd6dd04,5,2,292) at > syscall(3b,3b,3b,0,7a6c) at > Xint0x80_syscall() at > --- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x881d1787, esp = > 0xbfbfddec, ebp = 0xbfbfde48 --- > Sleeping on "vnsrd" with the following non-sleepable locks held: > exclusive sleep mutex udp r = 0 (0xc0a20a8c) locked @ > src/sys/netinet/udp_usrreq.c:1523 > KDB: stack backtrace: > kdb_backtrace(1,1,1,ccdd763c,ccdd5000) at > witness_warn(5,c09fe6a0,c0942b95,c0956c79) at > msleep(f01cd488,c09fe6a0,44,c0956c79,0) at > bwait(f01cd488,44,c0956c79) at > vnode_pager_input_smlfs(c10487bc,c2740ae0,0,1,fcd6d918) at > vnode_pager_generic_getpages(ccd0bcf0,fcd6da50,1000,0,fcd6d978) at > vop_stdgetpages(fcd6d98c) at > VOP_GETPAGES_APV(c09704e0,fcd6d98c) at > vnode_pager_getpages(c10487bc,fcd6da50,1,0) at > vm_fault(ccdbee10,8097000,1,0,ccdd5000) at > trap_pfault(fcd6db08,0,8097940) at > trap(fcd60008,ccdd0028,28,fcd6db94,8097940) at > calltrap() at > --- trap 0xc, eip = 0xc08a5e06, esp = 0xfcd6db48, ebp = 0xfcd6db68 --- > slow_copyin(fcd6dc88,fcd6db94,4,4,fcd6db98) at > ip_ctloutput(ccdfd4ec,fcd6dc88,0,c054f464,0) at > udp_ctloutput(ccdfd4ec,fcd6dc88,246,c0977524,ccdf3c2c) at > sosetopt(ccdfd4ec,fcd6dc88,ccde5090,1,0) at > kern_setsockopt(ccdd5000,6,0,6d,8097940) at > setsockopt(ccdd5000,fcd6dd04,5,2,292) at > syscall(3b,3b,3b,0,7a6c) at > Xint0x80_syscall() at > --- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x881d1787, esp = > 0xbfbfddec, ebp = 0xbfbfde48 --- > Sleeping thread (tid 100087, pid 4302) owns a non-sleepable lock > panic: sleeping thread > db_log_stack_trace_cmd(c09b2de0) at 0 > panic(c0943cde,c08f8bec,186f7,10ce,c09b2ae0) at 0 > propagate_priority(cc727c00,c09b6bf0,c0a20a8c,cc727c00,c09089b0) at 0 > turnstile_wait(c0a20a8c,ccdd5000,c0a20a8c,2,c08f60ec,225) at 0 > _mtx_lock_sleep(c0a20a8c,cc727c00,0,c09089b0,10c) at 0 > _mtx_lock_flags(c0a20a8c,0,c09089b0,10c,0) at 0 > udp_input(ccd34b00,14,0,4,4) at 0 > ip_input(cca7d180,ccd34b00,1,c08f60ec,c0a1be10) at 0 > netisr_processqueue(c0a1b738) at 0 > swi_net(0) at 0 > ithread_execute_handlers(cc726428,cc724500) at 0 > ithread_loop(cc70e740,f8de1d38,cc70e740,c051a45a,0) at 0 > fork_exit(c051a45a,cc70e740,f8de1d38) at 0 > fork_trampoline() at 0 > --- trap 0x1, eip = 0, esp = 0xf8de1d6c, ebp = 0 --- > KDB: enter: panic > [thread pid 14 tid 100002 ] > Stopped at kdb_enter+0x37: pushl $-0x1 > db> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Feb 23 15:36:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D1FA16A400 for ; Fri, 23 Feb 2007 15:36:09 +0000 (UTC) (envelope-from x_element108@btinternet.com) Received: from smtp811.mail.ukl.yahoo.com (smtp811.mail.ukl.yahoo.com [217.12.12.201]) by mx1.freebsd.org (Postfix) with SMTP id B8D4B13C4B6 for ; Fri, 23 Feb 2007 15:36:08 +0000 (UTC) (envelope-from x_element108@btinternet.com) Received: (qmail 70930 invoked from network); 23 Feb 2007 15:36:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; b=Yi1s/2pEWpDiqpNPEj4RIzq8ogPFZMK3rhsHRiAhZ8x48DctYVJfVGn74P25WLObJ7GqU7URrXE5vFDNiC+/ULFafGKqWuLggn3IFL8dD+EVcFNzoPFqV23KCOBvAp9gAfjqvAoU7vXcbXD0z7CV0SJCFzkc3X5ax0k/Ijh0gUE= ; Received: from unknown (HELO ?192.168.1.67?) (x_element108@btinternet.com@86.133.112.228 with plain) by smtp811.mail.ukl.yahoo.com with SMTP; 23 Feb 2007 15:36:06 -0000 X-YMail-OSG: EfMBTzkVM1lTAA6hC.QfBC_R8Fcu1Tt4uNdU6aPqIvTDF2s7C.6uP6h8LB0Ln6A_TdP7EgRVSExzaUOB0ArBdOYRPQvNV55FSCHDyuUUrlGcdaOkdjQ- Message-ID: <45DF09BD.5000208@btinternet.com> Date: Fri, 23 Feb 2007 15:35:25 +0000 From: "Rajen Jani (BT Yahoo! Broadband)" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/related; boundary="------------000605070706050701030902" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ganbold@micom.mng.net Subject: TFTPd FreeBSD Installtion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2007 15:36:09 -0000 This is a multi-part message in MIME format. --------------000605070706050701030902 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Hello everyone. I have setup a TFTPd on Windows XP (please don't frown!). All I need to know is what boot loader information do I have to provide to it to get the remote install working. Let me show you a screenshot. The G:\ directory is the 1st base install CD-ROM in this instance. If there are any additional options that I need to provide this also will be great. Right now the client ip, mask, dhcp & gateway ip all get assigned but the PXE then just hangs (sort off). It does check my CD-ROM out and I get a TFTP message on my diskless client but then thats it. Any help will be appreciated. Regards, Rajen --------------000605070706050701030902-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 24 08:17:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F89516A400 for ; Sat, 24 Feb 2007 08:17:56 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 9231A13C491 for ; Sat, 24 Feb 2007 08:17:55 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 13163 invoked by uid 0); 24 Feb 2007 11:24:02 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 24 Feb 2007 08:24:02 -0000 Message-ID: <45DFF4AF.1030506@webmail.sub.ru> Date: Sat, 24 Feb 2007 11:17:51 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexander Motin References: <1172193780.00692898.1172180402@10.7.7.3> <45DE9B7D.8070200@alkar.net> In-Reply-To: <45DE9B7D.8070200@alkar.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fighting mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 08:17:56 -0000 Alexander Motin wrote: > To somehow limit searching area, I think you should try to disable all > possible additional functions like netflow, tee, DialOnDemand, > tcpmssfix, nat, vjcomp, compression, encryption and everything else > you have and can disable for some time without harm. > No netflow, no nat, no dialonemand; disabling tcpmssfix will most likely render system useless, I'll disable all compression and encryption today and look. Alex. From owner-freebsd-net@FreeBSD.ORG Sat Feb 24 11:47:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BD2B16A402 for ; Sat, 24 Feb 2007 11:47:49 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by mx1.freebsd.org (Postfix) with ESMTP id DA36C13C467 for ; Sat, 24 Feb 2007 11:47:48 +0000 (UTC) (envelope-from j.witteveen@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so786151nzh for ; Sat, 24 Feb 2007 03:47:48 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:references; b=Dw5Vb7DkZ2qYRTElIqG/X7VqDYNwJsjdOEGrwnOhEKjoCOWNKcYasIT5BT23RmRRXy3SyqGS6qACKsAV2yiG08Q+CqW+CtevBigP/R1HDhFRHLiaX3F4fU9gbJbsfy9yvA7tL9biuwKe6YlHMZTgz3iDArLcpzEO6q8y5qBqZzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:subject:cc:in-reply-to:mime-version:content-type:references; b=b623m0o+w4usJ8hVSDj9vpVLCTuvurxxNGChBS+2ElsteBZKkoibkze6jMR6ag40n90arumk/3oM97ZUEqVYcWVMT7sF5nY7evnwjEBV97UsaU+K1f6nR15ZqSzntV/rqygNoqUEenkeeE1m9722ylT3lc9sE8dWepYtBSt2Q/g= Received: by 10.115.54.1 with SMTP id g1mr29668wak.1172317667952; Sat, 24 Feb 2007 03:47:47 -0800 (PST) Received: by 10.114.12.1 with HTTP; Sat, 24 Feb 2007 03:47:47 -0800 (PST) Message-ID: <3993a4980702240347o2ee0388bx42e29854928cadfd@mail.gmail.com> Date: Sat, 24 Feb 2007 12:47:47 +0100 From: "Jouke Witteveen" Cc: freebsd-net@freebsd.org In-Reply-To: <45D748C5.6040904@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_65670_21733424.1172317667877" References: <3993a4980702051233u10c30575kd1f6d27fcd600110@mail.gmail.com> <45C7A1F9.20306@FreeBSD.org> <3993a4980702170546t7f9384eaq358986a4cc734582@mail.gmail.com> <45D748C5.6040904@FreeBSD.org> Subject: Re: [PATCH] Re: ioctl: SIOCADDMULTI (howto?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 11:47:49 -0000 ------=_Part_65670_21733424.1172317667877 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 2/17/07, Bruce M. Simpson wrote: > Jouke Witteveen wrote: > > > > So my apologies for suggesting it doesn't work at all; it seems that > > the application I'm trying to get to work (wpa_supplicant for wired > > interfaces) just doesn't _send_ its packets the right way. > That's a big relief! I added an item to the Wiki for someone to write a > regression test. > > > > Things aren't perfect though. In if.c the if_findmulti function is > > broken (always returns NULL). I presume just comparing the > > *LLADDR((sockaddr *)sa) data on both sockets is a better check, though > > my knowledge on these things is limited. > I think I see a possible problem, though the code looks as though it is > behaving as expected. > I am looking at RELENG_6 if.c. I think sa_equal() may be to blame. > > sa_equal() performs a binary comparison on all of sa_data up to sa_len. > Looking at struct sockaddr_dl, this might not be the right thing at all > in that situation... though I need another pair of eyes to look. Can > anyone shed light on this? An AF_INET and AF_INET6 address can be > completely specified and compared with sa_equal(). An AF_LINK address > looks as though sa_equal() may return irrational results. > > > > As for netstat, I do not really know what is keeping it from showing > > the Multicast addresses. Again: my knowledge on this matter is > > limited. All I can think of is that getifmaddrs is forgetting > > something (perhaps the lack of a group membership). Maybe you can take > > a look at it (I believe you wrote it). > > I wrote the libc getifmaddrs() function and integrated it into netstat > -g; Harti Brandt wrote the NET_RT_IFMALIST support. getifmaddrs() > *should* return sockaddr_dl as well as sockaddr_in and all the others. > > netstat skips over AF_LINK addresses. Try this patch to reveal them. It > doesn't seem to show the IPv4 link layer memberships underneath, which > is interesting... > > > > As I am still learning how best to contribute to a project as big as > > FreeBSD and I do not think I am skilled enough yet in C I refrain from > > writing a patch. I am eager to see one though, be it only out of > > curiosity to know what would be considered a proper fix. > Give it a try anyway! I like to think we have strong healthy egos round > here. > > Regards, > BMS > > Thanks for that enormous stimulation; it really gave me some confidence. I have (before I saw your ethermcast.diff patch) been trying some things too and found that the patch attached did the job for me. As for now I haven't found any glitches yet as a result of this change. I notice however that you have probably foreseen quite some situations with your patch, since it looks far more complex than mine. However I'm pleased to see I managed to get something done myself. As for the netstat patch: it works like a shine! Very nicely done (ie: thanks). I will now try to make the wired driver of wpa_supplicant work in FreeBSD (it still isn't able to send/receive packages properly), as that is what started this whole bug-hunt of mine. Thanks again for your help and motivation. Regards, - Jouke ------=_Part_65670_21733424.1172317667877 Content-Type: text/x-patch; name="if.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if.c.diff" X-Attachment-Id: f_eyk00ycb LS0tIGlmLmMub3JpZwlXZWQgRmViIDE1IDA0OjM3OjE1IDIwMDYKKysrIGlmLmMJVGh1IEZlYiAy MiAwOToxMjoxMSAyMDA3CkBAIC0xODM4LDExICsxODM4LDE3IEBACiBpZl9maW5kbXVsdGkoc3Ry dWN0IGlmbmV0ICppZnAsIHN0cnVjdCBzb2NrYWRkciAqc2EpCiB7CiAJc3RydWN0IGlmbXVsdGlh ZGRyICppZm1hOworCWNhZGRyX3QgZGF0YSA9IExMQUREUigoc3RydWN0IHNvY2thZGRyX2RsICop c2EpOwogCiAJSUZfQUREUl9MT0NLX0FTU0VSVChpZnApOwogCiAJVEFJTFFfRk9SRUFDSChpZm1h LCAmaWZwLT5pZl9tdWx0aWFkZHJzLCBpZm1hX2xpbmspIHsKLQkJaWYgKHNhX2VxdWFsKGlmbWEt PmlmbWFfYWRkciwgc2EpKQorCQkvKgorCQkgKiBJbiBtdWx0aWNhc3Rpbmcgd2UgYXJlIG9ubHkg aW50ZXJlc3RlZCBpbiB0aGUgYWRkcmVzcyB2YWx1ZQorCQkgKiBvYnRhaW5lZCB3aXRoIExMQURE UigpLgorCQkgKi8KKwkJaWYgKGJjbXAoTExBRERSKChzdHJ1Y3Qgc29ja2FkZHJfZGwgKilpZm1h LT5pZm1hX2FkZHIpLCBkYXRhLAorCQkgICAgRVRIRVJfQUREUl9MRU4pID09IDApCiAJCQlicmVh azsKIAl9CiAK ------=_Part_65670_21733424.1172317667877-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 24 15:13:59 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2793116A40B for ; Sat, 24 Feb 2007 15:13:59 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id BB96513C4B9 for ; Sat, 24 Feb 2007 15:13:58 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 68D1535B77 for ; Sat, 24 Feb 2007 16:13:57 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id DCDBB9BE05 for ; Sat, 24 Feb 2007 15:15:49 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id BDBC84087; Sat, 24 Feb 2007 16:15:49 +0100 (CET) Date: Sat, 24 Feb 2007 16:15:49 +0100 From: Jeremie Le Hen To: freebsd-net@FreeBSD.org Message-ID: <20070224151549.GJ2479@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d8Lz2Tf5e5STOWUP" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: TCP connection stalls on LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 15:13:59 -0000 --d8Lz2Tf5e5STOWUP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm running a quite recent -CURRENT. I don't understand what's happening. According to tcpdump(1) it seems the two peers both keep acknowledging the same segment for ever. (See the file attached.) The peer is a Linksys router that have worked correctly for a while. The problem arises only with it, I can successfully connect to a NetBSD and a Windows host. I've attached the dump output. Feel free to ask me for more infos. Note that automatic TCP socket buffer sizing is disabled (the same happens when enabled). I've also disabled rxcsum and txcsum on my network adapter to narrow the possible sources of the problem. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --d8Lz2Tf5e5STOWUP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tcp.dump" 09:14:57.593729 IP (tos 0x0, ttl 64, id 27791, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.1.3.56556 > 192.168.1.1.80: S, cksum 0xe59c (correct), 487760288:487760288(0) win 65535 09:14:57.597224 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.1.1.80 > 192.168.1.3.56556: S, cksum 0xe603 (correct), 2303804549:2303804549(0) ack 487760289 win 5792 09:14:57.597306 IP (tos 0x0, ttl 64, id 2460, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x2a62 (correct), 1:1(0) ack 1 win 260 09:14:57.601590 IP (tos 0x0, ttl 64, id 48542, offset 0, flags [DF], proto: TCP (6), length: 488) 192.168.1.3.56556 > 192.168.1.1.80: P 1:437(436) ack 1 win 260 09:14:57.602390 IP (tos 0x0, ttl 64, id 26779, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x108d (correct), 1:1(0) ack 437 win 6432 09:14:57.605968 IP (tos 0x0, ttl 64, id 26780, offset 0, flags [DF], proto: TCP (6), length: 308) 192.168.1.1.80 > 192.168.1.3.56556: P 1:257(256) ack 437 win 6432 09:14:57.613414 IP (tos 0x0, ttl 64, id 26781, offset 0, flags [DF], proto: TCP (6), length: 1500) 192.168.1.1.80 > 192.168.1.3.56556: . 257:1705(1448) ack 437 win 6432 09:14:57.613465 IP (tos 0x0, ttl 64, id 38624, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x21fb (correct), 437:437(0) ack 1705 win 254 09:14:57.816442 IP (tos 0x0, ttl 64, id 26782, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x09c4 (correct), 1704:1704(0) ack 437 win 6432 09:14:57.816489 IP (tos 0x0, ttl 64, id 4315, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x212a (correct), 437:437(0) ack 1705 win 260 09:14:58.236395 IP (tos 0x0, ttl 64, id 26783, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x08cf (correct), 1704:1704(0) ack 437 win 6432 09:14:58.236448 IP (tos 0x0, ttl 64, id 48004, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x1f86 (correct), 437:437(0) ack 1705 win 260 09:14:59.076354 IP (tos 0x0, ttl 64, id 26784, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x06d7 (correct), 1704:1704(0) ack 437 win 6432 09:14:59.076403 IP (tos 0x0, ttl 64, id 4302, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x1c3e (correct), 437:437(0) ack 1705 win 260 09:15:00.756298 IP (tos 0x0, ttl 64, id 26785, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x02e7 (correct), 1704:1704(0) ack 437 win 6432 09:15:00.756344 IP (tos 0x0, ttl 64, id 47006, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x15ae (correct), 437:437(0) ack 1705 win 260 09:15:04.116021 IP (tos 0x0, ttl 64, id 26786, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0xfb06 (correct), 1704:1704(0) ack 437 win 6432 09:15:04.116068 IP (tos 0x0, ttl 64, id 63692, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x088e (correct), 437:437(0) ack 1705 win 260 --d8Lz2Tf5e5STOWUP-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 24 16:48:38 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5603616A402 for ; Sat, 24 Feb 2007 16:48:38 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout04-04.prod.mesa1.secureserver.net (smtpout04-04.prod.mesa1.secureserver.net [64.202.165.199]) by mx1.freebsd.org (Postfix) with SMTP id 32B9F13C491 for ; Sat, 24 Feb 2007 16:48:37 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 10497 invoked from network); 24 Feb 2007 16:48:37 -0000 Received: from unknown (24.144.77.243) by smtpout04-04.prod.mesa1.secureserver.net (64.202.165.199) with ESMTP; 24 Feb 2007 16:48:37 -0000 Message-ID: <45E06C64.6010705@seclark.us> Date: Sat, 24 Feb 2007 11:48:36 -0500 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremie Le Hen References: <20070224151549.GJ2479@obiwan.tataz.chchile.org> In-Reply-To: <20070224151549.GJ2479@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: TCP connection stalls on LAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 16:48:38 -0000 Jeremie Le Hen wrote: >Hi, > >I'm running a quite recent -CURRENT. > >I don't understand what's happening. According to tcpdump(1) it seems >the two peers both keep acknowledging the same segment for ever. >(See the file attached.) > >The peer is a Linksys router that have worked correctly for a while. >The problem arises only with it, I can successfully connect to a >NetBSD and a Windows host. > >I've attached the dump output. Feel free to ask me for more infos. > >Note that automatic TCP socket buffer sizing is disabled (the same >happens when enabled). I've also disabled rxcsum and txcsum on >my network adapter to narrow the possible sources of the problem. > >Regards, > > >------------------------------------------------------------------------ > >09:14:57.593729 IP (tos 0x0, ttl 64, id 27791, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.1.3.56556 > 192.168.1.1.80: S, cksum 0xe59c (correct), 487760288:487760288(0) win 65535 >09:14:57.597224 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.1.1.80 > 192.168.1.3.56556: S, cksum 0xe603 (correct), 2303804549:2303804549(0) ack 487760289 win 5792 >09:14:57.597306 IP (tos 0x0, ttl 64, id 2460, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x2a62 (correct), 1:1(0) ack 1 win 260 >09:14:57.601590 IP (tos 0x0, ttl 64, id 48542, offset 0, flags [DF], proto: TCP (6), length: 488) 192.168.1.3.56556 > 192.168.1.1.80: P 1:437(436) ack 1 win 260 >09:14:57.602390 IP (tos 0x0, ttl 64, id 26779, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x108d (correct), 1:1(0) ack 437 win 6432 >09:14:57.605968 IP (tos 0x0, ttl 64, id 26780, offset 0, flags [DF], proto: TCP (6), length: 308) 192.168.1.1.80 > 192.168.1.3.56556: P 1:257(256) ack 437 win 6432 >09:14:57.613414 IP (tos 0x0, ttl 64, id 26781, offset 0, flags [DF], proto: TCP (6), length: 1500) 192.168.1.1.80 > 192.168.1.3.56556: . 257:1705(1448) ack 437 win 6432 >09:14:57.613465 IP (tos 0x0, ttl 64, id 38624, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x21fb (correct), 437:437(0) ack 1705 win 254 >09:14:57.816442 IP (tos 0x0, ttl 64, id 26782, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x09c4 (correct), 1704:1704(0) ack 437 win 6432 >09:14:57.816489 IP (tos 0x0, ttl 64, id 4315, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x212a (correct), 437:437(0) ack 1705 win 260 >09:14:58.236395 IP (tos 0x0, ttl 64, id 26783, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x08cf (correct), 1704:1704(0) ack 437 win 6432 >09:14:58.236448 IP (tos 0x0, ttl 64, id 48004, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x1f86 (correct), 437:437(0) ack 1705 win 260 >09:14:59.076354 IP (tos 0x0, ttl 64, id 26784, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x06d7 (correct), 1704:1704(0) ack 437 win 6432 >09:14:59.076403 IP (tos 0x0, ttl 64, id 4302, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x1c3e (correct), 437:437(0) ack 1705 win 260 >09:15:00.756298 IP (tos 0x0, ttl 64, id 26785, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0x02e7 (correct), 1704:1704(0) ack 437 win 6432 >09:15:00.756344 IP (tos 0x0, ttl 64, id 47006, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x15ae (correct), 437:437(0) ack 1705 win 260 >09:15:04.116021 IP (tos 0x0, ttl 64, id 26786, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.1.80 > 192.168.1.3.56556: ., cksum 0xfb06 (correct), 1704:1704(0) ack 437 win 6432 >09:15:04.116068 IP (tos 0x0, ttl 64, id 63692, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.3.56556 > 192.168.1.1.80: ., cksum 0x088e (correct), 437:437(0) ack 1705 win 260 > > > > looks like the 1500 byte packet is not making it thru the network. Lower your mtu and see if this helps. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Sat Feb 24 23:58:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0972E16A407 for ; Sat, 24 Feb 2007 23:58:21 +0000 (UTC) (envelope-from spam_quarantine@xserve1.eeinternational.org) Received: from xserve1.eeinternational.org (50-36-13-69.cust.propagation.net [69.13.36.50]) by mx1.freebsd.org (Postfix) with ESMTP id E25C213C441 for ; Sat, 24 Feb 2007 23:58:20 +0000 (UTC) (envelope-from spam_quarantine@xserve1.eeinternational.org) Received: from localhost (localhost [127.0.0.1]) by xserve1.eeinternational.org (Postfix) with ESMTP id B85FE370F77A for ; Sat, 24 Feb 2007 17:44:17 -0600 (CST) Received: from xserve1.eeinternational.org ([127.0.0.1]) by localhost (50-36-13-69.cust.propagation.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01958-06 for ; Sat, 24 Feb 2007 17:44:17 -0600 (CST) Received: by xserve1.eeinternational.org (Postfix, from userid 2624) id 0CE633701AA0; Sat, 24 Feb 2007 17:23:30 -0600 (CST) To: freebsd-net@freebsd.org From: no-reply@bussinesideas.com Message-Id: <20070224232330.0CE633701AA0@xserve1.eeinternational.org> Date: Sat, 24 Feb 2007 17:23:30 -0600 (CST) X-Virus-Scanned: by amavisd-new at eeinternational.org MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: http://leet.110mb.com The latest bussiness idea ! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2007 23:58:21 -0000 Hello ! We are sorry if we distrubed you . Your email is in our email bank . We found out that you are an active bussiness man ,so we were wondering of you are interested in a bussiness offer . If so , please check out site for all the info. http://leet.110mb.com We apologise again if this e-mail bottered you in anyway . Thank you !