From owner-freebsd-net Sun Nov 3 0:20:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55EA837B401; Sun, 3 Nov 2002 00:20:35 -0800 (PST) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A38D43E75; Sun, 3 Nov 2002 00:20:34 -0800 (PST) (envelope-from mbretter@inode.at) Received: from line-c-98.adsl-dynamic.inode.at ([62.99.151.98]:1168 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 188Fta-000578-00; Sun, 03 Nov 2002 09:14:10 +0100 Message-ID: <3DC4DB96.9070402@inode.at> Date: Sun, 03 Nov 2002 09:17:26 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2b) Gecko/20021016 X-Accept-Language: de-at, de-de, de, en, en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Cc: brian@freebsd.org Subject: ppp radius programmer question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I'm implementing radius for mpd and I found maybe a leak in radius.c of the userland-ppp. in the function radius_Process, I think there is a missing free function call: snip case RAD_MICROSOFT_MS_MPPE_RECV_KEY: free(r->mppe.recvkey); demangle(r, data, len, &r->mppe.recvkey, &r->mppe.recvkeylen); log_Printf(LogPHASE, " MS-MPPE-Recv-Key ********\n"); break; case RAD_MICROSOFT_MS_MPPE_SEND_KEY: <--- isn't here missing: free(r->mppe.sendkey); --> demangle(r, data, len, &r->mppe.sendkey, &r->mppe.sendkeylen); log_Printf(LogPHASE, " MS-MPPE-Send-Key ********\n"); break; Am I right or is this just a bug in my brain? bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 4:29: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2526537B438 for ; Sun, 3 Nov 2002 04:29:01 -0800 (PST) Received: from terror.org.pl (terror.icm.edu.pl [193.219.28.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C4FD43F6B for ; Sun, 3 Nov 2002 04:28:34 -0800 (PST) (envelope-from ofca@terror.org.pl) Received: from ofca (helo=localhost) by terror.org.pl with local-esmtp id 188JrT-000175-00; Sun, 03 Nov 2002 13:28:15 +0100 Date: Sun, 3 Nov 2002 13:28:14 +0100 (CET) From: Pawel Tyll X-X-Sender: ofca@terror.org.pl To: Julian Elischer Cc: brian@awfulhak.org, Subject: Re: PPPoEd Bug. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2 Nov 2002, Julian Elischer wrote: > The code for doing non complient pppoe was written to be used as a > client. I'm amazed it works as a server too.. (and I wrote it). Well, it worked allright for me (and it would be a nice feature too, short of this bug ;) ) > Am I right in understanding that you accidentally had a non-compliant > client, and therefore discoverd that FreeBSD as a server could cope with > that, but that once it did, it couldn't go back? I wasn't at first aware that it was this client at fault (I didn't know it was patched back then). But generally you're right :) > I'll have a look. Thank You Best regards, Pawel 'ofca' Tyll. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 6:39: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17ADA37B401 for ; Sun, 3 Nov 2002 06:38:38 -0800 (PST) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1830143E6E for ; Sun, 3 Nov 2002 06:38:35 -0800 (PST) (envelope-from mbretter@inode.at) Received: from line-c-98.adsl-dynamic.inode.at ([62.99.151.98]:1186 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 188Lmr-0001Jo-00; Sun, 03 Nov 2002 15:31:37 +0100 Message-ID: <3DC53410.8000602@inode.at> Date: Sun, 03 Nov 2002 15:34:56 +0100 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, Archie Cobbs Cc: Brendan Bank Subject: mpd radius - request for review Content-Type: multipart/mixed; boundary="------------090203030406080803080701" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------090203030406080803080701 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, now I finished the work for radius-mpd-integration. It would be great if my code will be reviewed and integrated into "official" mpd. If there are any bugs or dirty hacks in my code, then let me know. I tested the code successfuly against freeradius and Microsoft Radius (Windows 2000). All auth-types are supported (pap, chap-md5, mschap v1 and mschap v2), also mppe works. Here are the new config-params: set radius config /etc/radius.conf or set radius retries 3 set radius timeout 3 set radius server localhost testing123 => configures radius (thanks to Brendan Bank). set bundle enable radius-auth => enables Radius Auth set bundle enable radius-fallback => enables fallback to mpd.secret if radius-auth not succeeded set ipcp enable radius-ip => let the radius-server assign the ip for the user with "show radius" all radius-related params are printed out. After the code has being integrated into mpd I would like continue implementing more features: - MPPE Types and Policy - Let mpd use other radius-params. - Accounting If the code is to bad for integration into mpd, no problem, because then it was only a good exercise for me. I attached the patches and also 2 new files for mpd 3.10. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 --------------090203030406080803080701 Content-Type: text/plain; name="mpd_radius.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mpd_radius.diff" Index: Makefile =================================================================== RCS file: /cvsrep/mpd/src/Makefile,v retrieving revision 1.4 retrieving revision 1.8 diff -r1.4 -r1.8 1c1 < # $Id: Makefile,v 1.4 2002/10/26 12:26:03 mbretter Exp $ --- > # $Id: Makefile,v 1.8 2002/11/03 14:09:20 mbretter Exp $ 43a44 > 48a50,52 > RADIUS= yes > LDADD+= -lradius > 84c88 < vars.c custom.c --- > vars.c custom.c radius.c Index: bund.c =================================================================== RCS file: /cvsrep/mpd/src/bund.c,v retrieving revision 1.3 diff -r1.3 bund.c 129c129,131 < { 0, 0, NULL }, --- > { 0, BUND_CONF_RADIUSAUTH, "radius-auth" }, > { 0, BUND_CONF_RADIUSFALLBACK, "radius-fallback" }, > { 0, 0, NULL }, 595,598c597,600 < if ((sb = gBundles[k]) != NULL) { < printf(BUND_FMT, sb->name); < BundShowLinks(sb); < } --- > if ((sb = gBundles[k]) != NULL) { > printf(BUND_FMT, sb->name); > BundShowLinks(sb); > } 605,610c607,612 < bund = sb; < if (lnk->bund != bund) < lnk = bund->links[0]; < } else < printf("Bundle \"%s\" not defined.\n", av[0]); < break; --- > bund = sb; > if (lnk->bund != bund) > lnk = bund->links[0]; > } else > printf("Bundle \"%s\" not defined.\n", av[0]); > break; 714a717,719 > > Disable(&bund->conf.options, BUND_CONF_RADIUSAUTH); > Disable(&bund->conf.options, BUND_CONF_RADIUSFALLBACK); Index: bund.h =================================================================== RCS file: /cvsrep/mpd/src/bund.h,v retrieving revision 1.4 diff -r1.4 bund.h 22a23 > #include "radius.h" 40a42,43 > BUND_CONF_RADIUSAUTH, /* enable radius auth */ > BUND_CONF_RADIUSFALLBACK, /* enable fallback to mpd.secret */ 134a138,140 > > /* radius */ > struct radius radius; Index: ccp_mppc.c =================================================================== RCS file: /cvsrep/mpd/src/ccp_mppc.c,v retrieving revision 1.2 retrieving revision 1.4 diff -r1.2 -r1.4 595a596,604 > if (bund->radius.valid == 1) { > if (dir == COMP_DIR_XMIT) { > memcpy(mppc->xmit_key0, bund->radius.mppe.sendkey, MPPE_KEY_LEN); > } else { > memcpy(mppc->recv_key0, bund->radius.mppe.recvkey, MPPE_KEY_LEN); > } > return; > } > Index: chap.c =================================================================== RCS file: /cvsrep/mpd/src/chap.c,v retrieving revision 1.3 retrieving revision 1.8 diff -r1.3 -r1.8 18a19 > #include "radius.h" 30,42d30 < struct mschapvalue { < u_char lmHash[24]; < u_char ntHash[24]; < u_char useNT; < }; < < struct mschapv2value { < u_char peerChal[16]; < u_char reserved[8]; < u_char ntHash[24]; < u_char flags; < }; < 77c65 < case AUTH_SELF_TO_PEER: /* Just wait for peer's challenge */ --- > case AUTH_SELF_TO_PEER: /* Just wait for peer's */ 285a274 > int radRes = RAD_NACK; 322c311 < if (ChapParsePkt(bp, len, peer_name, chap_value, &chap_value_size) < 0) --- > if (ChapParsePkt(bp, len, peer_name, chap_value, &chap_value_size) < 0) { 323a313,314 > } > Log(LG_AUTH, (" DEBUG CHAP_CHALLENGE: peer_name = %s", peer_name)); 458a450 > Log(LG_AUTH, (" DEBUG CHAP_RESPONSE: peer_name = %s", peer_name)); 468,474d459 < /* Get peer's secret key */ < Log(LG_AUTH, (" Peer name: \"%s\"", peer_name)); < if (AuthGetData(peer_name, &auth, 1, &whyFail) < 0) { < Log(LG_AUTH, (" Can't get credentials for \"%s\"", peer_name)); < goto badResponse; < } < 479,498c464,504 < /* Get expected hash value */ < if ((hash_value_size = ChapHash(chap->recv_alg, hash_value, chp.id, < peer_name, auth.password, chap->chal_data, chap->chal_len, < 0)) < 0) { < Log(LG_AUTH, (" Hash failure")); < whyFail = AUTH_FAIL_INVALID_PACKET; < goto badResponse; < } < < /* Compare with peer's response */ < if (chap->chal_len == 0 < || !ChapHashAgree(chap->recv_alg, hash_value, hash_value_size, < chap_value, chap_value_size)) { < Log(LG_AUTH, (" Invalid response")); < whyFail = AUTH_FAIL_INVALID_LOGIN; < badResponse: < failMesg = AuthFailMsg(PROTO_CHAP, chap->recv_alg, whyFail); < ChapOutput(CHAP_FAILURE, chp.id, failMesg, strlen(failMesg)); < AuthFinish(AUTH_PEER_TO_SELF, FALSE, NULL); < break; --- > if (Enabled(&bund->conf.options, BUND_CONF_RADIUSAUTH)) { > radRes = RadiusCHAPAuthenticate(peer_name, chap_value, chap_value_size, chap->chal_data, chap->chal_len, chp.id, chap->recv_alg); > if (radRes == RAD_NACK && !Enabled(&bund->conf.options, BUND_CONF_RADIUSFALLBACK)) { > whyFail = AUTH_FAIL_INVALID_LOGIN; > goto badResponse; > } > > if (radRes == RAD_ACK) RadiusSetAuth(&auth); > } > > if ((radRes == RAD_NACK && Enabled(&bund->conf.options, BUND_CONF_RADIUSFALLBACK)) || > !Enabled(&bund->conf.options, BUND_CONF_RADIUSAUTH)) { > > /* Get peer's secret key */ > Log(LG_AUTH, (" Peer name: \"%s\"", peer_name)); > if (AuthGetData(peer_name, &auth, 1, &whyFail) < 0) { > Log(LG_AUTH, (" Can't get credentials for \"%s\"", peer_name)); > goto badResponse; > } > > /* Get expected hash value */ > if ((hash_value_size = ChapHash(chap->recv_alg, hash_value, chp.id, > peer_name, auth.password, chap->chal_data, chap->chal_len, > 0)) < 0) { > Log(LG_AUTH, (" Hash failure")); > whyFail = AUTH_FAIL_INVALID_PACKET; > goto badResponse; > } > > /* Compare with peer's response */ > if (chap->chal_len == 0 > || !ChapHashAgree(chap->recv_alg, hash_value, hash_value_size, > chap_value, chap_value_size)) { > Log(LG_AUTH, (" Invalid response")); > whyFail = AUTH_FAIL_INVALID_LOGIN; > badResponse: > failMesg = AuthFailMsg(PROTO_CHAP, chap->recv_alg, whyFail); > ChapOutput(CHAP_FAILURE, chp.id, failMesg, strlen(failMesg)); > AuthFinish(AUTH_PEER_TO_SELF, FALSE, NULL); > break; > } 513a520 > #ifdef MICROSOFT_CHAP 520,525c527,537 < /* Generate MS-CHAPv2 'authenticator response' */ < GenerateAuthenticatorResponse(auth.password, pv->ntHash, < pv->peerChal, chap->chal_data, peer_name, authresp); < for (i = 0; i < 20; i++) < sprintf(hex + (i * 2), "%02X", authresp[i]); < snprintf(ackMesg, sizeof(ackMesg), "S=%s", hex); --- > if (radRes == RAD_ACK) { > strcpy(ackMesg, bund->radius.mschapv2resp); > } else { > /* Generate MS-CHAPv2 'authenticator response' */ > GenerateAuthenticatorResponse(auth.password, pv->ntHash, > pv->peerChal, chap->chal_data, peer_name, authresp); > for (i = 0; i < 20; i++) > sprintf(hex + (i * 2), "%02X", authresp[i]); > snprintf(ackMesg, sizeof(ackMesg), "S=%s", hex); > } > #endif 526a539 > Index: chap.h =================================================================== RCS file: /cvsrep/mpd/src/chap.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -r1.1.1.1 -r1.2 57a58,70 > struct mschapvalue { > u_char lmHash[24]; > u_char ntHash[24]; > u_char useNT; > }; > > struct mschapv2value { > u_char peerChal[16]; > u_char reserved[8]; > u_char ntHash[24]; > u_char flags; > }; > Index: command.c =================================================================== RCS file: /cvsrep/mpd/src/command.c,v retrieving revision 1.3 retrieving revision 1.5 diff -r1.3 -r1.5 17a18 > #include "radius.h" 90a92,93 > { "radius", "radius status", > RadStat, AdmitBund, NULL }, 116a120,121 > { "radius ...", "Set radius configuration", > CMD_SUBMENU, AdmitBund, (void *) RadiusSetCmds }, Index: ipcp.c =================================================================== RCS file: /cvsrep/mpd/src/ipcp.c,v retrieving revision 1.2 retrieving revision 1.3 diff -r1.2 -r1.3 68,77d67 < /* Configuration options */ < enum { < IPCP_CONF_VJCOMP, < IPCP_CONF_REQPRIDNS, < IPCP_CONF_REQSECDNS, < IPCP_CONF_REQPRINBNS, < IPCP_CONF_REQSECNBNS, < IPCP_CONF_PRETENDIP, < }; < 142a133 > { 0, IPCP_CONF_RADIUSIP, "radius-ip" }, Index: ipcp.h =================================================================== RCS file: /cvsrep/mpd/src/ipcp.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -r1.1.1.1 -r1.2 25a26,37 > > /* Configuration options */ > enum { > IPCP_CONF_VJCOMP, > IPCP_CONF_REQPRIDNS, > IPCP_CONF_REQSECDNS, > IPCP_CONF_REQPRINBNS, > IPCP_CONF_REQSECNBNS, > IPCP_CONF_PRETENDIP, > IPCP_CONF_RADIUSIP, > }; > Index: log.c =================================================================== RCS file: /cvsrep/mpd/src/log.c,v retrieving revision 1.3 retrieving revision 1.4 diff -r1.3 -r1.4 119a120,122 > #ifdef LG_RADIUS > ADD_OPT(RADIUS, "Radius authentication events") > #endif Index: log.h =================================================================== RCS file: /cvsrep/mpd/src/log.h,v retrieving revision 1.3 retrieving revision 1.4 diff -r1.3 -r1.4 44c44,45 < LG_I_CONSOLE --- > LG_I_CONSOLE, > LG_I_RADIUS 69a71 > #define LG_RADIUS (1 << LG_I_RADIUS) 85a88 > | LG_RADIUS \ Index: mbuf.c =================================================================== RCS file: /cvsrep/mpd/src/mbuf.c,v retrieving revision 1.3 retrieving revision 1.4 diff -r1.3 -r1.4 57a58 > { MB_RADIUS, "RADIUS" }, Index: mbuf.h =================================================================== RCS file: /cvsrep/mpd/src/mbuf.h,v retrieving revision 1.3 retrieving revision 1.4 diff -r1.3 -r1.4 58a59 > MB_RADIUS, Index: pap.c =================================================================== RCS file: /cvsrep/mpd/src/pap.c,v retrieving revision 1.4 retrieving revision 1.9 diff -r1.4 -r1.9 15a16 > #include "radius.h" 159a161 > int radRes = RAD_NACK; 190,194c192,199 < /* Get auth data for this system */ < Log(LG_AUTH, (" Peer name: \"%s\"", name)); < if (AuthGetData(name, &auth, 1, &whyFail) < 0) { < Log(LG_AUTH, (" Can't get credentials for \"%s\"", name)); < goto badRequest; --- > if (Enabled(&bund->conf.options, BUND_CONF_RADIUSAUTH)) { > radRes = RadiusPAPAuthenticate(name, pass); > if (radRes == RAD_NACK && !Enabled(&bund->conf.options, BUND_CONF_RADIUSFALLBACK)) { > whyFail = AUTH_FAIL_INVALID_LOGIN; > goto badRequest; > } > > if (radRes == RAD_ACK) RadiusSetAuth(&auth); 197,206c202,203 < /* Do name & password match? */ < if (strcmp(auth.authname, name) || strcmp(auth.password, pass)) { < Log(LG_AUTH, (" Invalid response")); < whyFail = AUTH_FAIL_INVALID_LOGIN; < badRequest: < failMesg = AuthFailMsg(PROTO_PAP, 0, whyFail); < PapOutput(PAP_NAK, php.id, failMesg, strlen(failMesg), 1); < AuthFinish(AUTH_PEER_TO_SELF, FALSE, NULL); < break; < } --- > if ((radRes == RAD_NACK && Enabled(&bund->conf.options, BUND_CONF_RADIUSFALLBACK)) || > !Enabled(&bund->conf.options, BUND_CONF_RADIUSAUTH)) { 207a205,223 > /* Get auth data for this system */ > Log(LG_AUTH, (" Peer name: \"%s\"", name)); > if (AuthGetData(name, &auth, 1, &whyFail) < 0) { > Log(LG_AUTH, (" Can't get credentials for \"%s\"", name)); > goto badRequest; > } > > /* Do name & password match? */ > if (strcmp(auth.authname, name) || strcmp(auth.password, pass)) { > Log(LG_AUTH, (" Invalid response")); > whyFail = AUTH_FAIL_INVALID_LOGIN; > badRequest: > failMesg = AuthFailMsg(PROTO_PAP, 0, whyFail); > PapOutput(PAP_NAK, php.id, failMesg, strlen(failMesg), 1); > AuthFinish(AUTH_PEER_TO_SELF, FALSE, NULL); > break; > } > > } --------------090203030406080803080701 Content-Type: text/plain; name="radius.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="radius.c" /* * radius.c * * Written by Michael Bretterklieber * Written by Brendan Bank * Copyright (c) Brendan Bank 2002 */ #include "radius.h" #include "pptp.h" #include "chap.h" #include #include #include /* Global variables */ static int RadiusSetCommand(int ac, char *av[], void *arg); static int RadiusAddServer (void); static void RadiusInit(void); static void RadiusMPPEExtractKey(const void *mangled, size_t mlen, u_char *buf, size_t *len); static const char * RadiusMPPEPolicyname(int policy); static const char * RadiusMPPETypesname(int types); /* Set menu options */ enum { SET_SERVER, SET_TIMEOUT, SET_RETRIES, SET_CONFIG }; /* * GLOBAL VARIABLES */ const struct cmdtab RadiusSetCmds[] = { { "server [auth port] [acct port]", "Set radius server parameters" , RadiusSetCommand, NULL, (void *) SET_SERVER }, { "timeout ", "Set timeout in seconds", RadiusSetCommand, NULL, (void *) SET_TIMEOUT }, { "retries <# retries>", "set number of retries", RadiusSetCommand, NULL, (void *) SET_RETRIES }, { "config ", "set path to config file for libradius", RadiusSetCommand, NULL, (void *) SET_CONFIG }, { NULL }, }; /* Set menu options */ static int RadiusSetCommand(int ac, char *av[], void *arg) { static char function[] = "RadiusSetCommand"; RadConf const conf = &bund->radius.conf; RadServe_Conf server; RadServe_Conf t_server; int val, count; /* Log(LG_RADIUS, ("[%s] %s: started", lnk->name, function)); */ if (ac == 0) return(-1); switch ((int) arg) { case SET_SERVER: if (ac > 4 || ac < 2) { return(-1); } count = 0; for ( t_server = conf->server ; t_server ; t_server = t_server->next) { count++; } if (count > RADIUS_MAX_SERVERS) { Log(LG_RADIUS, ("[%s] %s: cannot configure more than %d servers", lnk->name, function, RADIUS_MAX_SERVERS)); return (-1); } server = Malloc(MB_RADIUS, sizeof(*server)); server->auth_port = 1645; server->acct_port = 1646; server->next = NULL; if (strlen(av[0]) > 255) { Log(LG_ERR, ("Hostname too long!. > 255 char.")); return(-1); } if (strlen(av[1]) > 127) { Log(LG_ERR, ("Shared Secret too long! > 127 char.")); return(-1); } if (ac > 2 && atoi(av[2]) < 65535 && atoi(av[2]) > 1) { server->auth_port = atoi (av[2]); } else if ( ac > 2 ) { Log(LG_ERR, ("Auth Port number too high > 65535")); return(-1); } if (ac > 3 && atoi(av[3]) < 65535 && atoi(av[3]) > 1) { server->acct_port = atoi (av[3]); } else if ( ac > 3 ) { Log(LG_ERR, ("Acct Port number too high > 65535")); return(-1); } server->hostname = Malloc(MB_RADIUS, strlen(av[0]) + 1); server->sharedsecret = Malloc(MB_RADIUS, strlen(av[1]) + 1); sprintf(server->hostname, "%s" , av[0]); sprintf(server->sharedsecret, "%s" , av[1]); if (conf->server != NULL) server->next = conf->server; conf->server = server; break; case SET_TIMEOUT: val = atoi(*av); if (val <= 0) Log(LG_ERR, ("Timeout must be positive.")); else conf->radius_timeout = val; break; case SET_RETRIES: val = atoi(*av); if (val <= 0) Log(LG_ERR, ("Retries must be positive.")); else conf->radius_retries = val; break; case SET_CONFIG: if (strlen(av[0]) > PATH_MAX) Log(LG_ERR, (" PATH_MAX exceeded for config file.")); else strcpy(conf->file, av[0]); break; default: assert(0); } return 0; } void RadiusInit(void) { struct radius *rad = &bund->radius; if (rad->radh != NULL) rad_close(rad->radh); memset(rad, 0, sizeof(struct radius) - sizeof(struct radiusconf)); } extern int RadiusAuthenticate(const char *name, const char *password, int passlen, const char *challenge, int challenge_size, u_char chapid, int auth_type) { static char function[] = "RadiusAuthenticate"; struct radius *rad = &bund->radius; char host[MAXHOSTNAMELEN]; struct in_addr peer_ip; char *peeripname; int res; struct chap_response chapres; struct mschap_response mschapres; struct mschapv2_response mschap2res; struct mschapv2value *mschapv2; struct mschapvalue *mschapv; RadiusInit(); if (gethostname(host, sizeof (host)) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: gethostname() failed", lnk->name, function)); return (RAD_NACK); } if (name == NULL || password == NULL) { Log(LG_RADIUS, ("[%s] RADIUS: %s: name or password NULL", lnk->name, function)); return (RAD_NACK); } rad->radh = rad_open(); if (rad->radh == NULL) { Log(LG_RADIUS, ("[%s] RADIUS: rad_open failed", lnk->name)); return (RAD_NACK); } if (strlen(bund->radius.conf.file)) { Log(LG_RADIUS, ("[%s] RADIUS: using %s", lnk->name, bund->radius.conf.file)); if (rad_config(rad->radh, bund->radius.conf.file) != 0) { Log(LG_RADIUS, ("[%s] RADIUS: rad_config: %s", lnk->name, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } } if (RadiusAddServer() == RAD_NACK) { rad_close(rad->radh); return (RAD_NACK); } if (rad_create_request(rad->radh, RAD_ACCESS_REQUEST) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: rad_create_request: %s", lnk->name, rad_strerror(rad->radh))); return (RAD_NACK); } if (rad_put_string(rad->radh, RAD_USER_NAME, name) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_string(username) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } switch (auth_type) { case CHAP_ALG_MSOFT: Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_CHAP (MSOFTv1) peer name: %s", lnk->name, function, name)); if (passlen != 49) { Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_CHAP (MSOFTv1) unrecognised key length %d/%d", lnk->name, function, passlen, 49)); rad_close(rad->radh); return RAD_NACK; } if (rad_put_vendor_attr(rad->radh, RAD_VENDOR_MICROSOFT, RAD_MICROSOFT_MS_CHAP_CHALLENGE, challenge, challenge_size) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_vendor_attr(RAD_MICROSOFT_MS_CHAP_CHALLENGE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } mschapv = (struct mschapvalue *)password; mschapres.ident = chapid; mschapres.flags = 0x01; memcpy(mschapres.lm_response, mschapv->lmHash, 24); memcpy(mschapres.nt_response, mschapv->ntHash, 24); if (rad_put_vendor_attr(rad->radh, RAD_VENDOR_MICROSOFT, RAD_MICROSOFT_MS_CHAP_RESPONSE, &mschapres, sizeof mschapres) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_vendor_attr(RAD_MICROSOFT_MS_CHAP_RESPONSE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } break; case CHAP_ALG_MSOFTv2: Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_CHAP (MSOFTv2) peer name: %s", lnk->name, function, name)); if (passlen != sizeof(*mschapv2)) { Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_CHAP (MSOFTv2) unrecognised key length %d/%d", lnk->name, function, passlen, sizeof(*mschapv2))); rad_close(rad->radh); return RAD_NACK; } if (rad_put_vendor_attr(rad->radh, RAD_VENDOR_MICROSOFT, RAD_MICROSOFT_MS_CHAP_CHALLENGE, challenge, challenge_size) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_vendor_attr(RAD_MICROSOFT_MS_CHAP_CHALLENGE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } mschapv2 = (struct mschapv2value *)password; mschap2res.ident = chapid; mschap2res.flags = mschapv2->flags; memcpy(mschap2res.response, mschapv2->ntHash, sizeof mschap2res.response); memset(mschap2res.reserved, '\0', sizeof mschap2res.reserved); memcpy(mschap2res.pchallenge, mschapv2->peerChal, sizeof mschap2res.pchallenge); if (rad_put_vendor_attr(rad->radh, RAD_VENDOR_MICROSOFT, RAD_MICROSOFT_MS_CHAP2_RESPONSE, &mschap2res, sizeof mschap2res) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_vendor_attr(RAD_MICROSOFT_MS_CHAP2_RESPONSE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } break; case CHAP_ALG_MD5: /* Radius wants the CHAP Ident in the first byte of the CHAP-Password */ chapres.ident = chapid; memcpy(chapres.response, password, passlen); Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_CHAP (MD5) peer name: %s", lnk->name, function, name)); if (rad_put_attr(rad->radh, RAD_CHAP_PASSWORD, &chapres, passlen + 1) == -1 || rad_put_attr(rad->radh, RAD_CHAP_CHALLENGE, challenge, challenge_size) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_string(password) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } break; case RADIUS_PAP: Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS_PAP DEBUG: peer name: %s", lnk->name, function, name)); if (rad_put_string(rad->radh, RAD_USER_PASSWORD, password) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_string(password) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } break; default: Log(LG_RADIUS, ("[%s] RADIUS: %s: RADIUS auth type unkown", lnk->name, function)); rad_close(rad->radh); return (RAD_NACK); break; } if (rad_put_string(rad->radh, RAD_NAS_IDENTIFIER, host) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_string(host) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } if (rad_put_int(rad->radh, RAD_SERVICE_TYPE, RAD_FRAMED) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_int(RAD_SERVICE_TYPE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } if (rad_put_int(rad->radh, RAD_FRAMED_PROTOCOL, RAD_PPP) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_int(RAD_FRAMED_PROTOCOL) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } peer_ip = PptpGetPeerIp(); peeripname = inet_ntoa(peer_ip); if (peeripname != NULL) { if (rad_put_string(rad->radh, RAD_CALLING_STATION_ID, inet_ntoa(peer_ip)) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_put_int(RAD_SERVICE_TYPE) failed %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return (RAD_NACK); } } switch (rad_send_request(rad->radh)) { case RAD_ACCESS_ACCEPT: rad->valid = 1; Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_ACCEPT for user %s", lnk->name, function, name)); break; case RAD_ACCESS_REJECT: Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_ACCESS_REJECT for user %s", lnk->name, function, name)); rad_close(rad->radh); return(RAD_NACK); break; case -1: Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request failed %s", lnk->name, function, rad_strerror(rad->radh))); return(RAD_NACK); break; default: Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_send_request: unexpected " "return value %s", lnk->name, function, rad_strerror(rad->radh))); rad_close(rad->radh); return(RAD_NACK); } // Remember authname strncpy(rad->authname, name, AUTH_MAX_AUTHNAME); res = RadiusGetParams(); if (res == RAD_NACK) rad->valid = 0; rad_close(rad->radh); return(res); } int RadiusPAPAuthenticate(const char *name, const char *password) { return (RadiusAuthenticate(name, password, 0, NULL, NULL, 0, RADIUS_PAP)); } int RadiusCHAPAuthenticate(const char *name, const char *password, int passlen, const char *challenge, int challenge_size, u_char chapid, int chap_type) { return (RadiusAuthenticate(name, password, passlen, challenge, challenge_size, chapid, chap_type)); } int RadiusGetParams() { char function[] = "RadiusGetParams"; struct radius *rad = &bund->radius; int res; size_t len; const void *data; u_int32_t vendor; while ((res = rad_get_attr(rad->radh, &data, &len)) > 0) { switch (res) { case RAD_FRAMED_IP_ADDRESS: rad->ip = rad_cvt_addr(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_FRAMED_IP_ADDRESS: %s ", lnk->name, function, inet_ntoa(rad->ip))); break; case RAD_FRAMED_IP_NETMASK: rad->mask = rad_cvt_addr(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_FRAMED_IP_NETMASK: %s ", lnk->name, function, inet_ntoa(rad->mask))); break; case RAD_SESSION_TIMEOUT: rad->sessiontime = rad_cvt_int(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_SESSION_TIMEOUT: %lu ", lnk->name, function, rad->sessiontime)); break; case RAD_FRAMED_MTU: rad->mtu = rad_cvt_int(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_FRAMED_MTU: %lu ", lnk->name, function, rad->mtu)); break; case RAD_FRAMED_COMPRESSION: rad->vj = rad_cvt_int(data) == 1 ? 1 : 0; Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_FRAMED_COMPRESSION: %d ", lnk->name, function, rad->vj)); break; case RAD_VENDOR_SPECIFIC: if ((res = rad_get_vendor_attr(&vendor, &data, &len)) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_get_vendor_attr failed: %s ", lnk->name, function, rad_strerror(rad->radh))); return RAD_NACK; } switch (vendor) { case RAD_VENDOR_MICROSOFT: switch (res) { case RAD_MICROSOFT_MS_CHAP_ERROR: return RAD_NACK; break; /* this was taken from userland ppp */ case RAD_MICROSOFT_MS_CHAP2_SUCCESS: free(rad->mschapv2resp); if (len == 0) rad->mschapv2resp = NULL; else { if (len < 3 || ((const char *)data)[1] != '=') { /* * Only point at the String field if we don't think the * peer has misformatted the response. */ ((const char *)data)++; len--; } else Log(LG_RADIUS, ("[%s] RADIUS: %s: Warning: The MS-CHAP2-Success attribute is mis-formatted. Compensating", lnk->name, function)); if ((rad->mschapv2resp = rad_cvt_string((const char *)data, len)) == NULL) { Log(LG_RADIUS, ("[%s] RADIUS: %s: rad_cvt_string failed: %s", lnk->name, function, rad_strerror(rad->radh))); return RAD_NACK; } Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_MICROSOFT_MS_CHAP2_SUCCESS: %s", lnk->name, function, rad->mschapv2resp)); } break; case RAD_MICROSOFT_MS_MPPE_RECV_KEY: Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_MICROSOFT_MS_MPPE_RECV_KEY", lnk->name, function)); RadiusMPPEExtractKey(data, len, rad->mppe.recvkey, &rad->mppe.recvkeylen); break; case RAD_MICROSOFT_MS_MPPE_SEND_KEY: Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_MICROSOFT_MS_MPPE_SEND_KEY", lnk->name, function)); RadiusMPPEExtractKey(data, len, rad->mppe.sendkey, &rad->mppe.sendkeylen); break; case RAD_MICROSOFT_MS_MPPE_ENCRYPTION_POLICY: rad->mppe.policy = rad_cvt_int(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_MICROSOFT_MS_MPPE_ENCRYPTION_POLICY: %d (%s)", lnk->name, function, rad->mppe.policy, RadiusMPPEPolicyname(rad->mppe.policy))); break; case RAD_MICROSOFT_MS_MPPE_ENCRYPTION_TYPES: rad->mppe.types = rad_cvt_int(data); Log(LG_RADIUS, ("[%s] RADIUS: %s: RAD_MICROSOFT_MS_MPPE_ENCRYPTION_TYPES: %d (%s)", lnk->name, function, rad->mppe.types, RadiusMPPETypesname(rad->mppe.types))); break; default: Log(LG_RADIUS, ("[%s] RADIUS: %s: Dropping MICROSOFT vendor specific attribute: %d ", lnk->name, function, res)); break; } } break; default: Log(LG_RADIUS, ("[%s] RADIUS: %s: Dropping attribute: %d ", lnk->name, function, res)); break; } } return RAD_ACK; } int RadiusAddServer (void) { RadConf const c = &bund->radius.conf; RadServe_Conf s; char function[] = "RadiusAddServer"; int i; struct radius *rad = &bund->radius; if (c->server == NULL) return (RAD_ACK); s = c->server; i = 1; while (s) { Log(LG_RADIUS, ("[%s] RADIUS: %s Adding %s", lnk->name, function, s->hostname)); if (rad_add_server (rad->radh, s->hostname, s->auth_port, s->sharedsecret, c->radius_timeout, c->radius_retries) == -1) { Log(LG_RADIUS, ("[%s] RADIUS: %s error: %s", lnk->name, function, rad_strerror(rad->radh))); return (RAD_NACK); } s = s->next; } return (RAD_ACK); } void RadiusSetAuth(AuthData auth) { char function[] = "RadiusSetAuth"; strncpy(auth->authname, bund->radius.authname, AUTH_MAX_AUTHNAME); if (Enabled(&bund->ipcp.conf.options, IPCP_CONF_RADIUSIP)) { Log(LG_RADIUS, ("[%s] RADIUS: %s: Trying to use IP-address from radius-server", lnk->name, function)); if (strcmp(inet_ntoa(bund->radius.ip), "255.255.255.255") == 0) { /* the peer can choose an address */ Log(LG_RADIUS, ("[%s] RADIUS: %s: server says that the peer can choose an address", lnk->name, function)); auth->range.ipaddr.s_addr = 0; auth->range.width = 0; auth->range_valid = 1; } else if (strcmp(inet_ntoa(bund->radius.ip), "255.255.255.254") == 0) { /* we should choose the ip */ Log(LG_RADIUS, ("[%s] RADIUS: %s: server says that we should choose an address", lnk->name, function)); auth->range_valid = 0; } else { /* or use IP from Radius-server */ Log(LG_RADIUS, ("[%s] RADIUS: %s: using this IP: %s", lnk->name, function, inet_ntoa(bund->radius.ip))); memcpy(&auth->range.ipaddr, &bund->radius.ip, sizeof(struct in_addr)); auth->range_valid = 1; auth->range.width = 32; } } } int RadStat(int ac, char *av[], void *arg) { RadConf const conf = &bund->radius.conf; RadServe_Conf server; int i; printf("\tTimeout : %d\n", conf->radius_timeout); printf("\tRetries : %d\n", conf->radius_retries); printf("\tConfig-file : %s\n", conf->file); if (conf->server != NULL) { server = conf->server; i = 1; while (server) { printf("\t--------------- Radius Server %d ---------------\n", i); printf("\thostname : %s\n", server->hostname); printf("\tsecret : *********\n"); printf("\tauth port : %d\n", server->auth_port); printf("\tacct port : %d\n", server->acct_port); i++; server = server->next; } } printf("\t--------------- Radius Data ---------------\n"); printf("\tAuthname : %s\n", bund->radius.authname); printf("\tIP : %s\n", inet_ntoa(bund->radius.ip)); printf("\tMASK : %s\n", inet_ntoa(bund->radius.mask)); printf("\tMTU : %lu\n", bund->radius.mtu); printf("\tSessiontimeout : %lu\n", bund->radius.sessiontime); printf("\tVJ : %d\n", bund->radius.vj); printf("\tMPPE Types : %s\n", RadiusMPPETypesname(bund->radius.mppe.types)); printf("\tMPPE Policy : %s\n", RadiusMPPEPolicyname(bund->radius.mppe.policy)); return (0); } /* This algorithm was been taken from userland-ppp */ /* For exact description see RFC2548 */ static void RadiusMPPEExtractKey(const void *mangled, size_t mlen, u_char *buf, size_t *len) { char function[] = "RadiusExtractMPPEKey"; char R[AUTH_LEN]; /* variable names as per rfc2548 */ const char *S; u_char b[16]; const u_char *A, *C; MD5_CTX Context; int Slen, i, Clen, Ppos; u_char *P; if (mlen % 16 != SALT_LEN) { Log(LG_RADIUS, ("[%s] RADIUS: %s: Cannot interpret mangled data of length %ld", lnk->name, function, (u_long)mlen)); buf = NULL; *len = 0; return; } /* We need the RADIUS Request-Authenticator */ if (rad_request_authenticator(bund->radius.radh, R, sizeof R) != AUTH_LEN) { Log(LG_RADIUS, ("[%s] RADIUS: %s: Cannot obtain the RADIUS request authenticator", lnk->name, function)); buf = NULL; *len = 0; return; } A = (const u_char *)mangled; /* Salt comes first */ C = (const u_char *)mangled + SALT_LEN; /* Then the ciphertext */ Clen = mlen - SALT_LEN; S = rad_server_secret(bund->radius.radh); /* We need the RADIUS secret */ Slen = strlen(S); P = alloca(Clen); /* We derive our plaintext */ MD5Init(&Context); MD5Update(&Context, S, Slen); MD5Update(&Context, R, AUTH_LEN); MD5Update(&Context, A, SALT_LEN); MD5Final(b, &Context); Ppos = 0; while (Clen) { Clen -= 16; for (i = 0; i < 16; i++) P[Ppos++] = C[i] ^ b[i]; if (Clen) { MD5Init(&Context); MD5Update(&Context, S, Slen); MD5Update(&Context, C, 16); MD5Final(b, &Context); } C += 16; } /* * The resulting plain text consists of a one-byte length, the text and * maybe some padding. */ *len = *P; if (*len > mlen - 1) { Log(LG_RADIUS, ("[%s] RADIUS %s: Mangled data seems to be garbage %d %d", lnk->name, function, *len, mlen-1)); buf = NULL; *len = 0; return; } if (*len > MPPE_KEY_LEN) { Log(LG_RADIUS, ("[%s] RADIUS %s: Key to long (%d) for me max. %d", lnk->name, function, *len, MPPE_KEY_LEN)); buf = NULL; *len = 0; return; } memcpy(buf, P + 1, *len); } static const char * RadiusMPPEPolicyname(int policy) { switch(policy) { case MPPE_POLICY_ALLOWED: return "Allowed"; case MPPE_POLICY_REQUIRED: return "Required"; default: return "Unknown Policy"; } } static const char * RadiusMPPETypesname(int types) { static char res[30]; if (types == 0) { sprintf(res, "no encryption required"); return res; } if (types & MPPE_TYPE_40BIT) sprintf (res, "40 "); if (types & MPPE_TYPE_56BIT) sprintf (&res[strlen(res)], "56 "); if (types & MPPE_TYPE_128BIT) sprintf (&res[strlen(res)], "128 "); if (strlen(res) == 0) { sprintf (res, "unknown types"); } else { sprintf (&res[strlen(res)], "bit"); } return res; } --------------090203030406080803080701 Content-Type: text/plain; name="radius.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="radius.h" /* * radius.h * * Written by Brendan Bank * Copyright (c) Brendan Bank 2002 */ #include "ppp.h" #include "auth.h" #include "ccp_mppc.h" #include #ifndef _RADIUS_H_ #define _RADIUS_H_ #define RADIUS_CHAP 1 #define RADIUS_PAP 2 #define RADIUS_MAX_SERVERS 10 #define RAD_NACK 0 #define RAD_ACK 1 /* for mppe-keys */ #define AUTH_LEN 16 #define SALT_LEN 2 #define MPPE_POLICY_ALLOWED 1 #define MPPE_POLICY_REQUIRED 2 #define MPPE_TYPE_0BIT 0 /* No encryption required */ #define MPPE_TYPE_40BIT 2 #define MPPE_TYPE_128BIT 4 #define MPPE_TYPE_56BIT 8 /* * FUNCTIONS */ extern int RadiusAuthenticate(const char *name, const char *password, int passlen, const char *challenge, int challenge_size, u_char chapid, int auth_type); extern int RadiusPAPAuthenticate(const char *name, const char *password); extern int RadiusCHAPAuthenticate(const char *name, const char *password, int passlen, const char *challenge, int challenge_size, u_char chapid, int chap_type); extern int RadiusGetParams(void); extern void RadiusSetAuth(AuthData auth); extern const struct cmdtab RadiusSetCmds[]; extern int RadStat(int ac, char *av[], void *arg); struct radiusserver_conf { char *hostname; char *sharedsecret; int auth_port; int acct_port; struct radiusserver_conf *next; }; typedef struct radiusserver_conf *RadServe_Conf; /* Configuration for a radius server */ struct radiusconf { int radius_timeout; int radius_retries; char file[PATH_MAX]; struct radiusserver_conf *server; }; typedef struct radiusconf *RadConf; struct radius { struct rad_handle *radh; /* RadLib Handle */ short valid; /* Auth was successful */ char authname[AUTH_MAX_AUTHNAME]; unsigned vj : 1; /* FRAMED Compression */ struct in_addr ip; /* FRAMED IP */ struct in_addr mask; /* FRAMED Netmask */ unsigned long mtu; /* FRAMED MTU */ unsigned long sessiontime; /* Session-Timeout */ char *filterid; /* FRAMED Filter Id */ char *mschapv2resp; /* Response String for MSCHAPv2 */ struct { int policy; /* MPPE_POLICY_* */ int types; /* MPPE_TYPE_*BIT bitmask */ u_char recvkey[MPPE_KEY_LEN]; size_t recvkeylen; u_char sendkey[MPPE_KEY_LEN]; size_t sendkeylen; } mppe; struct radiusconf conf; }; struct chap_response { u_char ident; u_char response[CHAP_MAX_VAL]; }; struct mschap_response { u_char ident; u_char flags; u_char lm_response[24]; u_char nt_response[24]; }; struct mschapv2_response { u_char ident; u_char flags; u_char pchallenge[16]; u_char reserved[8]; u_char response[24]; }; #endif --------------090203030406080803080701-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 14:12:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB41037B401 for ; Sun, 3 Nov 2002 14:12:40 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9993643E42 for ; Sun, 3 Nov 2002 14:12:39 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gA3MCRYj065987 for ; Mon, 4 Nov 2002 00:12:31 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <03fe01c28386$186fed80$862a40c1@PHE> From: "Petri Helenius" To: Subject: bpf Date: Mon, 4 Nov 2002 00:12:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I believe the select operation on bpf is not functioning as supposed to. I´m calling select with 100ms timeout. The bpf interface is listening to an interface with constant packet rate, so it´s certain that multiple packets have been received during the select call. However the fd for the bpf device is not set until the bpf buffer is full. (which might be several seconds away since I´m using fairly large bpf buffers) Looking at the code I get the impression that if there are packets on the bpf buffer when the select timeouts, it should return the fd for the bpf ? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 14:54:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2F5B37B401 for ; Sun, 3 Nov 2002 14:54:08 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 324B343E7B for ; Sun, 3 Nov 2002 14:54:08 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gA3Ms25s028859; Sun, 3 Nov 2002 17:54:02 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gA3Ms2mV028858; Sun, 3 Nov 2002 17:54:02 -0500 (EST) Date: Sun, 3 Nov 2002 17:54:02 -0500 From: Barney Wolff To: Petri Helenius Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf Message-ID: <20021103225402.GA28812@tp.databus.com> References: <03fe01c28386$186fed80$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03fe01c28386$186fed80$862a40c1@PHE> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I believe you're misunderstanding the meaning of the timeout in select(2). Timeout applies only when no FDs are ready. Also, you might be better off setting immediate mode on your bpf fd, if you want a return before the buffer is full. On Mon, Nov 04, 2002 at 12:12:26AM +0200, Petri Helenius wrote: > > I believe the select operation on bpf is not functioning as supposed to. > I?m calling select with 100ms timeout. The bpf interface is listening to > an interface with constant packet rate, so it?s certain that multiple packets > have been received during the select call. However the fd for the bpf > device is not set until the bpf buffer is full. (which might be several seconds > away since I?m using fairly large bpf buffers) > > Looking at the code I get the impression that if there are packets on the bpf > buffer when the select timeouts, it should return the fd for the bpf ? > > Pete > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 16:35:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD03437B401 for ; Sun, 3 Nov 2002 16:35:37 -0800 (PST) Received: from mel-rto4.wanadoo.fr (smtp-out-4.wanadoo.fr [193.252.19.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id B246F43E42 for ; Sun, 3 Nov 2002 16:35:36 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto4.wanadoo.fr (6.5.007) id 3DA24D3200FEF2C8; Mon, 4 Nov 2002 01:35:24 +0100 Received: from there (217.128.206.98) by mel-rta8.wanadoo.fr (6.5.007) id 3DA24B4A00F924C1; Mon, 4 Nov 2002 01:35:24 +0100 Message-ID: <3DA24B4A00F924C1@mel-rta8.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: Michael Bretterklieber , freebsd-net@freebsd.org Subject: Re: mpd radius - request for review Date: Mon, 4 Nov 2002 01:52:06 +0100 X-Mailer: KMail [version 1.3.2] Cc: Brendan Bank References: <3DC53410.8000602@inode.at> In-Reply-To: <3DC53410.8000602@inode.at> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have not tested your code yet. However, according to me the radius code should be into link.c and not bund.c For example, it is important in order to support the accounting of the multilink ppp sessions, isn'it ? Vincent Le Dimanche 3 Novembre 2002 15:34, Michael Bretterklieber a écrit : > Hi, > > now I finished the work for radius-mpd-integration. > > It would be great if my code will be reviewed and integrated into > "official" mpd. > If there are any bugs or dirty hacks in my code, then let me know. > > I tested the code successfuly against freeradius and Microsoft Radius > (Windows 2000). > All auth-types are supported (pap, chap-md5, mschap v1 and mschap v2), > also mppe works. > > Here are the new config-params: > > set radius config /etc/radius.conf > or > set radius retries 3 > set radius timeout 3 > set radius server localhost testing123 > => configures radius (thanks to Brendan Bank). > > set bundle enable radius-auth => enables Radius Auth > set bundle enable radius-fallback => enables fallback to mpd.secret if > radius-auth not succeeded > > set ipcp enable radius-ip => let the radius-server assign the ip for the > user > > with "show radius" all radius-related params are printed out. > > After the code has being integrated into mpd I would like continue > implementing more features: > - MPPE Types and Policy > - Let mpd use other radius-params. > - Accounting > > If the code is to bad for integration into mpd, no problem, because then > it was only a good exercise for me. > > I attached the patches and also 2 new files for mpd 3.10. > > > bye, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 19:39:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A303D37B401 for ; Sun, 3 Nov 2002 19:39:29 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E6143E4A for ; Sun, 3 Nov 2002 19:39:29 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.3/8.12.3) with ESMTP id gA43dNAh034821; Sun, 3 Nov 2002 19:39:23 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.3/8.12.3/Submit) id gA43dNmN034820; Sun, 3 Nov 2002 19:39:23 -0800 (PST) (envelope-from rizzo) Date: Sun, 3 Nov 2002 19:39:23 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: fragmentation issues Message-ID: <20021103193923.A34675@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, a colleague pointed out the following problem: the various forms of encapsulation of IP traffic might result in IP datagrams which are larger than the IP maximum datagram length (64k). The problem arises with the various IP-in-IP encapsulations (gif, maybe faith), with IPSEC, and with some multicast processing. I guess the correct way to solve the problem is to do some form of fragmentation _before_ adding the new header to the packet. This requires the replication of some code which is in ip_output(). So i was wondering if there objections if in the long term i pull out the fragmentation code from ip_output and put it into a separate procedure that can be used wherever is required without having to replicate the code (and maintain it). comments ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 20: 0:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D85737B401 for ; Sun, 3 Nov 2002 20:00:14 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF4943E42 for ; Sun, 3 Nov 2002 20:00:13 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA60093; Sun, 3 Nov 2002 19:46:55 -0800 (PST) Date: Sun, 3 Nov 2002 19:46:54 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: fragmentation issues In-Reply-To: <20021103193923.A34675@xorpc.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 3 Nov 2002, Luigi Rizzo wrote: > Hi, > a colleague pointed out the following problem: the various > forms of encapsulation of IP traffic might result in IP > datagrams which are larger than the IP maximum datagram > length (64k). > > The problem arises with the various IP-in-IP encapsulations > (gif, maybe faith), with IPSEC, and with some multicast > processing. > yes I have: tcp/udp in ip in ppp in udp in esp in ip in my applications.. I ended up having to set the MTU of the tunnel interfaces down to about 1400 bytes so that the final packet could get into the 1500 byte ethernet frame neeed to get to the router to the Internet. (mtu discovery then reduced the path mtu and everything is cool) > I guess the correct way to solve the problem is to do > some form of fragmentation _before_ adding the new > header to the packet. This requires the replication of > some code which is in ip_output(). > > So i was wondering if there objections if in the long > term i pull out the fragmentation code from ip_output > and put it into a separate procedure that can be used > wherever is required without having to replicate the > code (and maintain it). > > comments ? > seems reasonable. Well see how practical it is when you try do it :-) > cheers > luigi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Nov 3 20:37:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82FD037B401 for ; Sun, 3 Nov 2002 20:37:24 -0800 (PST) Received: from mail.smashpow.com (mail.smashpow.net [216.235.9.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 612A543E3B for ; Sun, 3 Nov 2002 20:37:23 -0800 (PST) (envelope-from drek@smashpow.net) Received: from mail.smashpow.net (mail.smashpow.net [216.235.9.194]) by mail.smashpow.com (Postfix) with ESMTP id A9C5722C for ; Sun, 3 Nov 2002 23:37:16 -0500 (EST) Date: Sun, 3 Nov 2002 23:37:16 -0500 (EST) From: Agent Drek To: net@freebsd.org Subject: MTU problems ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, I'll start this off by claiming ignorance about the deep inner workings of tcp/ip. As such, this is not going to be a really technically detailed report. I will be more than happy to provide any info that might help in tracking this problem down though! The problem manifests as large downloads hanging (ftp/http/scp). The only way to make a download work is to choose an MTU setting on tun0 (this is a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find a value (1452, 1460, most things work at 1492 though) that makes the download complete properly. Sometimes finding an MTU that works is just not possible. The only icmp rule in ipfw is to allow all icmp so I am not unwittingly disallowing anything important. Could this thread be related to my problem? and was there any resolution with this? http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net According to my ISP (and a few other ISP's in the area) only FreeBSD systems and certain IOS versions are experiencing this problem. What can I do to start debugging this? Please CC me as I am not subscribed to net@. cheers, -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 4:35:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9AC337B401 for ; Mon, 4 Nov 2002 04:35:33 -0800 (PST) Received: from hotmail.com (f32.law15.hotmail.com [64.4.23.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2EDF43E6E for ; Mon, 4 Nov 2002 04:35:33 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Nov 2002 04:35:28 -0800 Received: from 217.218.77.5 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 04 Nov 2002 12:35:28 GMT X-Originating-IP: [217.218.77.5] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: IN-KERNEL Proxy Date: Mon, 04 Nov 2002 12:35:28 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Nov 2002 12:35:28.0504 (UTC) FILETIME=[A81A8F80:01C283FE] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list i want to know if there is any in-kernel made proxy on BSD ??? THANX _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 5:36:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FA5437B401 for ; Mon, 4 Nov 2002 05:36:57 -0800 (PST) Received: from musique.teaser.net (musique.teaser.net [213.91.2.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61BEE43E3B for ; Mon, 4 Nov 2002 05:36:56 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from notbsdems.nantes.kisoft-services.com (d42-122.ppp.teaser.fr [213.91.42.122]) by musique.teaser.net (Postfix) with ESMTP id 9CB3E72545; Mon, 4 Nov 2002 14:36:41 +0100 (CET) Received: by notbsdems.nantes.kisoft-services.com (Postfix, from userid 1001) id D320C5B473; Sun, 3 Nov 2002 18:00:35 +0100 (CET) To: Julian Elischer Cc: Mailing List FreeBSD Network Subject: Re: FEC : ng_fec & ng_one2many References: From: Eric Masson In-Reply-To: (Julian Elischer's message of "Tue, 29 Oct 2002 11:16:24 -0800 (PST)") X-Operating-System: FreeBSD 4.6-STABLE i386 Date: Sun, 03 Nov 2002 18:00:35 +0100 Message-ID: <86pttm8u6k.fsf@notbsdems.nantes.kisoft-services.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Common Lisp, i386--freebsd) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> "Julian" == Julian Elischer writes: Hello, (Sorry for replying late) Julian> I have committed it to 5.0 I will do 4.x in a day or so.. Thanks a lot, Julian> do you use it? I plan to use it on a box with a dfe570 (quad port ethernet), as soon as it's possible for me to get at the office where the box is located (Real Work overhead at the moment). Julian> it needs someone to write a man page.. Never done that before, but I could take a look. Eric Masson -- hier j ai sans le vouloirs j'ai envoyé un virus sur Internet qu'une personne mal intentionné m'avez donné pour tous . je leurs demande de m'excuser -+- RP in : GNU - Le retour du fils de la vengeance d'Henry -+- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 6:11:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EDFF37B401 for ; Mon, 4 Nov 2002 06:11:15 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59BF243E6E for ; Mon, 4 Nov 2002 06:11:12 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 188hwT-000NNT-00 for freebsd-net@freebsd.org; Mon, 04 Nov 2002 16:11:01 +0200 Date: Mon, 4 Nov 2002 16:11:01 +0200 (EET) From: Iasen Kostov To: freebsd-net@freebsd.org Subject: mbufs exhausted - kernel panic Message-ID: <20021104153320.L76062-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've tested our LAN when I come to this: I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing "All mbufs exhausted, see tuning(7)". if you cancel execution of nbtscan - everything is ok but: 10112/10112/10112 mbufs in use (current/peak/max): 9822 mbufs allocated to data 128/130/2528 mbuf clusters in use (current/peak/max) 2788 Kbytes allocated to network (36% of mb_map in use) 161 requests for memory denied 0 requests for memory delayed 8 calls to protocol drain routines and second after kernel paniced. After reboot tried this again and nothing has happend. Then I mounted a NFS directory exported from the other computer on the network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced when I execute "ls" in the NFS mounted directory. Fatal trap 12: page fault while in kernel mode . . . current process = 272(ls) ... I can't use this machine for dumping kernel core becouse it's production server it should be up and running. But I'll try same at home. It seems that kernel mbuf are exhausted by the route cache or the arpresolver becouse I can see a lot of unresolved arp requests in the routing table. interface xl0 has 2 IPs inet 212.36.9.x netmask 0xfffffff8 broadcast 212.36.9.x inet 192.168.100.254 netmask 0xffff0000 broadcast 192.168.255.255 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 6:41:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2118337B401 for ; Mon, 4 Nov 2002 06:41:27 -0800 (PST) Received: from ene.asda.gr (ene.asda.gr [193.92.118.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3D6A43E42 for ; Mon, 4 Nov 2002 06:41:25 -0800 (PST) (envelope-from lefty@ene.asda.gr) Received: from ene.asda.gr (lefty.ene.asda.gr [193.92.118.162]) (authenticated bits=0) by ene.asda.gr (8.12.6/8.12.6) with ESMTP id gA4EfFIS040440; Mon, 4 Nov 2002 16:41:17 +0200 (EET) (envelope-from lefty@ene.asda.gr) Message-ID: <3DC68735.F2008CDA@ene.asda.gr> Date: Mon, 04 Nov 2002 16:41:57 +0200 From: Lefteris Tsintjelis X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,el MIME-Version: 1.0 To: Iasen Kostov Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbufs exhausted - kernel panic References: <20021104153320.L76062-100000@shadowhand.OTEL.net> Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You need to increase kern.ipc.nmbufs sysctl -w kern.ipc.nmbufs=... Iasen Kostov wrote: > > I've tested our LAN when I come to this: > I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing > > "All mbufs exhausted, see tuning(7)". > if you cancel execution of nbtscan - everything is ok but: > > 10112/10112/10112 mbufs in use (current/peak/max): > 9822 mbufs allocated to data > 128/130/2528 mbuf clusters in use (current/peak/max) > 2788 Kbytes allocated to network (36% of mb_map in use) > 161 requests for memory denied > 0 requests for memory delayed > 8 calls to protocol drain routines > > and second after kernel paniced. > After reboot tried this again and nothing has happend. > Then I mounted a NFS directory exported from the other computer on the > network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced > when I execute "ls" in the NFS mounted directory. > > Fatal trap 12: page fault while in kernel mode > . > . > . > current process = 272(ls) > ... > > I can't use this machine for dumping kernel core becouse it's > production server it should be up and running. But I'll try same at home. > > It seems that kernel mbuf are exhausted by the route cache or the > arpresolver becouse I can see a lot of unresolved arp requests in the > routing table. > > interface xl0 has 2 IPs > inet 212.36.9.x netmask 0xfffffff8 broadcast 212.36.9.x > inet 192.168.100.254 netmask 0xffff0000 broadcast 192.168.255.255 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 7:19:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A85237B401 for ; Mon, 4 Nov 2002 07:19:11 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB1C43E6E for ; Mon, 4 Nov 2002 07:19:10 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 188j0G-000OeZ-00; Mon, 04 Nov 2002 17:19:00 +0200 Date: Mon, 4 Nov 2002 17:19:00 +0200 (EET) From: Iasen Kostov To: Lefteris Tsintjelis Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbufs exhausted - kernel panic In-Reply-To: <3DC68735.F2008CDA@ene.asda.gr> Message-ID: <20021104165903.F76062-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't think that it will help - all 192.168.0.0/16 routes could possibly exhaust whole my RAM - besides kern.ipc.nmbufs is read-only :) and could be set only at boot time or in kernel config. But I think the problem here is in NFS client code in nfsm_reqh() (I've compiled DDB in the kernel) which is called from nfs_lookup and so on ... Mbufs exhaustion is just condition for this panic as I saw. On Mon, 4 Nov 2002, Lefteris Tsintjelis wrote: > You need to increase kern.ipc.nmbufs > > sysctl -w kern.ipc.nmbufs=... > > Iasen Kostov wrote: > > > > I've tested our LAN when I come to this: > > I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing > > > > "All mbufs exhausted, see tuning(7)". > > if you cancel execution of nbtscan - everything is ok but: > > > > 10112/10112/10112 mbufs in use (current/peak/max): > > 9822 mbufs allocated to data > > 128/130/2528 mbuf clusters in use (current/peak/max) > > 2788 Kbytes allocated to network (36% of mb_map in use) > > 161 requests for memory denied > > 0 requests for memory delayed > > 8 calls to protocol drain routines > > > > and second after kernel paniced. > > After reboot tried this again and nothing has happend. > > Then I mounted a NFS directory exported from the other computer on the > > network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced > > when I execute "ls" in the NFS mounted directory. > > > > Fatal trap 12: page fault while in kernel mode > > . > > . > > . > > current process = 272(ls) > > ... > > > > I can't use this machine for dumping kernel core becouse it's > > production server it should be up and running. But I'll try same at home. > > > > It seems that kernel mbuf are exhausted by the route cache or the > > arpresolver becouse I can see a lot of unresolved arp requests in the > > routing table. > > > > interface xl0 has 2 IPs > > inet 212.36.9.x netmask 0xfffffff8 broadcast 212.36.9.x > > inet 192.168.100.254 netmask 0xffff0000 broadcast 192.168.255.255 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 8:47:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C93837B401 for ; Mon, 4 Nov 2002 08:47:23 -0800 (PST) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id E755543E3B for ; Mon, 4 Nov 2002 08:47:21 -0800 (PST) (envelope-from darcy@wavefire.com) Received: (qmail 10393 invoked from network); 4 Nov 2002 17:12:41 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 4 Nov 2002 17:12:41 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: "soheil soheil" Subject: Re: IN-KERNEL Proxy Date: Mon, 4 Nov 2002 08:46:49 -0800 User-Agent: KMail/1.4.3 References: In-Reply-To: Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211040846.49228.darcy@wavefire.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you mean in terms of transparently forward/redirecting packets then ye= s,=20 see ipfw's fwd feature. On Monday 04 November 2002 04:35, soheil soheil wrote: > Hi list > i want to know if there is any in-kernel made proxy on BSD ??? > THANX > > > _________________________________________________________________ > Broadband? Dial-up? Get reliable MSN Internet Access. > http://resourcecenter.msn.com/access/plans/default.asp > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 8:59:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6F9937B401 for ; Mon, 4 Nov 2002 08:59:10 -0800 (PST) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 289F743E6E for ; Mon, 4 Nov 2002 08:59:10 -0800 (PST) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 439; Mon, 4 Nov 2002 08:59:03 -0800 Message-ID: <3DC6A7BF.7010209@expertcity.com> Date: Mon, 04 Nov 2002 09:00:47 -0800 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Agent Drek Cc: net@freebsd.org Subject: Re: MTU problems ... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The problem below (which is still a problem in FreeBSD, but one that will be rarely encountered) was caused by a load balancer in front of the BSD boxes, that did not NAT part of the ICMP unreachable message payload to the BSD's address. (The ICMP includes part of the original datagram that caused the problem, and the load balancer did not translate the sequence numbers, I think.) Its still a BSD problem (I'd say) as if BSD hears the ICMP and reduces its MSS, it should not resend the original packet at a size > MSS. So this could be your issue if your ISP is forcing all your traffic through a proxy that does the same thing. A workaround would be disable PMTU-discovery. Agent Drek wrote: > hi, > > I'll start this off by claiming ignorance about the deep inner workings of > tcp/ip. As such, this is not going to be a really technically detailed > report. I will be more than happy to provide any info that might help in > tracking this problem down though! > > The problem manifests as large downloads hanging (ftp/http/scp). The only > way to make a download work is to choose an MTU setting on tun0 (this is > a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find > a value (1452, 1460, most things work at 1492 though) that makes the download > complete properly. Sometimes finding an MTU that works is just not possible. > The only icmp rule in ipfw is to allow all icmp so I am not unwittingly > disallowing anything important. > > Could this thread be related to my problem? and was there any resolution > with this? > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net > > According to my ISP (and a few other ISP's in the area) only FreeBSD systems > and certain IOS versions are experiencing this problem. > > What can I do to start debugging this? Please CC me as I am not subscribed > to net@. > > cheers, > > -- > Derek Marshall > > Smash and Pow Inc > 'digital plumber' > http://www.smashpow.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 10: 7:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5BC737B401 for ; Mon, 4 Nov 2002 10:07:39 -0800 (PST) Received: from mail.smashpow.com (mail.smashpow.net [216.235.9.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 296E843E3B for ; Mon, 4 Nov 2002 10:07:39 -0800 (PST) (envelope-from drek@smashpow.net) Received: from mail.smashpow.net (mail.smashpow.net [216.235.9.194]) by mail.smashpow.com (Postfix) with ESMTP id 0762B21A; Mon, 4 Nov 2002 13:07:38 -0500 (EST) Date: Mon, 4 Nov 2002 13:07:38 -0500 (EST) From: Agent Drek To: Steve Francis Cc: "net@freebsd.org" Subject: Re: MTU problems ... In-Reply-To: <3DC6A7BF.7010209@expertcity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 4 Nov 2002, Steve Francis wrote: > Date: Mon, 04 Nov 2002 09:00:47 -0800 > From: Steve Francis > To: Agent Drek > Cc: "net@freebsd.org" > Subject: Re: MTU problems ... > > The problem below (which is still a problem in FreeBSD, but one that > will be rarely encountered) was caused by a load balancer in front of > the BSD boxes, that did not NAT part of the ICMP unreachable message > payload to the BSD's address. (The ICMP includes part of the original > datagram that caused the problem, and the load balancer did not > translate the sequence numbers, I think.) Its still a BSD problem (I'd > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > the original packet at a size > MSS. > > So this could be your issue if your ISP is forcing all your traffic > through a proxy that does the same thing. > > A workaround would be disable PMTU-discovery. > hi, I didn't notice the pr until now: http://www.freebsd.org/cgi/query-pr.cgi?pr=42137 In my case the "load balancer" is something at the telco that is probably aggregating a bunch of stuff at the dslam. Thus I can't really fix the bad router, and there is no option of going somewhere else. I think I want something like: net.inet.tcp.stupid_router_in_front_of_me_mtu_hack->1 but that may not be what I need. Is it rude to send mail to that same pr? should I try and harvest more info first? disabling path mtu discovery just cause the problem to happen faster for me :( cheers, -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 10:15:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77DD137B401 for ; Mon, 4 Nov 2002 10:15:22 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87CB543E91 for ; Mon, 4 Nov 2002 10:15:20 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA27336; Mon, 4 Nov 2002 10:13:46 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA4IDOZE034244; Mon, 4 Nov 2002 10:13:24 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA4IDN7t034243; Mon, 4 Nov 2002 10:13:23 -0800 (PST) From: Archie Cobbs Message-Id: <200211041813.gA4IDN7t034243@arch20m.dellroad.org> Subject: Re: Win XP with mpd In-Reply-To: <004a01c2836a$b20c2e70$02020101@dimasic> "from Dmitry A. Bondareff at Nov 3, 2002 11:49:55 pm" To: "Dmitry A. Bondareff" Date: Mon, 4 Nov 2002 10:13:22 -0800 (PST) Cc: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dmitry A. Bondareff writes: > For a long time many peoples discussed why Win XP don't work with mpd. > May be you can help us ?? > Where I can find working configs ?? I've heard of some MTU problems, some of which mpd-3.10 should address. What's the specific problem you're having? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 10:22:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C7F837B401 for ; Mon, 4 Nov 2002 10:22:49 -0800 (PST) Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7671543E42 for ; Mon, 4 Nov 2002 10:22:48 -0800 (PST) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by sheffield.cnchost.com id NAA21028; Mon, 4 Nov 2002 13:22:45 -0500 (EST) [ConcentricHost SMTP Relay 1.15] Message-ID: <200211041822.NAA21028@sheffield.cnchost.com> To: Fran.Lawas-Grodek@grc.nasa.gov Cc: Cindy.Tran@grc.nasa.gov, freebsd-net@FreeBSD.ORG, Mark.Allman@grc.nasa.gov Subject: Re: Problem in High Speed and Long Delay with FreeBSD In-reply-to: Your message of "Fri, 01 Nov 2002 11:20:01 EST." <20021101112001.E3259@grc.nasa.gov> Date: Mon, 04 Nov 2002 10:22:44 -0800 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Your suggestion of increasing the -l seems to have made a positive > impact -- tests this morning with a higher buffer length size of 8192 > gave us a better throughput of 44Mbps. Now the time sequence plot > shows a window usage of 1.5MB as opposed to the previous 1MB usage. > > We still don't understand as to why we are not getting a larger > window usage when we are requesting a 3MB socket buffer. (BTW, > a typo in my example testing commands, left out a "0" in the > "-b".) Since *something* is making a difference, you may wish to try changing one independent parameter at a time. For instance, do you get different throughput numbers with -l = 16k, 32k, and so on? What is the limit? You will want to decrease the -n parameter correspondingly so as to not keep waiting longer and longer! Similarly try changing other limits one at a time. If you can, try to use the *same* non-FreeBSD machine at one end and characterize send and recv performance of FreeBSD separately. This ought to help you figure out where the bottleneck may be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 10:27:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1284C37B401 for ; Mon, 4 Nov 2002 10:27:14 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DAAB43E77 for ; Mon, 4 Nov 2002 10:27:08 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA4IOuAf018722; Mon, 4 Nov 2002 23:24:56 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from dimasic (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with SMTP id gA4IJlk26543; Mon, 4 Nov 2002 23:19:47 +0500 (ESK) Message-ID: <003b01c2842f$821b1ee0$02020101@dimasic> From: "Dmitry A. Bondareff" To: "Archie Cobbs" Cc: References: <200211041813.gA4IDN7t034243@arch20m.dellroad.org> Subject: Re: Win XP with mpd Date: Mon, 4 Nov 2002 23:25:07 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org When I used Win2000 client all works fine and fast. I've tested WinXp with mpd in two places. In one place do not work nothing. I see traffic on FreeBSD to Internet and from it, but on WinXP client no HTTP, no ICQ. And when i do telnet to some host I see answer from time to time. One time I see login: But after some seconds no answer. In the other place work fine HTTP from Explorer, but no ICQ. When I do in ICQ client "Auto configure ..." all fine and fast. But do not connecting. All firewalls I was set to ALLOW from ANY to ANY. With best regards, Dmitry. ----- Original Message ----- From: "Archie Cobbs" To: "Dmitry A. Bondareff" Cc: Sent: Monday, November 04, 2002 11:13 PM Subject: Re: Win XP with mpd > Dmitry A. Bondareff writes: > > For a long time many peoples discussed why Win XP don't work with mpd. > > May be you can help us ?? > > Where I can find working configs ?? > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > What's the specific problem you're having? > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 10:49:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F3BE37B401 for ; Mon, 4 Nov 2002 10:49:17 -0800 (PST) Received: from operax.com (aurorum84-0.aurorum.se [213.88.249.84]) by mx1.FreeBSD.org (Postfix) with SMTP id BDD1443E7B for ; Mon, 4 Nov 2002 10:49:15 -0800 (PST) (envelope-from johan.larsson@operax.com) Received: (qmail 99519 invoked by uid 0); 4 Nov 2002 18:49:08 -0000 Received: from treo.operax.com (192.168.1.2) by treo.operax.com with SMTP; 4 Nov 2002 18:49:08 -0000 Date: Mon, 4 Nov 2002 19:49:08 +0100 (CET) From: Johan Larsson X-X-Sender: johan@treo.operax.com To: Archie Cobbs Cc: "Dmitry A. Bondareff" , "freebsd-net@FreeBSD.org" Subject: Re: Win XP with mpd In-Reply-To: <200211041813.gA4IDN7t034243@arch20m.dellroad.org> Message-ID: <20021104193831.Y53733-100000@treo.operax.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 4 Nov 2002, Archie Cobbs wrote: > Dmitry A. Bondareff writes: > > For a long time many peoples discussed why Win XP don't work with mpd. > > May be you can help us ?? > > Where I can find working configs ?? > > I've heard of some MTU problems, some of which mpd-3.10 should address. It might be MTU problems. But the problem occurs for example when i ping the server from the windows xp machine, some pings get lost, some times you must issue the ping command a few times, or run it with -t for a while to see them get lost. mpd-3.10 does not solve this problem unfortunately. I might be able to fix some dumps (from ethereal) under windows xp if you want it. And of course, these pings getting lost is just an easy way of seeing the problem, you also get poor performance obviously. > > What's the specific problem you're having? > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- Johan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 11:15:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15B4F37B401 for ; Mon, 4 Nov 2002 11:15:22 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 572E543E3B for ; Mon, 4 Nov 2002 11:15:21 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA27686; Mon, 4 Nov 2002 11:04:22 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA4J41ZE034477; Mon, 4 Nov 2002 11:04:01 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA4J41fp034476; Mon, 4 Nov 2002 11:04:01 -0800 (PST) From: Archie Cobbs Message-Id: <200211041904.gA4J41fp034476@arch20m.dellroad.org> Subject: Re: Win XP with mpd In-Reply-To: <20021104193831.Y53733-100000@treo.operax.com> "from Johan Larsson at Nov 4, 2002 07:49:08 pm" To: Johan Larsson Date: Mon, 4 Nov 2002 11:04:01 -0800 (PST) Cc: Archie Cobbs , "Dmitry A. Bondareff" , "freebsd-net@FreeBSD.org" X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Johan Larsson writes: > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > May be you can help us ?? > > > Where I can find working configs ?? > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > It might be MTU problems. But the problem occurs for example when i ping > the server from the windows xp machine, some pings get lost, some times > you must issue the ping command a few times, or run it with -t for a while > to see them get lost. mpd-3.10 does not solve this problem unfortunately. Try playing with the "set link mtu" and/or "set iface mtu" commands to manually set the MTU values. > I might be able to fix some dumps (from ethereal) under windows xp if you > want it. And of course, these pings getting lost is just an easy way of > seeing the problem, you also get poor performance obviously. If you can tell where the packets are being dropped, that would be useful to know. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 11:15:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78E1937B401 for ; Mon, 4 Nov 2002 11:15:38 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA78D43E3B for ; Mon, 4 Nov 2002 11:15:37 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA27682; Mon, 4 Nov 2002 11:03:16 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA4J2sZE034471; Mon, 4 Nov 2002 11:02:54 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA4J2sPw034470; Mon, 4 Nov 2002 11:02:54 -0800 (PST) From: Archie Cobbs Message-Id: <200211041902.gA4J2sPw034470@arch20m.dellroad.org> Subject: Re: Win XP with mpd In-Reply-To: <004801c28430$097cb6a0$62dca8c0@kpush> "from Murat Bicer at Nov 4, 2002 01:28:57 pm" To: Murat Bicer Date: Mon, 4 Nov 2002 11:02:54 -0800 (PST) Cc: "'Archie Cobbs'" , "'Dmitry A. Bondareff'" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Murat Bicer writes: > I also have some problems: > > I get Error 742: connection does not support required encryption type. What does the mpd log trace say when this happens? > And even weirder thing is, it works on some XP machines without any > problem. And on win2k it works fine too. > > My mpd.conf: > > pptp_client0: > # create the bundle "vpn0" with link "pptp1" > new -i ng0 vpn0 pptp0 > > # single link > set bundle yes multilink > set iface disable on-demand > set iface idle 1800 > > # do VJ compression > set ipcp yes vjcomp > > # require Microsoft encryption > set bundle yes crypt-reqd > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e56 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set link mtu 1490 > > set bundle yes compression > set ccp yes mpp-compress ^^^^^^^^^^^^^^^^^^^^^^^^ Don't use "set ccp yes mpp-compress". FreeBSD doesn't support MPPC compression. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 12: 0:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4A7137B401 for ; Mon, 4 Nov 2002 12:00:26 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5707C43E42 for ; Mon, 4 Nov 2002 12:00:26 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA63771; Mon, 4 Nov 2002 11:56:35 -0800 (PST) Date: Mon, 4 Nov 2002 11:56:33 -0800 (PST) From: Julian Elischer To: Agent Drek Cc: Steve Francis , "net@freebsd.org" Subject: Re: MTU problems ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org There is a program that intercepts tcp session negotiation and artificially reduces the negotiated MTU but I can't find it right now.. I think it was called mssd or something. On Mon, 4 Nov 2002, Agent Drek wrote: > On Mon, 4 Nov 2002, Steve Francis wrote: > > > Date: Mon, 04 Nov 2002 09:00:47 -0800 > > From: Steve Francis > > To: Agent Drek > > Cc: "net@freebsd.org" > > Subject: Re: MTU problems ... > > > > The problem below (which is still a problem in FreeBSD, but one that > > will be rarely encountered) was caused by a load balancer in front of > > the BSD boxes, that did not NAT part of the ICMP unreachable message > > payload to the BSD's address. (The ICMP includes part of the original > > datagram that caused the problem, and the load balancer did not > > translate the sequence numbers, I think.) Its still a BSD problem (I'd > > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > > the original packet at a size > MSS. > > > > So this could be your issue if your ISP is forcing all your traffic > > through a proxy that does the same thing. > > > > A workaround would be disable PMTU-discovery. > > > > hi, > > I didn't notice the pr until now: > http://www.freebsd.org/cgi/query-pr.cgi?pr=42137 > > In my case the "load balancer" is something at the telco that is probably > aggregating a bunch of stuff at the dslam. Thus I can't really fix the > bad router, and there is no option of going somewhere else. > > I think I want something like: > > net.inet.tcp.stupid_router_in_front_of_me_mtu_hack->1 > > but that may not be what I need. Is it rude to send mail to that same > pr? should I try and harvest more info first? > > disabling path mtu discovery just cause the problem to happen faster > for me :( > > cheers, > > -- > Derek Marshall > > Smash and Pow Inc > 'digital plumber' > http://www.smashpow.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 12:10:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3334D37B401 for ; Mon, 4 Nov 2002 12:10:29 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id A73BC43E42 for ; Mon, 4 Nov 2002 12:10:28 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VVGQ>; Mon, 4 Nov 2002 15:10:23 -0500 Message-ID: From: Don Bowman To: 'Julian Elischer' , Agent Drek Cc: Steve Francis , net@freebsd.org Subject: RE: MTU problems ... Date: Mon, 4 Nov 2002 15:10:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: Julian Elischer [mailto:julian@elischer.org] > There is a program that intercepts tcp session negotiation and > artificially reduces the negotiated MTU but I can't find it > right now.. > I think it was called mssd or something. /usr/ports/net/tcpmssd --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 12:20:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C840A37B401 for ; Mon, 4 Nov 2002 12:20:23 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B608543E4A for ; Mon, 4 Nov 2002 12:20:22 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA63904; Mon, 4 Nov 2002 12:20:05 -0800 (PST) Date: Mon, 4 Nov 2002 12:20:03 -0800 (PST) From: Julian Elischer To: Don Bowman Cc: Agent Drek , Steve Francis , net@freebsd.org Subject: RE: MTU problems ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 4 Nov 2002, Don Bowman wrote: > > From: Julian Elischer [mailto:julian@elischer.org] > > There is a program that intercepts tcp session negotiation and > > artificially reduces the negotiated MTU but I can't find it > > right now.. > > I think it was called mssd or something. > > /usr/ports/net/tcpmssd err yeah, thanks.. > > --don (don@sandvine.com www.sandvine.com) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 12:40:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2390F37B401 for ; Mon, 4 Nov 2002 12:40:12 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98AC743E6E for ; Mon, 4 Nov 2002 12:40:11 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA63954; Mon, 4 Nov 2002 12:27:04 -0800 (PST) Date: Mon, 4 Nov 2002 12:27:03 -0800 (PST) From: Julian Elischer To: Steve Francis Cc: Agent Drek , net@freebsd.org Subject: Re: MTU problems ... In-Reply-To: <3DC6A7BF.7010209@expertcity.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 4 Nov 2002, Steve Francis wrote: > The problem below (which is still a problem in FreeBSD, but one that > will be rarely encountered) was caused by a load balancer in front of > the BSD boxes, that did not NAT part of the ICMP unreachable message > payload to the BSD's address. (The ICMP includes part of the original > datagram that caused the problem, and the load balancer did not > translate the sequence numbers, I think.) Its still a BSD problem (I'd > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > the original packet at a size > MSS. > > So this could be your issue if your ISP is forcing all your traffic > through a proxy that does the same thing. > > A workaround would be disable PMTU-discovery. > > > Agent Drek wrote: > > hi, > > > > I'll start this off by claiming ignorance about the deep inner workings of > > tcp/ip. As such, this is not going to be a really technically detailed > > report. I will be more than happy to provide any info that might help in > > tracking this problem down though! > > > > The problem manifests as large downloads hanging (ftp/http/scp). The only > > way to make a download work is to choose an MTU setting on tun0 (this is > > a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find > > a value (1452, 1460, most things work at 1492 though) that makes the download > > complete properly. Sometimes finding an MTU that works is just not possible. > > The only icmp rule in ipfw is to allow all icmp so I am not unwittingly > > disallowing anything important. > > > > Could this thread be related to my problem? and was there any resolution > > with this? > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net > > > > According to my ISP (and a few other ISP's in the area) only FreeBSD systems > > and certain IOS versions are experiencing this problem. > > > > What can I do to start debugging this? Please CC me as I am not subscribed > > to net@. > > > > cheers, > > TCPMSSD(8) FreeBSD System Manager's Manual TCPMSSD(8) NAME tcpmssd - TCP Maximum Segment Size option corrector SYNOPSIS tcpmssd [-v] -p port {-i iface | -m mtu} DESCRIPTION tcpmssd is a program that adjusts outgoing TCP SYN packets so that the maximum receive segment size is not greater than the amount allowed by the interface MTU. This is necessary in many setups to avoid problems caused by routers that drop ICMP ``Datagram Too Big'' messages, thus breaking Path MTU discovery algorithm (RFC 1191). Without these messages, the originating machine sends data, it passes the rogue router then hits a machine that has an MTU that is not big enough for the data. Because the IP ``don't fragment'' option is set, this machine sends an ICMP ``Datagram Too Big'' message back to the originator and drops the packet. The rogue router drops the ICMP and the originator never gets to discover that it must reduce the Path MTU value or exclude the IP ``don't fragment'' option from its outgoing data. tcpmssd normally runs in the background as a daemon. It intercept TCP packets from a divert(4) socket bound to the port specified with the -p option and reduces the value of TCP MSS option if necessary so that the incoming TCP messages will pass through this host without need to send ICMP ``Datagram Too Big'' messages. The maximum value for the TCP MSS option is determined based on a MTU given either as an absolute value with the -m option or derived from a network interface specified with the -i option. If run with the -v option, tcpmssd does not detach from its controlling terminal and writes various diagnostic messages to the standard error output. The following steps are necessary to run tcpmssd : 1. Build your kernel with the following options: options IPFIREWALL options IPDIVERT Refer to the Handbook for detailed instructions on building a custom kernel. 2. Make sure to redirect TCP traffic to the divert(4) port port. Refer to the ipfw(8) manual page for details. SEE ALSO divert(4), ipfw(8). AUTHORS This program was written by Ruslan Ermilov based on work done by Patrick Bihan-Faou . FreeBSD July 17, 2000 FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 13: 3:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E54C37B401 for ; Mon, 4 Nov 2002 13:03:13 -0800 (PST) Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF45143E4A for ; Mon, 4 Nov 2002 13:03:12 -0800 (PST) (envelope-from vjardin@wanadoo.fr) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto3.wanadoo.fr (6.5.007) id 3DA24D1801089F57 for net@freebsd.org; Mon, 4 Nov 2002 22:03:10 +0100 Received: from there (217.128.206.98) by mel-rta7.wanadoo.fr (6.5.007) id 3DA24BE600FF3EA2 for net@freebsd.org; Mon, 4 Nov 2002 22:03:10 +0100 Message-ID: <3DA24BE600FF3EA2@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: net@freebsd.org Subject: MPD and MRU Date: Mon, 4 Nov 2002 22:19:54 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, It looks like it is not possible to configure any MRU values with MPD, due to LCP_MRU_MARGIN (=20). For example, on the PPPoE links, the values between 1473 to 1491 are not possible. ... link.c: case SET_MRU: case SET_MTU: val = atoi(*av); name = ((intptr_t)arg == SET_MTU) ? "MTU" : "MRU"; if (!lnk->phys->type) Log(LG_ERR, ("[%s] this link has no type set", lnk->name)); else if (val < LCP_MIN_MRU) Log(LG_ERR, ("[%s] the min %s is %d", lnk->name, name, LCP_MIN_MRU)); else if (val + LCP_MRU_MARGIN > lnk->phys->type->mru) Log(LG_ERR, ("[%s] the max %s on type \"%s\" links is %d", lnk->name, name, lnk->phys->type->name, lnk->phys->type->mru - LCP_MRU_MARGIN)); /* XXXXXXXXXX */ else if ((intptr_t)arg == SET_MTU) lnk->conf.mtu = val; else lnk->conf.mru = val; break; ... I think that the LCP_MRU_MARGIN tests could be removed or LCP_MRU_MARGIN could be set to 0. Regards, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 15: 0: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E96237B401 for ; Mon, 4 Nov 2002 15:00:06 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C829343E42 for ; Mon, 4 Nov 2002 15:00:05 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA29056; Mon, 4 Nov 2002 14:56:38 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA4MuHZE035382; Mon, 4 Nov 2002 14:56:17 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA4MuH5k035381; Mon, 4 Nov 2002 14:56:17 -0800 (PST) From: Archie Cobbs Message-Id: <200211042256.gA4MuH5k035381@arch20m.dellroad.org> Subject: Re: MPD and MRU In-Reply-To: <3DA24BE600FF3EA2@mel-rta7.wanadoo.fr> (added by postmaster@wanadoo.fr) "from Vincent Jardin at Nov 4, 2002 10:19:54 pm" To: Vincent Jardin Date: Mon, 4 Nov 2002 14:56:17 -0800 (PST) Cc: net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Vincent Jardin writes: > It looks like it is not possible to configure any MRU values with MPD, due to > LCP_MRU_MARGIN (=20). > > For example, on the PPPoE links, the values between 1473 to 1491 are not > possible. > > ... > link.c: > case SET_MRU: > case SET_MTU: > val = atoi(*av); > name = ((intptr_t)arg == SET_MTU) ? "MTU" : "MRU"; > if (!lnk->phys->type) > Log(LG_ERR, ("[%s] this link has no type set", lnk->name)); > else if (val < LCP_MIN_MRU) > Log(LG_ERR, ("[%s] the min %s is %d", lnk->name, name, LCP_MIN_MRU)); > else if (val + LCP_MRU_MARGIN > lnk->phys->type->mru) > Log(LG_ERR, ("[%s] the max %s on type \"%s\" links is %d", > lnk->name, name, lnk->phys->type->name, > lnk->phys->type->mru - LCP_MRU_MARGIN)); /* XXXXXXXXXX */ > else if ((intptr_t)arg == SET_MTU) > lnk->conf.mtu = val; > else > lnk->conf.mru = val; > break; > ... > > I think that the LCP_MRU_MARGIN tests could be removed or LCP_MRU_MARGIN > could be set to 0. Yes, you're right.. that's a hold-over kludge from before. I'll remove it in the next version. In the meantime, you can just redefine it to zero. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 18:40:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8CF937B401 for ; Mon, 4 Nov 2002 18:40:40 -0800 (PST) Received: from web10402.mail.yahoo.com (web10402.mail.yahoo.com [216.136.130.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 1425443E42 for ; Mon, 4 Nov 2002 18:40:40 -0800 (PST) (envelope-from opolyakov@yahoo.com) Message-ID: <20021105024040.68335.qmail@web10402.mail.yahoo.com> Received: from [67.112.212.200] by web10402.mail.yahoo.com via HTTP; Mon, 04 Nov 2002 18:40:40 PST Date: Mon, 4 Nov 2002 18:40:40 -0800 (PST) From: Oleg Polyakov Subject: Re: RFC 3390: Increasing TCP's Initial Window To: freebsd-net@freebsd.org, Jeffrey Hsu , Lars Eggert In-Reply-To: <0H4X004T7EFMU1@mta7.pltn13.pbi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Jeffrey Hsu wrote: > > Time to default net.inet.tcp.slowstart_flightsize to 4? > > A straight initial window of 4 is too big. I have patches lying around > that varies the initial window size from 2 to 4 depending on the MSS, > as specified in the RFC. > > Jeffrey We could not apply those patches until we fix a bug serverside which increments snd_cwnd with 1 mss somewhere... Server - CURRENT (source synced on Nov 02). Take a look on TCP session. There is local network and we should have initial window 4 mss. Notice how many packets it sent before first ACK came. 5 packets. 5 ck ~# sysctl net.inet.tcp.local_slowstart_flightsize net.inet.tcp.local_slowstart_flightsize: 4 6 ck ~# tcpdump port 80 tcpdump: listening on fxp0 18:57:28.854418 10.13.200.242.2356 > 10.13.200.240.http: S 2006596932:2006596932(0) win 16384 (DF) 18:57:28.854519 10.13.200.240.http > 10.13.200.242.2356: S 3851758649:3851758649(0) ack 2006596933 win 65535 (DF) 18:57:28.854698 10.13.200.242.2356 > 10.13.200.240.http: . ack 1 win 17520 (DF) 18:57:28.980517 10.13.200.242.2356 > 10.13.200.240.http: P 1:510(509) ack 1 win 17520 (DF) 18:57:28.981094 10.13.200.240.http > 10.13.200.242.2356: . 1:1461(1460) ack 510 win 65535 (DF) 18:57:28.981157 10.13.200.240.http > 10.13.200.242.2356: . 1461:2921(1460) ack 510 win 65535 (DF) 18:57:28.981216 10.13.200.240.http > 10.13.200.242.2356: . 2921:4381(1460) ack 510 win 65535 (DF) 18:57:28.981238 10.13.200.240.http > 10.13.200.242.2356: . 4381:5841(1460) ack 510 win 65535 (DF) 18:57:28.981287 10.13.200.240.http > 10.13.200.242.2356: . 5841:7301(1460) ack 510 win 65535 (DF) 18:57:28.981744 10.13.200.242.2356 > 10.13.200.240.http: . ack 2921 win 17520 (DF) 18:57:28.981822 10.13.200.240.http > 10.13.200.242.2356: FP 7301:7864(563) ack 510 win 65535 (DF) 18:57:28.981981 10.13.200.242.2356 > 10.13.200.240.http: . ack 5841 win 17520 (DF) 18:57:28.982171 10.13.200.242.2356 > 10.13.200.240.http: . ack 7865 win 17520 (DF) 18:57:29.102762 10.13.200.242.2356 > 10.13.200.240.http: F 510:510(0) ack 7865 win 17520 (DF) 18:57:29.102840 10.13.200.240.http > 10.13.200.242.2356: . ack 511 win 65535 (DF) ^C 1214 packets received by filter 0 packets dropped by kernel 7 ck ~# 7 ck ~# sysctl -w net.inet.tcp.local_slowstart_flightsize=1 net.inet.tcp.local_slowstart_flightsize: 4 -> 1 8 ck ~# tcpdump port 80 tcpdump: listening on fxp0 19:04:54.623558 10.13.200.242.2360 > 10.13.200.240.http: S 2118035397:2118035397(0) win 16384 (DF) 19:04:54.623657 10.13.200.240.http > 10.13.200.242.2360: S 1566520560:1566520560(0) ack 2118035398 win 65535 (DF) 19:04:54.623841 10.13.200.242.2360 > 10.13.200.240.http: . ack 1 win 17520 (DF) 19:04:54.767900 10.13.200.242.2360 > 10.13.200.240.http: P 1:510(509) ack 1 win 17520 (DF) 19:04:54.768484 10.13.200.240.http > 10.13.200.242.2360: . 1:1461(1460) ack 510 win 65535 (DF) 19:04:54.768545 10.13.200.240.http > 10.13.200.242.2360: . 1461:2921(1460) ack 510 win 65535 (DF) 19:04:54.769133 10.13.200.242.2360 > 10.13.200.240.http: . ack 2921 win 17520 (DF) 19:04:54.769218 10.13.200.240.http > 10.13.200.242.2360: . 2921:4381(1460) ack 510 win 65535 (DF) 19:04:54.769243 10.13.200.240.http > 10.13.200.242.2360: . 4381:5841(1460) ack 510 win 65535 (DF) 19:04:54.769267 10.13.200.240.http > 10.13.200.242.2360: . 5841:7301(1460) ack 510 win 65535 (DF) 19:04:54.769863 10.13.200.242.2360 > 10.13.200.240.http: . ack 5841 win 17520 (DF) 19:04:54.769927 10.13.200.240.http > 10.13.200.242.2360: FP 7301:7864(563) ack 510 win 65535 (DF) 19:04:54.770240 10.13.200.242.2360 > 10.13.200.240.http: . ack 7865 win 17520 (DF) 19:04:54.905359 10.13.200.242.2360 > 10.13.200.240.http: F 510:510(0) ack 7865 win 17520 (DF) 19:04:54.905438 10.13.200.240.http > 10.13.200.242.2360: . ack 511 win 65535 (DF) After I changed initial window size to 1 it started to send 2 packets before first ACK, then 3 packets before next ACK. Client side is working as supposed to. If I set net.inet.tcp.local_slowstart_flightsize to 1 it sends 1 packet before ACK. If I change it to 4 - it sends 4 packets before ACK. Please check it in your environment. I've got same results with 4.7 and 4.6 - same wrong TCP initial window. ---- Oleg __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 18:51: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFF8937B401 for ; Mon, 4 Nov 2002 18:51:08 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B1AE43E4A for ; Mon, 4 Nov 2002 18:51:08 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H5300HY7198ZX@mta6.snfc21.pbi.net> for freebsd-net@freebsd.org; Mon, 04 Nov 2002 18:51:08 -0800 (PST) Date: Mon, 04 Nov 2002 18:54:37 -0800 From: Jeffrey Hsu Subject: Re: RFC 3390: Increasing TCP's Initial Window In-reply-to: Message from Oleg Polyakov "of Mon, 04 Nov 2002 18:40:40 PST." <20021105024040.68335.qmail@web10402.mail.yahoo.com> To: Oleg Polyakov Cc: freebsd-net@freebsd.org Message-id: <0H5300HY8198ZX@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> I have patches lying around >> that varies the initial window size from 2 to 4 depending on the MSS, >> as specified in the RFC. > We could not apply those patches until we fix a bug serverside which > increments snd_cwnd with 1 mss somewhere... > Take a look on TCP session. No, no, I meant I wrote my own, which doesn't show this problem in the traces I've examined. But, it's all rolled up into a bunch of other congestion related stuff I'm still working on like SACK and, more importantly, Limited Transmit, exactly because all this stuff modifies and examines the same variables and so all the functionality has to be tested together to make sure no part breaks any other part. Jeffrey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 19: 6:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF97837B401 for ; Mon, 4 Nov 2002 19:06:44 -0800 (PST) Received: from mail.smashpow.com (mail.smashpow.net [216.235.9.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22BF643E42 for ; Mon, 4 Nov 2002 19:06:44 -0800 (PST) (envelope-from drek@smashpow.net) Received: from mail.smashpow.net (mail.smashpow.net [216.235.9.194]) by mail.smashpow.com (Postfix) with ESMTP id 02B2B22B; Mon, 4 Nov 2002 22:06:43 -0500 (EST) Date: Mon, 4 Nov 2002 22:06:43 -0500 (EST) From: Agent Drek To: Julian Elischer Cc: Steve Francis , "net@freebsd.org" Subject: Re: MTU problems ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org tcpmssd is working great! thanks a lot!!! -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 19:51:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE94337B401 for ; Mon, 4 Nov 2002 19:51:49 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B149D43E42 for ; Mon, 4 Nov 2002 19:51:47 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA53njAf021893; Tue, 5 Nov 2002 08:49:45 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gA53ick20692; Tue, 5 Nov 2002 08:44:38 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gA53nWS9034566; Tue, 5 Nov 2002 08:49:33 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <001b01c2847f$19002c70$02010101@wall> From: "Dmitry A. Bondareff" To: "Archie Cobbs" , "Johan Larsson" Cc: "freebsd-net@FreeBSD.org" References: <200211041904.gA4J41fp034476@arch20m.dellroad.org> Subject: Re: Win XP with mpd Date: Tue, 5 Nov 2002 08:54:51 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think that packets droped on the WinXP side. ----- Original Message ----- From: "Archie Cobbs" To: "Johan Larsson" Cc: "Archie Cobbs" ; "Dmitry A. Bondareff" ; "freebsd-net@FreeBSD.org" Sent: Tuesday, November 05, 2002 12:04 AM Subject: Re: Win XP with mpd > Johan Larsson writes: > > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > > May be you can help us ?? > > > > Where I can find working configs ?? > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > > > It might be MTU problems. But the problem occurs for example when i ping > > the server from the windows xp machine, some pings get lost, some times > > you must issue the ping command a few times, or run it with -t for a while > > to see them get lost. mpd-3.10 does not solve this problem unfortunately. > > Try playing with the "set link mtu" and/or "set iface mtu" commands > to manually set the MTU values. > > > I might be able to fix some dumps (from ethereal) under windows xp if you > > want it. And of course, these pings getting lost is just an easy way of > > seeing the problem, you also get poor performance obviously. > > If you can tell where the packets are being dropped, that would be useful > to know. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 21: 3:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C89EB37B401 for ; Mon, 4 Nov 2002 21:03:40 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A470A43E3B for ; Mon, 4 Nov 2002 21:03:38 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA551XAf022578; Tue, 5 Nov 2002 10:01:33 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gA54uP524237; Tue, 5 Nov 2002 09:56:25 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gA551KS9034851; Tue, 5 Nov 2002 10:01:20 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <00de01c28489$20ebb760$02010101@wall> From: "Dmitry A. Bondareff" To: "Archie Cobbs" , "Johan Larsson" Cc: "freebsd-net@FreeBSD.org" References: <200211041904.gA4J41fp034476@arch20m.dellroad.org> Subject: Re: Win XP with mpd Date: Tue, 5 Nov 2002 10:06:39 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'll trying to setup mtu to 1400, why I don't see it by ifconfig command ? From mpd.conf: .... set link mru 1400 set link mtu 1400 .... #mpd -b #ifconfig -a: ng0: flags=8890 mtu 1500 ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 After connecting: #ifconfig -a: ng0: flags=88d1 mtu 1500 inet 1.1.1.1 --> 10.0.2.1 netmask 0xffffffff ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 After disconnected: #ifconfig -a: ng0: flags=8890 mtu 1496 ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 ----- Original Message ----- From: "Archie Cobbs" To: "Johan Larsson" Cc: "Archie Cobbs" ; "Dmitry A. Bondareff" ; "freebsd-net@FreeBSD.org" Sent: Tuesday, November 05, 2002 12:04 AM Subject: Re: Win XP with mpd > Johan Larsson writes: > > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > > May be you can help us ?? > > > > Where I can find working configs ?? > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > > > It might be MTU problems. But the problem occurs for example when i ping > > the server from the windows xp machine, some pings get lost, some times > > you must issue the ping command a few times, or run it with -t for a while > > to see them get lost. mpd-3.10 does not solve this problem unfortunately. > > Try playing with the "set link mtu" and/or "set iface mtu" commands > to manually set the MTU values. > > > I might be able to fix some dumps (from ethereal) under windows xp if you > > want it. And of course, these pings getting lost is just an easy way of > > seeing the problem, you also get poor performance obviously. > > If you can tell where the packets are being dropped, that would be useful > to know. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 22:10: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC36937B404 for ; Mon, 4 Nov 2002 22:09:58 -0800 (PST) Received: from web10403.mail.yahoo.com (web10403.mail.yahoo.com [216.136.130.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 16AD443E6E for ; Mon, 4 Nov 2002 22:09:58 -0800 (PST) (envelope-from opolyakov@yahoo.com) Message-ID: <20021105060957.77055.qmail@web10403.mail.yahoo.com> Received: from [12.236.91.184] by web10403.mail.yahoo.com via HTTP; Mon, 04 Nov 2002 22:09:57 PST Date: Mon, 4 Nov 2002 22:09:57 -0800 (PST) From: Oleg Polyakov Subject: Re: RFC 3390: Increasing TCP's Initial Window To: freebsd-net@freebsd.org, hsu@FreeBSD.org Cc: freebsd-net@freebsd.org In-Reply-To: <0H5300HY8198ZX@mta6.snfc21.pbi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Jeffrey Hsu wrote: > >> I have patches lying around > >> that varies the initial window size from 2 to 4 depending on the MSS, > >> as specified in the RFC. > > > We could not apply those patches until we fix a bug serverside which > > increments snd_cwnd with 1 mss somewhere... > > Take a look on TCP session. > > No, no, I meant I wrote my own, which doesn't show this problem in the > traces I've examined. Just for clarification - this problem shows up on nonpatched fresh-installed system. > But, it's all rolled up into a bunch > of other congestion related stuff I'm still working on like SACK and, > more importantly, Limited Transmit, exactly because all this stuff > modifies and examines the same variables and so all the functionality > has to be tested together to make sure no part breaks any other part. Good stuff ;)) Do you plan to commit code anytime soon? --- Oleg > > Jeffrey __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 22:10: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0BE637B401 for ; Mon, 4 Nov 2002 22:09:58 -0800 (PST) Received: from web10403.mail.yahoo.com (web10403.mail.yahoo.com [216.136.130.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 154C043E4A for ; Mon, 4 Nov 2002 22:09:58 -0800 (PST) (envelope-from opolyakov@yahoo.com) Message-ID: <20021105060957.77055.qmail@web10403.mail.yahoo.com> Received: from [12.236.91.184] by web10403.mail.yahoo.com via HTTP; Mon, 04 Nov 2002 22:09:57 PST Date: Mon, 4 Nov 2002 22:09:57 -0800 (PST) From: Oleg Polyakov Subject: Re: RFC 3390: Increasing TCP's Initial Window To: freebsd-net@freebsd.org, hsu@FreeBSD.org Cc: freebsd-net@freebsd.org In-Reply-To: <0H5300HY8198ZX@mta6.snfc21.pbi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --- Jeffrey Hsu wrote: > >> I have patches lying around > >> that varies the initial window size from 2 to 4 depending on the MSS, > >> as specified in the RFC. > > > We could not apply those patches until we fix a bug serverside which > > increments snd_cwnd with 1 mss somewhere... > > Take a look on TCP session. > > No, no, I meant I wrote my own, which doesn't show this problem in the > traces I've examined. Just for clarification - this problem shows up on nonpatched fresh-installed system. > But, it's all rolled up into a bunch > of other congestion related stuff I'm still working on like SACK and, > more importantly, Limited Transmit, exactly because all this stuff > modifies and examines the same variables and so all the functionality > has to be tested together to make sure no part breaks any other part. Good stuff ;)) Do you plan to commit code anytime soon? --- Oleg > > Jeffrey __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 22:12:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A91A637B40B for ; Mon, 4 Nov 2002 22:12:13 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 737FF43E42 for ; Mon, 4 Nov 2002 22:12:12 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.6/8.11.4) with ESMTP id gA56CAuO005793 for ; Tue, 5 Nov 2002 08:12:10 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <3DC76139.5020101@he.iki.fi> Date: Tue, 05 Nov 2002 08:12:09 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: English [en],Finnish [fi] MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: mbufs exchausted Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Looking at the numbers, the messages about mbufs being exhausted do not make sense. Is this a known bug? Pete All mbuf clusters exhausted, please see tuning(7). All mbufs exhausted, please see tuning(7). All mbufs exhausted, please see tuning(7). > netstat -m 4296/4352/65536 mbufs in use (current/peak/max): 2242 mbufs allocated to data 6 mbufs allocated to packet headers 2048 mbufs allocated to socket names and addresses 2240/2292/16384 mbuf clusters in use (current/peak/max) 5672 Kbytes allocated to network (11% of mb_map in use) 96 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines > uname -a FreeBSD rms21.rommon.net 4.7-RELEASE FreeBSD 4.7-RELEASE #14: Thu Oct 17 18:57:59 EEST 2002 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 23: 6: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E383337B401 for ; Mon, 4 Nov 2002 23:06:00 -0800 (PST) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1443243E4A for ; Mon, 4 Nov 2002 23:06:00 -0800 (PST) (envelope-from mbretter@inode.at) Received: from line-c-254.adsl-dynamic.inode.at ([62.99.151.254]:1049 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 188xgO-0005X6-00; Tue, 05 Nov 2002 07:59:28 +0100 Message-ID: <3DC76D20.2030704@inode.at> Date: Tue, 05 Nov 2002 08:02:56 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2b) Gecko/20021016 X-Accept-Language: de-at, de-de, de, en, en-us MIME-Version: 1.0 To: "Dmitry A. Bondareff" Cc: freebsd-net@FreeBSD.org Subject: Re: Win XP with mpd References: <200211041813.gA4IDN7t034243@arch20m.dellroad.org> <003b01c2842f$821b1ee0$02020101@dimasic> In-Reply-To: <200211041813.gA4IDN7t034243@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I had similar problems in the past and I found that, if the "Internet Connection Sharing" is enabled on the Windows BOX pptp doesen't work anymore in the right way. bye, Dmitry A. Bondareff wrote: > When I used Win2000 client all works fine and fast. > I've tested WinXp with mpd in two places. > > In one place do not work nothing. > I see traffic on FreeBSD to Internet and from it, but on WinXP client no > HTTP, no ICQ. > And when i do telnet to some host I see answer from time to time. > One time I see login: > But after some seconds no answer. > > In the other place work fine HTTP from Explorer, but no ICQ. > When I do in ICQ client "Auto configure ..." all fine and fast. But > do not > connecting. > > All firewalls I was set to ALLOW from ANY to ANY. > > With best regards, > Dmitry. > > > ----- Original Message ----- > From: "Archie Cobbs" > To: "Dmitry A. Bondareff" > Cc: > Sent: Monday, November 04, 2002 11:13 PM > Subject: Re: Win XP with mpd > > > > >Dmitry A. Bondareff writes: > > > >>For a long time many peoples discussed why Win XP don't work with mpd. > >>May be you can help us ?? > >>Where I can find working configs ?? > > > >I've heard of some MTU problems, some of which mpd-3.10 should address. > > > >What's the specific problem you're having? > > > >-Archie > > > >__________________________________________________________________________ > >Archie Cobbs * Packet Design * > http://www.packetdesign.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Nov 4 23:40:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A1D137B401 for ; Mon, 4 Nov 2002 23:40:44 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AFC143E4A for ; Mon, 4 Nov 2002 23:40:43 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA66710; Mon, 4 Nov 2002 23:21:47 -0800 (PST) Date: Mon, 4 Nov 2002 23:21:46 -0800 (PST) From: Julian Elischer To: "Dmitry A. Bondareff" Cc: Archie Cobbs , Johan Larsson , "freebsd-net@FreeBSD.org" Subject: Re: Win XP with mpd In-Reply-To: <00de01c28489$20ebb760$02010101@wall> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 5 Nov 2002, Dmitry A. Bondareff wrote: > I'll trying to setup mtu to 1400, why I don't see it by ifconfig command ? > > From mpd.conf: > .... > set link mru 1400 > set link mtu 1400 the link commands affect the links.. this sets teh fragment size that Mulitlink ppp will use.. externally you only see teh interface mtu, which is a different thing.. try: set iface mtu 1400 > .... > > #mpd -b > > #ifconfig -a: > ng0: flags=8890 mtu 1500 > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > After connecting: > #ifconfig -a: > ng0: flags=88d1 mtu 1500 > inet 1.1.1.1 --> 10.0.2.1 netmask 0xffffffff > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > After disconnected: > #ifconfig -a: > ng0: flags=8890 mtu 1496 > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > > > ----- Original Message ----- > From: "Archie Cobbs" > To: "Johan Larsson" > Cc: "Archie Cobbs" ; "Dmitry A. Bondareff" > ; "freebsd-net@FreeBSD.org" > Sent: Tuesday, November 05, 2002 12:04 AM > Subject: Re: Win XP with mpd > > > > Johan Larsson writes: > > > > > For a long time many peoples discussed why Win XP don't work with > mpd. > > > > > May be you can help us ?? > > > > > Where I can find working configs ?? > > > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should > address. > > > > > > It might be MTU problems. But the problem occurs for example when i ping > > > the server from the windows xp machine, some pings get lost, some times > > > you must issue the ping command a few times, or run it with -t for a > while > > > to see them get lost. mpd-3.10 does not solve this problem > unfortunately. > > > > Try playing with the "set link mtu" and/or "set iface mtu" commands > > to manually set the MTU values. > > > > > I might be able to fix some dumps (from ethereal) under windows xp if > you > > > want it. And of course, these pings getting lost is just an easy way of > > > seeing the problem, you also get poor performance obviously. > > > > If you can tell where the packets are being dropped, that would be useful > > to know. > > > > -Archie > > > > __________________________________________________________________________ > > Archie Cobbs * Packet Design * http://www.packetdesign.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 0:19:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5435F37B401 for ; Tue, 5 Nov 2002 00:19:25 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id D626D43E4A for ; Tue, 5 Nov 2002 00:19:23 -0800 (PST) (envelope-from oppermann@tix.ch) Received: (qmail 50079 invoked from network); 5 Nov 2002 08:15:55 -0000 Received: from unknown (HELO tix.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Nov 2002 08:15:55 -0000 Message-ID: <3DC77ED9.4EED1312@tix.ch> Date: Tue, 05 Nov 2002 09:18:33 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: [Fwd: [lir-wg] Important Informational Message - root.zone change] Content-Type: multipart/mixed; boundary="------------AA771A466A4AEDFB4D926CE9" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------AA771A466A4AEDFB4D926CE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It's time to change /etc/namedb/named.root. -- Andre --------------AA771A466A4AEDFB4D926CE9 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Delivered-To: oppermann@pipeline.ch Received: (qmail 25219 invoked from network); 4 Nov 2002 23:25:47 -0000 Received: from unknown (HELO postboy.ripe.net) ([193.0.0.201]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 4 Nov 2002 23:25:47 -0000 Received: from postboy.ripe.net (localhost [127.0.0.1]) by postboy.ripe.net (Postfix) with ESMTP id 254616A1D5; Tue, 5 Nov 2002 00:27:02 +0100 (CET) Delivered-To: lir-wg@postboy.ripe.net Received: by postboy.ripe.net (Postfix, from userid 8) id 2FCF16A151; Tue, 5 Nov 2002 00:26:11 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postboy.ripe.net (Postfix) with ESMTP id 261EF6A058; Tue, 5 Nov 2002 00:26:11 +0100 (CET) Received: from postboy.ripe.net (postboy.ripe.net [193.0.0.201]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gA4NQAa1001342; Tue, 5 Nov 2002 00:26:10 +0100 Received: by postboy.ripe.net (Postfix, from userid 8) id E78716A151; Tue, 5 Nov 2002 00:26:10 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postboy.ripe.net (Postfix) with ESMTP id E0D096A058; Tue, 5 Nov 2002 00:26:10 +0100 (CET) Received: from postboy.ripe.net (postboy.ripe.net [193.0.0.201]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id gA4NQAa1001338; Tue, 5 Nov 2002 00:26:10 +0100 Received: by postboy.ripe.net (Postfix, from userid 8) id AD02C6A151; Tue, 5 Nov 2002 00:26:10 +0100 (CET) Received: from santee.icann.org (santee.icann.org [192.0.35.122]) by postboy.ripe.net (Postfix) with ESMTP id A3C3C6A058; Tue, 5 Nov 2002 00:26:09 +0100 (CET) Received: from VAIO (mailtest.icann.org [192.0.34.221]) by santee.icann.org (8.11.6/8.11.6) with ESMTP id gA4NQ4508033; Mon, 4 Nov 2002 15:26:04 -0800 From: "John Crain" To: "RIPE DNS WG" , "RIPE LIR WG" Date: Mon, 4 Nov 2002 15:26:03 -0800 Message-ID: <002401c28459$8b1414a0$5d2300c0@VAIO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RIPE-Spam-Level: ++++++ X-RIPE-Spam-Level: ++++++ X-RIPE-Spam-Level: X-RIPE-Signature: 1b2c5968184186053ff34fbf5edf5e4c X-RIPE-Spam-Status: NONE ; 6 X-RIPE-Spam-Status: NONE ; 6 Subject: [lir-wg] Important Informational Message - root.zone change Sender: lir-wg-admin@ripe.net Errors-To: lir-wg-admin@ripe.net X-BeenThere: lir-wg@lists.ripe.net X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: RIPE Local IR Working Group List-Unsubscribe: , X-Mozilla-Status2: 00000000 =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 *****PLEASE NOTE*****=20 This is an important Informational Message to the internet community: November 5, 2002, the IP address for J.root-servers.net will=20 change in the authoritative NS set for "dot". The change will=20 be reflected in zone serial # 2002110501.=20 The new set of servers authoritative for "dot" will be:=20 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4=20 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53=20 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12=20 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4=20 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241=20 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107=20 J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30=20 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129=20 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12=20 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33=20 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17=20 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10=20 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90=20 This WILL require a change to your root hints file. The new=20 file will be available via anonymous ftp from=20 rs.internic.net:/domain/named.root as well as=20 ftp.internic.net:/doamin/named.root starting 11/5/02 1700UTC (12pm EST/9am PST).=20 Both the new and old j.root-servers.net IP space will provide=20 answers in parallel for the foreseeable future. _________________________________________ John Crain Manager of Technical Operations ICANN/IANA crain@icann.org 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 _________________________________________ -----BEGIN PGP SIGNATURE----- Version: PGP Personal Security 7.0.3 iQA/AwUBPccB+9Gxp5XUiliSEQIoywCg8K173qtbZM6JHupF48GSCud5AZgAn1w+ AUt6QxkOnmeroXdpIdvT/T3T =3D72sA -----END PGP SIGNATURE----- --------------AA771A466A4AEDFB4D926CE9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 0:32:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96C2B37B401 for ; Tue, 5 Nov 2002 00:32:48 -0800 (PST) Received: from 12-234-90-219.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E8B243E3B for ; Tue, 5 Nov 2002 00:32:48 -0800 (PST) (envelope-from DougB@FreeBSD.org) Received: from master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.6/8.12.6) with ESMTP id gA58WfmX047961; Tue, 5 Nov 2002 00:32:41 -0800 (PST) (envelope-from DougB@FreeBSD.org) Received: from localhost (doug@localhost) by master.gorean.org (8.12.6/8.12.6/Submit) with ESMTP id gA58Wd96000999; Tue, 5 Nov 2002 00:32:41 -0800 (PST) Date: Tue, 5 Nov 2002 00:32:39 -0800 (PST) From: Doug Barton To: Andre Oppermann Cc: freebsd-net@FreeBSD.org Subject: Re: [Fwd: [lir-wg] Important Informational Message - root.zone change] In-Reply-To: <3DC77ED9.4EED1312@tix.ch> Message-ID: <20021105003056.V810-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 5 Nov 2002, Andre Oppermann wrote: > > It's time to change /etc/namedb/named.root. I'm planning to do it tomorrow morning. They haven't actually loaded the new zone yet, and probably won't till sometime near or after 3am California time. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 1: 8:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A792C37B401 for ; Tue, 5 Nov 2002 01:08:15 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1500743E3B for ; Tue, 5 Nov 2002 01:08:09 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA5967Af025102; Tue, 5 Nov 2002 14:06:07 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gA590xm07763; Tue, 5 Nov 2002 14:00:59 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gA595hsX000307; Tue, 5 Nov 2002 14:05:43 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <001601c284ab$4bdb1c00$02010101@wall> From: "Dmitry A. Bondareff" To: Cc: "FreeBSD Net" References: <008701c284aa$08515590$faf810ac@sof.procreditbank.bg> Subject: Re: Win XP with mpd Date: Tue, 5 Nov 2002 14:11:16 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On which side ?? On WinXp or on MPD side ? With best regards, Dmitry. ----- Original Message ----- From: "Ivailo Tanusheff" To: "'Dmitry A. Bondareff'" Cc: "FreeBSD Net" Sent: Tuesday, November 05, 2002 2:02 PM Subject: RE: Win XP with mpd > A time ago I had the same problem, which is related with mtu/mru of the > connection. The solution for the XP is to setup the VPN connection to > use multilink (trough options). This solved my problem. > > Kind Regards, > Ivailo Tanusheff > > > > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG] On Behalf Of Dmitry A. Bondareff > Sent: Monday, November 04, 2002 8:25 PM > To: Archie Cobbs > Cc: freebsd-net@FreeBSD.org > Subject: Re: Win XP with mpd > > When I used Win2000 client all works fine and fast. > I've tested WinXp with mpd in two places. > > In one place do not work nothing. > I see traffic on FreeBSD to Internet and from it, but on WinXP client no > HTTP, no ICQ. > And when i do telnet to some host I see answer from time to time. > One time I see login: > But after some seconds no answer. > > In the other place work fine HTTP from Explorer, but no ICQ. > When I do in ICQ client "Auto configure ..." all fine and fast. But do > not > connecting. > > All firewalls I was set to ALLOW from ANY to ANY. > > With best regards, > Dmitry. > > > ----- Original Message ----- > From: "Archie Cobbs" > To: "Dmitry A. Bondareff" > Cc: > Sent: Monday, November 04, 2002 11:13 PM > Subject: Re: Win XP with mpd > > > > Dmitry A. Bondareff writes: > > > For a long time many peoples discussed why Win XP don't work with > mpd. > > > May be you can help us ?? > > > Where I can find working configs ?? > > > > I've heard of some MTU problems, some of which mpd-3.10 should > address. > > > > What's the specific problem you're having? > > > > -Archie > > > > > ________________________________________________________________________ > __ > > Archie Cobbs * Packet Design * > http://www.packetdesign.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 1:41:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54F3437B401 for ; Tue, 5 Nov 2002 01:41:30 -0800 (PST) Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54AA43E75 for ; Tue, 5 Nov 2002 01:41:28 -0800 (PST) (envelope-from ml.ventu@flashnet.it) Received: from smtp.flashnet.it ([195.191.20.24]) by relay.flashnet.it (/) with SMTP id gA59fKe04559 for ; Tue, 5 Nov 2002 10:41:21 +0100 Message-Id: <200211050941.gA59fKe04559@relay.flashnet.it> To: freebsd-net@freebsd.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Tue, 5 Nov 2002 10:41:16 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Dial in only works for a while Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello. I set up a machine to accept dial-in modem connections according to the suggestions in the Handbook: _ I set up my modem so as to lock its speed, don't echo commands, don't give any reply code and auto-answer; _ I modified rc.serial so as to set-up /dev/ttyd0 as a modem at 57600 bps; _ through /etc/ttys, I instructed init to spawn a getty process with a terminal type of std.57600; _ I corrected /etc/gettytab, adding a pp options so as to invoke a script for ppp; _ I set up ppp.conf for dial-in. Everything works fine, I can login directly with a terminal emulation program (like cu) or via a ppp connection... for a while. After a few days this stops working: ppp cannot pass the login phase and if I connect with cu I see garbage coming from the remote end instead of the login prompt. If I press any single key, several other garbage chars will come in again. I tried rebooting the machine, reinvoking rc.serial, power-cycling the modem, HUPping getty, but all this usually fails, until I finally manage to get it back to work, I don't really know how. Has anyone had the same problem? Does anyone have any hint to share? Bye & Thanks a lot av. P.S. The modem is an external 3Com 56K. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 3:25:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F6137B401 for ; Tue, 5 Nov 2002 03:25:33 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 892A143E42 for ; Tue, 5 Nov 2002 03:25:30 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA5BMwAf026630; Tue, 5 Nov 2002 16:22:58 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gA5BHpc16318; Tue, 5 Nov 2002 16:17:51 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gA5BMF1F000222; Tue, 5 Nov 2002 16:22:31 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <002501c284be$69404eb0$02010101@wall> From: "Dmitry A. Bondareff" To: "Julian Elischer" Cc: "Archie Cobbs" , "Johan Larsson" , "freebsd-net@FreeBSD.org" References: Subject: SUMMARY: Win XP with mpd Date: Tue, 5 Nov 2002 16:27:47 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After installing mpd-3.10 and using in mpd.conf: set iface mtu 1400 XP works fine and fast. There is no some tuning on the WinXP client I was make. Many thanks for all. Dmitry. ----- Original Message ----- From: "Julian Elischer" To: "Dmitry A. Bondareff" Cc: "Archie Cobbs" ; "Johan Larsson" ; "freebsd-net@FreeBSD.org" Sent: Tuesday, November 05, 2002 12:21 PM Subject: Re: Win XP with mpd > > > On Tue, 5 Nov 2002, Dmitry A. Bondareff wrote: > > > I'll trying to setup mtu to 1400, why I don't see it by ifconfig command ? > > > > From mpd.conf: > > .... > > set link mru 1400 > > set link mtu 1400 > > > the link commands affect the links.. > this sets teh fragment size that Mulitlink ppp will use.. > externally you only see teh interface mtu, which is > a different thing.. > try: > > set iface mtu 1400 > > > > .... > > > > #mpd -b > > > > #ifconfig -a: > > ng0: flags=8890 mtu 1500 > > ng1: flags=8890 mtu 1500 > > ng2: flags=8890 mtu 1500 > > ng3: flags=8890 mtu 1500 > > ng4: flags=8890 mtu 1500 > > > > After connecting: > > #ifconfig -a: > > ng0: flags=88d1 mtu 1500 > > inet 1.1.1.1 --> 10.0.2.1 netmask 0xffffffff > > ng1: flags=8890 mtu 1500 > > ng2: flags=8890 mtu 1500 > > ng3: flags=8890 mtu 1500 > > ng4: flags=8890 mtu 1500 > > > > After disconnected: > > #ifconfig -a: > > ng0: flags=8890 mtu 1496 > > ng1: flags=8890 mtu 1500 > > ng2: flags=8890 mtu 1500 > > ng3: flags=8890 mtu 1500 > > ng4: flags=8890 mtu 1500 > > > > > > > > ----- Original Message ----- > > From: "Archie Cobbs" > > To: "Johan Larsson" > > Cc: "Archie Cobbs" ; "Dmitry A. Bondareff" > > ; "freebsd-net@FreeBSD.org" > > Sent: Tuesday, November 05, 2002 12:04 AM > > Subject: Re: Win XP with mpd > > > > > > > Johan Larsson writes: > > > > > > For a long time many peoples discussed why Win XP don't work with > > mpd. > > > > > > May be you can help us ?? > > > > > > Where I can find working configs ?? > > > > > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should > > address. > > > > > > > > It might be MTU problems. But the problem occurs for example when i ping > > > > the server from the windows xp machine, some pings get lost, some times > > > > you must issue the ping command a few times, or run it with -t for a > > while > > > > to see them get lost. mpd-3.10 does not solve this problem > > unfortunately. > > > > > > Try playing with the "set link mtu" and/or "set iface mtu" commands > > > to manually set the MTU values. > > > > > > > I might be able to fix some dumps (from ethereal) under windows xp if > > you > > > > want it. And of course, these pings getting lost is just an easy way of > > > > seeing the problem, you also get poor performance obviously. > > > > > > If you can tell where the packets are being dropped, that would be useful > > > to know. > > > > > > -Archie > > > > > > __________________________________________________________________________ > > > Archie Cobbs * Packet Design * http://www.packetdesign.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 4: 0:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1826B37B401 for ; Tue, 5 Nov 2002 04:00:53 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C13A443E42 for ; Tue, 5 Nov 2002 04:00:50 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gA5Bx0Af027012; Tue, 5 Nov 2002 16:59:00 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gA5BrqW18419; Tue, 5 Nov 2002 16:53:52 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gA5BwU1F003425; Tue, 5 Nov 2002 16:58:35 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <006701c284c3$723832d0$02010101@wall> From: "Dmitry A. Bondareff" To: "Johan Larsson" Cc: References: <20021105124636.R53668-100000@treo.operax.com> Subject: Re: SUMMARY: Win XP with mpd Date: Tue, 5 Nov 2002 17:04:02 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org FreeBSD 4.7-RELEASE MPD-3.10 mpd.conf: default: load client1 client1: new -i ng0 pptp0 pptp0 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface idle 600 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set iface mtu 1400 # set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 161.8.22.2 # set ipcp nbns 192.168.1.4 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless mpd.links: pptp0: set link type pptp set pptp self X.X.X.X set pptp enable incoming set pptp disable originate mpd.log: Nov 5 14:30:46 wall mpd: [pptp0] IFACE: Up event Nov 5 14:30:46 wall mpd: [pptp0] exec: /sbin/ifconfig ng0 1.1.1.1 10.0.2.2 netmask 0xffffffff -link0 Nov 5 14:30:46 wall mpd: [pptp0] no interface to proxy arp on for 10.0.2.2 Nov 5 14:30:46 wall mpd: [pptp0] exec: 1400 ng0 inet 1.1.1.1 10.0.2.2 user Nov 5 14:30:46 wall mpd: [pptp0] exec: command returned 32512 Nov 5 14:30:46 wall mpd: [pptp0] IFACE: Up event Best regards, Dmitry. ----- Original Message ----- From: "Johan Larsson" To: "Dmitry A. Bondareff" Sent: Tuesday, November 05, 2002 4:49 PM Subject: Re: SUMMARY: Win XP with mpd > On Tue, 5 Nov 2002, Dmitry A. Bondareff wrote: > > > After installing mpd-3.10 > > and using in mpd.conf: > > set iface mtu 1400 > > XP works fine and fast. > > Humm, you don't have any problem with it setting the mtu on the interface? > I get this in my logs (in the terminal windows where i run mpd). > > [pptp1] exec: 1400 ng0 inet 192.168.1.2 192.168.1.65 johan > 1400: not found > > > > > > There is no some tuning on the WinXP client I was make. > > > > Many thanks for all. > > > > Dmitry. > > > > ----- Original Message ----- > > From: "Julian Elischer" > > To: "Dmitry A. Bondareff" > > Cc: "Archie Cobbs" ; "Johan Larsson" > > ; "freebsd-net@FreeBSD.org" > > > > Sent: Tuesday, November 05, 2002 12:21 PM > > Subject: Re: Win XP with mpd > > > > > > > > > > > > > On Tue, 5 Nov 2002, Dmitry A. Bondareff wrote: > > > > > > > I'll trying to setup mtu to 1400, why I don't see it by ifconfig command > > ? > > > > > > > > From mpd.conf: > > > > .... > > > > set link mru 1400 > > > > set link mtu 1400 > > > > > > > > > the link commands affect the links.. > > > this sets teh fragment size that Mulitlink ppp will use.. > > > externally you only see teh interface mtu, which is > > > a different thing.. > > > try: > > > > > > set iface mtu 1400 > > > > > > > > > > .... > > > > > > > > #mpd -b > > > > > > > > #ifconfig -a: > > > > ng0: flags=8890 mtu 1500 > > > > ng1: flags=8890 mtu 1500 > > > > ng2: flags=8890 mtu 1500 > > > > ng3: flags=8890 mtu 1500 > > > > ng4: flags=8890 mtu 1500 > > > > > > > > After connecting: > > > > #ifconfig -a: > > > > ng0: flags=88d1 mtu 1500 > > > > inet 1.1.1.1 --> 10.0.2.1 netmask 0xffffffff > > > > ng1: flags=8890 mtu 1500 > > > > ng2: flags=8890 mtu 1500 > > > > ng3: flags=8890 mtu 1500 > > > > ng4: flags=8890 mtu 1500 > > > > > > > > After disconnected: > > > > #ifconfig -a: > > > > ng0: flags=8890 mtu 1496 > > > > ng1: flags=8890 mtu 1500 > > > > ng2: flags=8890 mtu 1500 > > > > ng3: flags=8890 mtu 1500 > > > > ng4: flags=8890 mtu 1500 > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Archie Cobbs" > > > > To: "Johan Larsson" > > > > Cc: "Archie Cobbs" ; "Dmitry A. Bondareff" > > > > ; "freebsd-net@FreeBSD.org" > > > > Sent: Tuesday, November 05, 2002 12:04 AM > > > > Subject: Re: Win XP with mpd > > > > > > > > > > > > > Johan Larsson writes: > > > > > > > > For a long time many peoples discussed why Win XP don't work > > with > > > > mpd. > > > > > > > > May be you can help us ?? > > > > > > > > Where I can find working configs ?? > > > > > > > > > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should > > > > address. > > > > > > > > > > > > It might be MTU problems. But the problem occurs for example when i > > ping > > > > > > the server from the windows xp machine, some pings get lost, some > > times > > > > > > you must issue the ping command a few times, or run it with -t for a > > > > while > > > > > > to see them get lost. mpd-3.10 does not solve this problem > > > > unfortunately. > > > > > > > > > > Try playing with the "set link mtu" and/or "set iface mtu" commands > > > > > to manually set the MTU values. > > > > > > > > > > > I might be able to fix some dumps (from ethereal) under windows xp > > if > > > > you > > > > > > want it. And of course, these pings getting lost is just an easy way > > of > > > > > > seeing the problem, you also get poor performance obviously. > > > > > > > > > > If you can tell where the packets are being dropped, that would be > > useful > > > > > to know. > > > > > > > > > > -Archie > > > > > > > > > > > > __________________________________________________________________________ > > > > > Archie Cobbs * Packet Design * > > http://www.packetdesign.com > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > -- > Johan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 4:43: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A71B37B401 for ; Tue, 5 Nov 2002 04:43:01 -0800 (PST) Received: from ene.asda.gr (ene.asda.gr [193.92.118.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC4C43E8A for ; Tue, 5 Nov 2002 04:43:00 -0800 (PST) (envelope-from lefty@ene.asda.gr) Received: from ene.asda.gr (lefty.ene.asda.gr [193.92.118.162]) (authenticated bits=0) by ene.asda.gr (8.12.6/8.12.6) with ESMTP id gA5CgpcJ080484; Tue, 5 Nov 2002 14:42:55 +0200 (EET) (envelope-from lefty@ene.asda.gr) Message-ID: <3DC7BCC4.52B5BF65@ene.asda.gr> Date: Tue, 05 Nov 2002 14:42:44 +0200 From: Lefteris Tsintjelis X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,el MIME-Version: 1.0 To: Andrea Venturoli Cc: freebsd-net@FreeBSD.ORG Subject: Re: Dial in only works for a while References: <200211050941.gA59fKe04559@relay.flashnet.it> Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Same pattern of garbage when pressing a key usually means wrong speed in most cases, or parity/stop/start/data bits. It could be your serial port or your modem at your end or remote end. Next time try and use -s 115200 with cu. That would set the serial port speed at 115200 and see what happens. Regards, Lefteris Andrea Venturoli wrote: > > Hello. > > I set up a machine to accept dial-in modem connections according to the suggestions in the Handbook: > _ I set up my modem so as to lock its speed, don't echo commands, don't give any reply code and auto-answer; > _ I modified rc.serial so as to set-up /dev/ttyd0 as a modem at 57600 bps; > _ through /etc/ttys, I instructed init to spawn a getty process with a terminal type of std.57600; > _ I corrected /etc/gettytab, adding a pp options so as to invoke a script for ppp; > _ I set up ppp.conf for dial-in. > > Everything works fine, I can login directly with a terminal emulation program (like cu) or via a ppp connection... for a > while. > After a few days this stops working: ppp cannot pass the login phase and if I connect with cu I see garbage coming from > the remote end instead of the login prompt. If I press any single key, several other garbage chars will come in again. > > I tried rebooting the machine, reinvoking rc.serial, power-cycling the modem, HUPping getty, but all this usually fails, > until I finally manage to get it back to work, I don't really know how. > > Has anyone had the same problem? Does anyone have any hint to share? > > Bye & Thanks a lot > av. > > P.S. The modem is an external 3Com 56K. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 7:34:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6197037B401 for ; Tue, 5 Nov 2002 07:34:35 -0800 (PST) Received: from hotmail.com (f135.law14.hotmail.com [64.4.21.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA78143E77 for ; Tue, 5 Nov 2002 07:34:34 -0800 (PST) (envelope-from floating_in_space_@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 5 Nov 2002 07:34:34 -0800 Received: from 65.92.205.223 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 05 Nov 2002 15:34:34 GMT X-Originating-IP: [65.92.205.223] From: "alexis georges" To: freebsd-net@FreeBSD.org Subject: dhclient turns ethernet card off Date: Tue, 05 Nov 2002 15:34:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Nov 2002 15:34:34.0755 (UTC) FILETIME=[D7C81530:01C284E0] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hey guys we had a power cut yesterday..all went down at our home.. when we got electricity back, my internet wouldnot work..only my computer atually..i found that my eth. card would not turn on..or actually i just foung out now..it does turn on until it get to the 'dhclient dc0' lne in rc.conf..which i need..basically during boot up it turns on..and when it has t exectute the dchlient line, the light on the card disapears..its weird.i have a linksys (LNE TX?) anyways the way i have to have my card going is by having start_if.dc0 with a line that turns my card to half-duplex (it needs to be like this) and then in the rc.conf i have the ifconfig_dc0="DHCP" anyone knoe what could cause my card to literally shut down on dhclient? i already tried just in case to change PCI slots, but nothing changed.. thanks in advance _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 7:36:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5831B37B404 for ; Tue, 5 Nov 2002 07:36:33 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5178143E75 for ; Tue, 5 Nov 2002 07:36:32 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VWK6>; Tue, 5 Nov 2002 10:36:31 -0500 Message-ID: From: Don Bowman To: 'alexis georges' , freebsd-net@FreeBSD.org Subject: RE: dhclient turns ethernet card off Date: Tue, 5 Nov 2002 10:36:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > From: alexis georges [mailto:floating_in_space_@hotmail.com] > hey guys > we had a power cut yesterday..all went down at our home.. > when we got electricity back, my internet wouldnot work..only > my computer > atually..i found that my eth. card would not turn on..or > actually i just > foung out now..it does turn on until it get to the 'dhclient > dc0' lne in > rc.conf..which i need..basically during boot up it turns > on..and when it has > t exectute the dchlient line, the light on the card > disapears..its weird.i > have a linksys (LNE TX?) > anyways the way i have to have my card going is by having > start_if.dc0 with > a line that turns my card to half-duplex (it needs to be like > this) and then > in the rc.conf i have the ifconfig_dc0="DHCP" > anyone knoe what could cause my card to literally shut down > on dhclient? > i already tried just in case to change PCI slots, but nothing > changed.. > thanks in advance some routers disable ports if they see too many errors, e.g. due to a duplex mismatch. Is your router set to auto? and the NIC is as well? --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 8:55: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92C437B404 for ; Tue, 5 Nov 2002 08:55:07 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F54043E4A for ; Tue, 5 Nov 2002 08:55:07 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id gA5Gt51H050036 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Nov 2002 08:55:06 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <212201c284ec$26cea3a0$52557f42@errno.com> From: "Sam Leffler" To: Subject: CFR: network patch Date: Tue, 5 Nov 2002 08:55:30 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org http://www.freebsd.org/~sam/network.patch.gz has a patch that contains a bunch of changes to the network interface layer and related drivers. These changes are intended to reduce incompatibilities between freebsd and netbsd so that work can be more easily exchanged/shared. In particular, this stuff came up while working with the netbsd if_ieee80211subr.c code; a common layer to be shared by all 802.11 drivers. Many of the changes are "mechanical". Some change ABI's and as such I'd like to get them into 5.0-R since otherwise we'll be stuck until 6.0. Everything in this patch has been tested except for some of the hardware drivers (see below). In addition I did some performance testing of the vlan mods and see almost identical performance running netperf over a 100baseT network w/ and w/o hardware tagging (.1% drop). A list of the changes are: 1. Add BPF support for multiple link types per interface (so, for example, you can tap at both 802.11 and Ethernet). 2. Wrap bpf_mtap and bpf_tap calls in macros to hide implementation details and ease code portability. 3. Add an if_input method to struct ifnet and replace all references to ether_input by (*if_input)(...). 4. Change the calling convention for ether_input: leave the ethernet header in the mbuf and possibly the FCS. 5. Change ether_ifattach and ether_ifdetach to remove the param that says whether bpf is supported. 6. Change ether_ifattach to take an ethernet address explicitly that's used to fillin the link level address (and temporarily the arpcom ethernet mac). 7. Change drivers to call ether_ifioctl for the default case and rely on it's error return. 8. Drivers that support vlan tagging in h/w now mark this in their capabilities. 9. Drivers that support large mtu's for vlan headers now mark this in their capabilities. 10. The mechanism for dealing with vlan-encapsulated packets is changed to use packet tags and to always go through ether_input. Among other things this eliminates the need for anyone but ether_input to know about vlan_input_p. 11. The vlan code now auto-recognizes interface capabilities w.r.t. vlans and does the right thing. 12. The vlan code now handles promiscuous mode correctly. 13. Change net/ethernet.h to add definitions from netbsd and to move some stuff out. 14. Add some #defines to net/if.h for netbsd compatibility I'm interested in all manner of comments, but please send nits directly to me rather than everyone. If you have hardware to test the le, ie, or wl drivers I'd really appreciate help as these have non-trivial changes that are currently untested. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 8:58:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6A0737B401 for ; Tue, 5 Nov 2002 08:58:08 -0800 (PST) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B34043E3B for ; Tue, 5 Nov 2002 08:58:04 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from amduat.net (nat-bhm1.attachmate.com [63.115.16.66]) (authenticated bits=0) by aker.amduat.net (8.12.6/8.12.6) with ESMTP id gA5Gvv3t023537 for ; Tue, 5 Nov 2002 08:57:57 -0800 (PST) (envelope-from jbarrett@amduat.net) Message-ID: <3DC7F88B.8090602@amduat.net> Date: Tue, 05 Nov 2002 08:57:47 -0800 From: "Jacob S. Barrett" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: VLAN tag byte swap and chop problem?? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am not sure if I am doing something completely wrong of if I have found some sort of bug here, but I thought I would toss it out to see if anyone else has ever seen this. I have two ports on my switch configured for vlan id 5. Port 1 is untagged and port 2 is tagged. The machine A is on port 1 and machine B is on port 2. Machine B's card is configure with multiple vlan nodes attached to it, including vlan id 5. I couldn't ping B from A so I attached tcpdump to the parent interface on B to see what was happening. So here is the strange part. The arp request from A to find B says that it is on vlan 1280. So I set the vlan id on the switch to 1280 and tcpdump says 5. So, id 0x0005 on the switch becomes 0x0500 on the host and 0x0500 on the switch becomes 0x0005 on the host. So I thought maybe a byte order problem until I tried setting the id on the switch to 18. So the id on the switch was 0x0012 and tcpdump reported it on vlan 0x0200. Trying other vlan IDs shows the same behavior. The id on the framed that is delivered is byte swapped with the first nibble chopped off. 0x0005 -> 0x0500 0x0500 -> 0x0005 0x0002 -> 0x0200 0x0200 -> 0x0002 0x0012 -> 0x0200 Here is my tcpdump from machine B (.1). Machine be is attempting to ping machine A (.2). It shows the frame leaving as vlan 2 (0x0020) (correct) and the reply coming back from A on vlan 512 (0x0200). 11:35:16.982435 802.1Q vlan#2 P0 arp who-has 10.126.0.2 (2e:2f:30:31:32:33) tell 10.126.0.1 11:35:16.982593 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at 0:90:27:f4:3c:9f 11:35:17.992434 802.1Q vlan#2 P0 arp who-has 10.126.0.2 (2e:2f:30:31:32:33) tell 10.126.0.1 11:35:17.992604 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at 0:90:27:f4:3c:9f 11:35:19.002467 802.1Q vlan#2 P0 arp who-has 10.126.0.2 (2e:2f:30:31:32:33) tell 10.126.0.1 11:35:19.002627 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at 0:90:27:f4:3c:9f So does anyone have any ideas? I am assuming this is either a configuration issue on my part with my boxes or a bug in the vlan code for if_em. I doubt that it is a problem with the switch firmware since this came from a production site where vlans were used extensively. Also, it correctly transmits the frame on the ports tagged for that vlan. My guess is that it is in the if_em driver somewhere. If anyone wants to tackle this let me know. Hardware Involved: (1) Extreme Networks Summit 4 (2) HP LPr Dual PIII 600MHz (1) Intel Pro 10/100B/100+ Ethernet (2) Intel(R) PRO/1000 -Jake -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 9: 1:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 780FD37B404 for ; Tue, 5 Nov 2002 09:01:14 -0800 (PST) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A53743E4A for ; Tue, 5 Nov 2002 09:01:13 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from amduat.net (nat-bhm1.attachmate.com [63.115.16.66]) (authenticated bits=0) by aker.amduat.net (8.12.6/8.12.6) with ESMTP id gA5H193t023551; Tue, 5 Nov 2002 09:01:11 -0800 (PST) (envelope-from jbarrett@amduat.net) Message-ID: <3DC7F94B.2020606@amduat.net> Date: Tue, 05 Nov 2002 09:00:59 -0800 From: "Jacob S. Barrett" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jacob S. Barrett" Cc: freebsd-net@FreeBSD.ORG Subject: Correction: VLAN tag byte swap and chop problem?? References: <3DC7F88B.8090602@amduat.net> In-Reply-To: <3DC7F88B.8090602@amduat.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Line: It shows the frame leaving as vlan 2 (0x0020) (correct) ... Should read: It shows the frame leaving as vlan 2 (0x0002) (correct) ... Sorry, Jake Jacob S. Barrett wrote: > I am not sure if I am doing something completely wrong of if I have > found some sort of bug here, but I thought I would toss it out to see if > anyone else has ever seen this. > > I have two ports on my switch configured for vlan id 5. Port 1 is > untagged and port 2 is tagged. The machine A is on port 1 and machine B > is on port 2. Machine B's card is configure with multiple vlan nodes > attached to it, including vlan id 5. I couldn't ping B from A so I > attached tcpdump to the parent interface on B to see what was happening. > So here is the strange part. The arp request from A to find B says > that it is on vlan 1280. So I set the vlan id on the switch to 1280 and > tcpdump says 5. So, id 0x0005 on the switch becomes 0x0500 on the host > and 0x0500 on the switch becomes 0x0005 on the host. So I thought maybe > a byte order problem until I tried setting the id on the switch to 18. > So the id on the switch was 0x0012 and tcpdump reported it on vlan > 0x0200. Trying other vlan IDs shows the same behavior. The id on the > framed that is delivered is byte swapped with the first nibble chopped > off. > > 0x0005 -> 0x0500 > 0x0500 -> 0x0005 > 0x0002 -> 0x0200 > 0x0200 -> 0x0002 > 0x0012 -> 0x0200 > > Here is my tcpdump from machine B (.1). Machine be is attempting to > ping machine A (.2). It shows the frame leaving as vlan 2 (0x0020) > (correct) and the reply coming back from A on vlan 512 (0x0200). > > 11:35:16.982435 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:16.982593 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > 11:35:17.992434 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:17.992604 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > 11:35:19.002467 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:19.002627 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > > So does anyone have any ideas? I am assuming this is either a > configuration issue on my part with my boxes or a bug in the vlan code > for if_em. I doubt that it is a problem with the switch firmware since > this came from a production site where vlans were used extensively. > Also, it correctly transmits the frame on the ports tagged for that > vlan. My guess is that it is in the if_em driver somewhere. If anyone > wants to tackle this let me know. > > Hardware Involved: > (1) Extreme Networks Summit 4 > (2) HP LPr Dual PIII 600MHz > (1) Intel Pro 10/100B/100+ Ethernet > (2) Intel(R) PRO/1000 > > -Jake > -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 9:25:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AAF437B401 for ; Tue, 5 Nov 2002 09:25:40 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE3F343E3B for ; Tue, 5 Nov 2002 09:25:37 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 1897SH-0002eB-00 for freebsd-net@freebsd.org; Tue, 05 Nov 2002 19:25:33 +0200 Date: Tue, 5 Nov 2002 19:25:33 +0200 (EET) From: Iasen Kostov To: freebsd-net@freebsd.org Subject: NFS functions does *NOT* check if they really have allocated any memory Message-ID: <20021105183154.I80368-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As I experience system crushes at time of mbufs exhaustion I've compiled a debug kernel and traced the problem. I seems the NFS functions (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have allocated memory by MGET macro. First problem that I saw was in nfsm_reqh at nfs/nfs_subs.c:593 (4.7-STABLE). I've added a check for mb == 0 - if so function just retuns NULL. But here raise another problem in "second level" functions - they don't check what lower level functions return , thus they crush kernel if the lower level functions return NULL. You could see it in nfs3_access_otw at nfs_vnops.c:293 - there is absent a check for value returned by nfsm_reqhead macro which calls nfsm_reqh(). I've looked at the other parts of kernel (drivers mainly) and I saw that after MGET allocations drivers check if they really have allocated mbufs (xl dirver) (which is not true for NFS :). Why NFS functions doesn't care if they really have allocated mbufs ? :), and I think they should care. regards To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 9:30:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83DBD37B401 for ; Tue, 5 Nov 2002 09:30:42 -0800 (PST) Received: from relay.flashnet.it (ems.flashnet.it [194.247.160.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 167F843E75 for ; Tue, 5 Nov 2002 09:30:41 -0800 (PST) (envelope-from ml.ventu@flashnet.it) Received: from smtp.flashnet.it ([195.191.17.193]) by relay.flashnet.it (/) with SMTP id gA5HUXR14771 for ; Tue, 5 Nov 2002 18:30:33 +0100 Message-Id: <200211051730.gA5HUXR14771@relay.flashnet.it> To: freebsd-net@FreeBSD.ORG X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Tue, 5 Nov 2002 18:30:25 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Re: Dial in only works for a while Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ** Reply to note from Lefteris Tsintjelis Tue, 05 Nov 2002 14:42:44 +0200 >Hi, Thanks a lot, this solved it, at least for now. However I'm quite sure that this will happen again, so I'd like to go through it all in order to solve it for good sooner or later. > Same pattern of garbage when pressing a key usually means wrong speed >in most cases, or parity/stop/start/data bits. > It could be your serial port or your modem at your end or remote end. Ok, I was also quite sure about this. > Next time try and use -s >115200 with cu. That would set the serial port speed at 115200 and see >what happens. In fact this helped (I used 57600, but that's not the point). I don't really understand the reason why either the modem or the serial port would change their setting spontaneously. Let's deal with the serial port: it's initialized at boot time by rc.serial, so a reboot should have set it up right. In any case wouldn't "sh /etc/rc.serial" be enough to solve the matter in case for some reasons it wasn't properly configured? Besides, stty showed a speed of 57600 bps, so I think it was not the problem. The modem: doing an ATI4 shows a speed of 57600 (obviously after issuing cu -s), while ATI5 shows 9600 and 115200 respectively for the two stored profiles. But again, now that it is working at this speed, why should it change? Furthermore, I often find that cu will only run once; after that, I get a "line in use" message, although ps shows no process using /dev/cuaa0 (there is getty on /dev/ttyd0, but that's also true the first time I run cu). Is there anything I can do to solve this without rebooting? bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 9:42:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD13137B401; Tue, 5 Nov 2002 09:42:51 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A86743E3B; Tue, 5 Nov 2002 09:42:51 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gA5Hgj5s046039; Tue, 5 Nov 2002 12:42:45 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gA5Hggea046038; Tue, 5 Nov 2002 12:42:42 -0500 (EST) Date: Tue, 5 Nov 2002 12:42:42 -0500 From: Barney Wolff To: Doug Barton Cc: Andre Oppermann , freebsd-net@FreeBSD.ORG Subject: Re: [Fwd: [lir-wg] Important Informational Message - root.zone change] Message-ID: <20021105174242.GB45667@tp.databus.com> References: <3DC77ED9.4EED1312@tix.ch> <20021105003056.V810-100000@master.gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021105003056.V810-100000@master.gorean.org> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org While it's important to make the change eventually, there is no need to panic - named.root is used only at named start, and is soon replaced internally by the actual list of roots. Also, named works fine as long as at least one root's address is correct. Also, the old address will continue to work for quite a while. This does not mean you can just forget about it, though. On Tue, Nov 05, 2002 at 12:32:39AM -0800, Doug Barton wrote: > On Tue, 5 Nov 2002, Andre Oppermann wrote: > > It's time to change /etc/namedb/named.root. > > I'm planning to do it tomorrow morning. They haven't actually loaded the > new zone yet, and probably won't till sometime near or after 3am > California time. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 9:46:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CA237B401 for ; Tue, 5 Nov 2002 09:46:58 -0800 (PST) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B01943E42 for ; Tue, 5 Nov 2002 09:46:57 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from amduat.net (nat-bhm1.attachmate.com [63.115.16.66]) (authenticated bits=0) by aker.amduat.net (8.12.6/8.12.6) with ESMTP id gA5Hkt3t023759; Tue, 5 Nov 2002 09:46:56 -0800 (PST) (envelope-from jbarrett@amduat.net) Message-ID: <3DC80403.9010908@amduat.net> Date: Tue, 05 Nov 2002 09:46:43 -0800 From: "Jacob S. Barrett" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN tag byte swap and chop problem?? References: <3DC7F88B.8090602@amduat.net> <20021105173701.GA45667@tp.databus.com> In-Reply-To: <3DC7F88B.8090602@amduat.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yeah, looks like they are 12 bits. I should I thought of that since the Summit has a range of 0-4095 vlan IDs, which is 12 bits. So that explains the chopping. Now if I can just solve the swapping all should be good! Thanks, Jake Barney Wolff wrote: > Dunno about the byte-order issue, but vlan numbers are not 16-bit > internally > in Cisco gear. 12 bits, I think, or even 10. That explains the > chopping, at least. > -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 10: 5:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 860E737B401 for ; Tue, 5 Nov 2002 10:05:53 -0800 (PST) Received: from srv.inorg.chem.msu.ru (rt-inorg.chem.msu.ru [195.208.208.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76BFF43E75 for ; Tue, 5 Nov 2002 10:05:51 -0800 (PST) (envelope-from anton@inorg.chem.msu.ru) Received: from anton (r546-1.inorg.chem.msu.ru [195.208.209.20]) by srv.inorg.chem.msu.ru (8.11.6/8.11.6) with SMTP id gA5I5mP94755 for ; Tue, 5 Nov 2002 21:05:48 +0300 (MSK) (envelope-from anton@inorg.chem.msu.ru) Message-ID: <008b01c284f5$f7b603b0$14d1d0c3@main.inorg.chem.msu.ru> From: "Anton Vinokurov" To: Subject: USB ethernet problem Date: Tue, 5 Nov 2002 21:05:47 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet adapter. Unfortunately it causes my system to print something like: kue0: watchdog timeout kue0: usb error on tx: TIMEOUT following by freeze. I got this problem while forwarding 50pps/64kbit UDP packet stream which comes from Cisco ATA186 voice gateway in several minutes after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver works fine at least under one day voice traffic load. I tried original driver and altq modifed with no success. Could someone suggest me a way to fix my problem? Anton L. Vinokurov, CCNA anton@inorg.chem.msu.ru NeTAMS Development Team To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 11:38: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 798C437B401 for ; Tue, 5 Nov 2002 11:38:05 -0800 (PST) Received: from 12-234-90-219.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1BF443E7B for ; Tue, 5 Nov 2002 11:38:04 -0800 (PST) (envelope-from DougB@FreeBSD.org) Received: from FreeBSD.org (master.gorean.org [10.0.0.2]) by 12-234-90-219.client.attbi.com (8.12.6/8.12.6) with ESMTP id gA5JbwmX005777; Tue, 5 Nov 2002 11:37:58 -0800 (PST) (envelope-from DougB@FreeBSD.org) Message-ID: <3DC81E16.58DCDD57@FreeBSD.org> Date: Tue, 05 Nov 2002 11:37:58 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff Cc: Andre Oppermann , freebsd-net@FreeBSD.org Subject: Re: [Fwd: [lir-wg] Important Informational Message - root.zone change] References: <3DC77ED9.4EED1312@tix.ch> <20021105003056.V810-100000@master.gorean.org> <20021105174242.GB45667@tp.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Barney Wolff wrote: > > While it's important to make the change eventually, there is no > need to panic Umm.. yes, I know that. :) It's why I haven't made the change yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 12:49: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21EB637B401; Tue, 5 Nov 2002 12:49:05 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC95043E75; Tue, 5 Nov 2002 12:48:54 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 12:48:54 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 12:48:54 -0800 Message-ID: <3DC82EB5.7974429D@exodus.net> Date: Tue, 05 Nov 2002 12:48:53 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Cc: Julian Elischer Subject: Netgraph and KQUEUE(2) References: <3DC82927.7200233B@exodus.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2002 20:48:54.0367 (UTC) FILETIME=[C0FC7EF0:01C2850C] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear Hackers, I would like to get some feedback on the idea i have. Basically i would like Netgraph system to send kevents whenever something happens. For example: 1) node X of type Y was created/destroyed 2) hook X was connected/disconnected to/from node Y 3) Data passed via hook X 4) Node X got message Y etc. Right now i can think of two scenarios where this could be useful. 1) Device driver in Netgraph node. When hardware is activated new Netgraph node is created and new kevent sent. devd (or something like devd) listens for these events and does something (loads firmware, activates device, etc.) 2) ngdump - "tcpdump" for Netgraph. Dumps everything that happens in the Netgraph. what do you think? thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 13:15:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63DA337B404 for ; Tue, 5 Nov 2002 13:15:12 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A3A43E75 for ; Tue, 5 Nov 2002 13:15:11 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA36596; Tue, 5 Nov 2002 13:07:10 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA5L6lZE039809; Tue, 5 Nov 2002 13:06:47 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA5L6igd039808; Tue, 5 Nov 2002 13:06:44 -0800 (PST) From: Archie Cobbs Message-Id: <200211052106.gA5L6igd039808@arch20m.dellroad.org> Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: <20021105183154.I80368-100000@shadowhand.OTEL.net> "from Iasen Kostov at Nov 5, 2002 07:25:33 pm" To: Iasen Kostov Date: Tue, 5 Nov 2002 13:06:44 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Iasen Kostov writes: > As I experience system crushes at time of mbufs exhaustion I've compiled > a debug kernel and traced the problem. I seems the NFS functions > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have > allocated memory by MGET macro. No check is necessary if M_WAIT is specified; the M_GET() function is always successful in that case. Same for malloc(). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 13:15:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16A1D37B404 for ; Tue, 5 Nov 2002 13:15:48 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E450343E3B for ; Tue, 5 Nov 2002 13:15:46 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA36598; Tue, 5 Nov 2002 13:09:09 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA5L8kZE039834; Tue, 5 Nov 2002 13:08:46 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA5L8iCg039833; Tue, 5 Nov 2002 13:08:44 -0800 (PST) From: Archie Cobbs Message-Id: <200211052108.gA5L8iCg039833@arch20m.dellroad.org> Subject: Re: SUMMARY: Win XP with mpd In-Reply-To: <006701c284c3$723832d0$02010101@wall> "from Dmitry A. Bondareff at Nov 5, 2002 05:04:02 pm" To: "Dmitry A. Bondareff" Date: Tue, 5 Nov 2002 13:08:44 -0800 (PST) Cc: Johan Larsson , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dmitry A. Bondareff writes: > Nov 5 14:30:46 wall mpd: [pptp0] exec: 1400 ng0 inet 1.1.1.1 10.0.2.2 user > Nov 5 14:30:46 wall mpd: [pptp0] exec: command returned 32512 This is a (harmless) bug in mpd 3.10, fixed by the patch below. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: iface.c =================================================================== RCS file: /home/cvs/archie/mpd/src/iface.c,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- iface.c 23 Oct 2002 21:15:47 -0000 1.6 +++ iface.c 5 Nov 2002 16:49:42 -0000 1.7 @@ -791,6 +791,7 @@ } iface->max_mtu = max_mtu; } + break; case SET_UP_SCRIPT: switch (ac) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 13:40:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F58737B401; Tue, 5 Nov 2002 13:40:40 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5D8B43E3B; Tue, 5 Nov 2002 13:40:39 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA70447; Tue, 5 Nov 2002 13:31:48 -0800 (PST) Date: Tue, 5 Nov 2002 13:31:47 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: current@freebsd.org, net@freebsd.org Subject: Re: Netgraph and KQUEUE(2) In-Reply-To: <3DC82EB5.7974429D@exodus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It's not a bad idea. On Tue, 5 Nov 2002, Maksim Yevmenkin wrote: > Dear Hackers, > > I would like to get some feedback on the idea i have. > Basically i would like Netgraph system to send kevents > whenever something happens. For example: > > 1) node X of type Y was created/destroyed > 2) hook X was connected/disconnected to/from node Y > 3) Data passed via hook X > 4) Node X got message Y > > etc. > > Right now i can think of two scenarios where this > could be useful. > > 1) Device driver in Netgraph node. When hardware is > activated new Netgraph node is created and new > kevent sent. devd (or something like devd) listens > for these events and does something (loads firmware, > activates device, etc.) > > 2) ngdump - "tcpdump" for Netgraph. Dumps everything > that happens in the Netgraph. > > what do you think? > > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 14:45: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01B4B37B401; Tue, 5 Nov 2002 14:45:05 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6189543E77; Tue, 5 Nov 2002 14:45:04 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA37163; Tue, 5 Nov 2002 14:32:19 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA5MVuZE040318; Tue, 5 Nov 2002 14:31:56 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA5MVuJB040317; Tue, 5 Nov 2002 14:31:56 -0800 (PST) From: Archie Cobbs Message-Id: <200211052231.gA5MVuJB040317@arch20m.dellroad.org> Subject: Re: Netgraph and KQUEUE(2) In-Reply-To: <3DC82EB5.7974429D@exodus.net> "from Maksim Yevmenkin at Nov 5, 2002 12:48:53 pm" To: Maksim Yevmenkin Date: Tue, 5 Nov 2002 14:31:56 -0800 (PST) Cc: current@FreeBSD.ORG, net@FreeBSD.ORG, Julian Elischer X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Maksim Yevmenkin writes: > I would like to get some feedback on the idea i have. > Basically i would like Netgraph system to send kevents > whenever something happens. For example: > > 1) node X of type Y was created/destroyed > 2) hook X was connected/disconnected to/from node Y > 3) Data passed via hook X > 4) Node X got message Y This would be nice, but what does kqueue() really have to do with it? I.e., why not just allow the creation of a ng_monitor(4) (or whatever you want to call it) node, which would send out event report messages to whomever connected to it. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 15: 9: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9970337B401; Tue, 5 Nov 2002 15:09:03 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB3B543E88; Tue, 5 Nov 2002 15:09:02 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 15:09:02 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Tue, 5 Nov 2002 15:09:02 -0800 Message-ID: <3DC84F87.D5CB9C1C@exodus.net> Date: Tue, 05 Nov 2002 15:08:55 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: current@FreeBSD.ORG, net@FreeBSD.ORG, Julian Elischer Subject: Re: Netgraph and KQUEUE(2) References: <200211052231.gA5MVuJB040317@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2002 23:09:02.0570 (UTC) FILETIME=[54AA74A0:01C28520] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Archie Cobbs wrote: > > Maksim Yevmenkin writes: > > I would like to get some feedback on the idea i have. > > Basically i would like Netgraph system to send kevents > > whenever something happens. For example: > > > > 1) node X of type Y was created/destroyed > > 2) hook X was connected/disconnected to/from node Y > > 3) Data passed via hook X > > 4) Node X got message Y > > This would be nice, but what does kqueue() really have to do with it? > > I.e., why not just allow the creation of a ng_monitor(4) (or whatever you > want to call it) node, which would send out event report messages to > whomever connected to it. common interface? reusing existing functionality? just open a Netgraph socket, register for events and away you go. and you are right ng_monitor (or whatever) is another way to do the same thing. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 15:40:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D564A37B401; Tue, 5 Nov 2002 15:40:18 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2916343E88; Tue, 5 Nov 2002 15:40:17 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA71162; Tue, 5 Nov 2002 15:30:02 -0800 (PST) Date: Tue, 5 Nov 2002 15:30:01 -0800 (PST) From: Julian Elischer To: Maksim Yevmenkin Cc: Archie Cobbs , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) In-Reply-To: <3DC84F87.D5CB9C1C@exodus.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 5 Nov 2002, Maksim Yevmenkin wrote: > Archie Cobbs wrote: > > > > Maksim Yevmenkin writes: > > > I would like to get some feedback on the idea i have. > > > Basically i would like Netgraph system to send kevents > > > whenever something happens. For example: > > > > > > 1) node X of type Y was created/destroyed > > > 2) hook X was connected/disconnected to/from node Y > > > 3) Data passed via hook X > > > 4) Node X got message Y > > > > This would be nice, but what does kqueue() really have to do with it? > > > > I.e., why not just allow the creation of a ng_monitor(4) (or whatever you > > want to call it) node, which would send out event report messages to > > whomever connected to it. > > common interface? reusing existing functionality? just open a > Netgraph socket, register for events and away you go. > > and you are right ng_monitor (or whatever) is another way to > do the same thing. A program would only have to look for one kind of event with kqueue. otherwise it's have to check with kqueue NAD teh ng_monitor node. Its possible BOTH approaches could be combined.. Most of teh event catching code would be shared. > thanks, > max > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 16:29:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4D1D37B401 for ; Tue, 5 Nov 2002 16:29:53 -0800 (PST) Received: from tet.runningwave.com (dsl027-144-067.nyc1.dsl.speakeasy.net [216.27.144.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 758DA43E6E for ; Tue, 5 Nov 2002 16:29:52 -0800 (PST) (envelope-from dsagal@runningwave.com) Received: from tet.runningwave.com (tet.runningwave.com [10.0.0.25] (may be forged)) by tet.runningwave.com (8.12.3/8.12.3) with ESMTP id gA60ToIS078080 for ; Tue, 5 Nov 2002 19:29:51 -0500 (EST) (envelope-from dsagal@runningwave.com) Received: from localhost (dsagal@localhost) by tet.runningwave.com (8.12.3/8.12.3/Submit) with ESMTP id gA60To2J078077 for ; Tue, 5 Nov 2002 19:29:50 -0500 (EST) (envelope-from dsagal@runningwave.com) Date: Tue, 5 Nov 2002 19:29:50 -0500 (EST) From: Dmitry Sagalovskiy Reply-To: Jason Carroll To: freebsd-net@freebsd.org Subject: Trouble with gigabit cards Message-ID: <20021105192815.T74046-100000@tet.runningwave.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: Jason Carroll Hi Everyone-- Has anyone had trouble with gigabit (copper) interfaces dropping multicast traffic? I've tried two different cards on both FreeBSD 4.5 and 4.7 and seen an alarmingly high loss of data over the gigabit interface, even when the gigabit interface is running at 100mbs/s and plugged into a 100mbs/s switch. Briefly, I am multicasting sequenced data to 10 multicast groups at about 1% network utilization (1 mbs/s). I have about 15 systems listening to the 10 multicast groups. All but one have 100mbs cards in them (a mixture of Intel Pro/100s and various 3com cards). One test system has an Intel Pro/1000, a NetGear GA622T and an Intel Pro/100. All 15 are plugged into the same switch which is a Cisco 100mbs/s multi-layer switch (a Catalyst 3550). When I use either of the gigabit cards on the test system with their appropriate drivers (em and nge), I start dropping packets from the various groups (one or several packets every minute or so). As soon as I switch over to the 100mbs card with the fxp driver, I stop losing data. I can provide oodles more information if anyone's interested in the problem. I've been trying various things and dumping kernel network statistics for several days now. Among the interesting things I've noticed: - Packets are not preferentially dropped from any of the 10 groups. - Two systems using slightly different cards (both Intel Pro/1000, but one with the 82540EM chip and the other with the 82544 chip) drop almost exactly the same packets when hooked up in in parallel, while the NetGear card drops different (but a roughly equivalent amount) of traffic. - I've monitored the udp traffic statistics (viewed by netstat -s), and these statistics don't appear to indicate the data was being dropped at the IP level or higher (see next note). That is, the "N dropped do to no socket", "M broadcast/multicast datagrams dropped due to no socket", and "S dropped due to full socket buffers" statistics didn't seem to account for our lost data. - I hacked in a crude packet monitor to the beginning of ip_input in sys/netinet/ip_input.c that indicates the data is being dropped at a lower level (it shows the same missing data as my user-land listener). - I haven't been able to reproduce the problem outside of our application, but I'm working on it. Thanks, Jason Carroll To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 17: 0:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C601637B401 for ; Tue, 5 Nov 2002 17:00:40 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9899243E42 for ; Tue, 5 Nov 2002 17:00:40 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 7DF21AE2D9; Tue, 5 Nov 2002 17:00:40 -0800 (PST) Date: Tue, 5 Nov 2002 17:00:40 -0800 From: Maxime Henrion To: net@FreeBSD.org Subject: problems with stf(4) and ipv6_gateway_enable Message-ID: <20021106010040.GJ26605@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'm having problems setting my box as an ipv6 router. It's already doing 6to4 using the following configuration without problems. ipv6_enable="YES" ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) ipv6_prefix_xl1="2002:5143:8351:" stf_interface_ipv4addr="81.67.131.81" When I add the following knobs : ipv6_gateway_enable="YES" rtadvd_enable="YES" rtadvd_interfaces="xl0" The ipv6_gateway_enable causes the startup script to issue another ifconfig command (line 101 of /etc/rc.d/network_ipv6) which fails with the following error message : ifconfig: 2002:5143:8351:::: bad value I assume I must be doing something stupid since I'm no IPv6 expert. Another odd thing to note is that the boot scripts output : IPv4 mapped IPv6 address support=NO while it works fine (except for the gateway thing). Any thoughts are of course appreciated. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 17:51:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2E4C37B401 for ; Tue, 5 Nov 2002 17:51:49 -0800 (PST) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4F6E43E75 for ; Tue, 5 Nov 2002 17:51:48 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from amduat.net (trilluser@osiris.amduat.net [10.0.0.69]) (authenticated bits=0) by aker.amduat.net (8.12.6/8.12.6) with ESMTP id gA61pf3t025286; Tue, 5 Nov 2002 17:51:41 -0800 (PST) (envelope-from jbarrett@amduat.net) Message-ID: <3DC875A5.8010408@amduat.net> Date: Tue, 05 Nov 2002 17:51:33 -0800 From: "Jacob S. Barrett" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jacob S. Barrett" Cc: freebsd-net@FreeBSD.ORG Subject: Re: VLAN tag byte swap and chop problem?? References: <3DC7F88B.8090602@amduat.net> In-Reply-To: <3DC7F88B.8090602@amduat.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well it is a bug in the em driver. It works fine on the fxp device. I am trying to debug and patch myself, but I am not familiar with the driver code so it is slow going. If anyone has any pointers on where exactly to focus or anything at all please let me know. For the short term I have worked around this by setting the vlan ids to values that are the same when the fist nibble is masked and the bytes are swapped. For example 0, 257, 517 an 1028. -Jake Jacob S. Barrett wrote: > I am not sure if I am doing something completely wrong of if I have > found some sort of bug here, but I thought I would toss it out to see if > anyone else has ever seen this. > > I have two ports on my switch configured for vlan id 5. Port 1 is > untagged and port 2 is tagged. The machine A is on port 1 and machine B > is on port 2. Machine B's card is configure with multiple vlan nodes > attached to it, including vlan id 5. I couldn't ping B from A so I > attached tcpdump to the parent interface on B to see what was happening. > So here is the strange part. The arp request from A to find B says > that it is on vlan 1280. So I set the vlan id on the switch to 1280 and > tcpdump says 5. So, id 0x0005 on the switch becomes 0x0500 on the host > and 0x0500 on the switch becomes 0x0005 on the host. So I thought maybe > a byte order problem until I tried setting the id on the switch to 18. > So the id on the switch was 0x0012 and tcpdump reported it on vlan > 0x0200. Trying other vlan IDs shows the same behavior. The id on the > framed that is delivered is byte swapped with the first nibble chopped > off. > > 0x0005 -> 0x0500 > 0x0500 -> 0x0005 > 0x0002 -> 0x0200 > 0x0200 -> 0x0002 > 0x0012 -> 0x0200 > > Here is my tcpdump from machine B (.1). Machine be is attempting to > ping machine A (.2). It shows the frame leaving as vlan 2 (0x0020) > (correct) and the reply coming back from A on vlan 512 (0x0200). > > 11:35:16.982435 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:16.982593 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > 11:35:17.992434 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:17.992604 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > 11:35:19.002467 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > (2e:2f:30:31:32:33) tell 10.126.0.1 > 11:35:19.002627 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > 0:90:27:f4:3c:9f > > So does anyone have any ideas? I am assuming this is either a > configuration issue on my part with my boxes or a bug in the vlan code > for if_em. I doubt that it is a problem with the switch firmware since > this came from a production site where vlans were used extensively. > Also, it correctly transmits the frame on the ports tagged for that > vlan. My guess is that it is in the if_em driver somewhere. If anyone > wants to tackle this let me know. > > Hardware Involved: > (1) Extreme Networks Summit 4 > (2) HP LPr Dual PIII 600MHz > (1) Intel Pro 10/100B/100+ Ethernet > (2) Intel(R) PRO/1000 > > -Jake > -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Nov 5 21: 2:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4863B37B401 for ; Tue, 5 Nov 2002 21:02:35 -0800 (PST) Received: from aker.amduat.net (aker.amduat.net [206.124.149.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67AA543E4A for ; Tue, 5 Nov 2002 21:02:30 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from amduat.net (trilluser@osiris.amduat.net [10.0.0.69]) (authenticated bits=0) by aker.amduat.net (8.12.6/8.12.6) with ESMTP id gA652E3t025625 for ; Tue, 5 Nov 2002 21:02:14 -0800 (PST) (envelope-from jbarrett@amduat.net) Message-ID: <3DC8A243.4070603@amduat.net> Date: Tue, 05 Nov 2002 21:01:55 -0800 From: "Jacob S. Barrett" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Re: VLAN tag byte swap and chop problem?? References: <3DC7F88B.8090602@amduat.net> <3DC875A5.8010408@amduat.net> In-Reply-To: <3DC7F88B.8090602@amduat.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well I think I fixed it. It works for my card atleast. I am not sure the of the correct route to get this checked and corrected in the main source tree. Seems like such a simple fix but it may only work for the chipset that I have, 82543, so someone should check on other chipsets. 2020,2021c2020,2021 < VLAN_INPUT_TAG(eh, adapter->fmp, < current_desc->special); --- > VLAN_INPUT_TAG(eh, adapter->fmp, > ntohs(current_desc->special)); Jacob S. Barrett wrote: > Well it is a bug in the em driver. It works fine on the fxp device. I > am trying to debug and patch myself, but I am not familiar with the > driver code so it is slow going. If anyone has any pointers on where > exactly to focus or anything at all please let me know. > > For the short term I have worked around this by setting the vlan ids to > values that are the same when the fist nibble is masked and the bytes > are swapped. For example 0, 257, 517 an 1028. > > -Jake > > Jacob S. Barrett wrote: > > > I am not sure if I am doing something completely wrong of if I have > > found some sort of bug here, but I thought I would toss it out to see if > > anyone else has ever seen this. > > > > I have two ports on my switch configured for vlan id 5. Port 1 is > > untagged and port 2 is tagged. The machine A is on port 1 and machine B > > is on port 2. Machine B's card is configure with multiple vlan nodes > > attached to it, including vlan id 5. I couldn't ping B from A so I > > attached tcpdump to the parent interface on B to see what was happening. > > So here is the strange part. The arp request from A to find B says > > that it is on vlan 1280. So I set the vlan id on the switch to 1280 and > > tcpdump says 5. So, id 0x0005 on the switch becomes 0x0500 on the host > > and 0x0500 on the switch becomes 0x0005 on the host. So I thought maybe > > a byte order problem until I tried setting the id on the switch to 18. > > So the id on the switch was 0x0012 and tcpdump reported it on vlan > > 0x0200. Trying other vlan IDs shows the same behavior. The id on the > > framed that is delivered is byte swapped with the first nibble chopped > > off. > > > > 0x0005 -> 0x0500 > > 0x0500 -> 0x0005 > > 0x0002 -> 0x0200 > > 0x0200 -> 0x0002 > > 0x0012 -> 0x0200 > > > > Here is my tcpdump from machine B (.1). Machine be is attempting to > > ping machine A (.2). It shows the frame leaving as vlan 2 (0x0020) > > (correct) and the reply coming back from A on vlan 512 (0x0200). > > > > 11:35:16.982435 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > > (2e:2f:30:31:32:33) tell 10.126.0.1 > > 11:35:16.982593 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > > 0:90:27:f4:3c:9f > > 11:35:17.992434 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > > (2e:2f:30:31:32:33) tell 10.126.0.1 > > 11:35:17.992604 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > > 0:90:27:f4:3c:9f > > 11:35:19.002467 802.1Q vlan#2 P0 arp who-has 10.126.0.2 > > (2e:2f:30:31:32:33) tell 10.126.0.1 > > 11:35:19.002627 802.1Q vlan#512 P0 arp reply 10.126.0.2 is-at > > 0:90:27:f4:3c:9f > > > > So does anyone have any ideas? I am assuming this is either a > > configuration issue on my part with my boxes or a bug in the vlan code > > for if_em. I doubt that it is a problem with the switch firmware since > > this came from a production site where vlans were used extensively. > > Also, it correctly transmits the frame on the ports tagged for that > > vlan. My guess is that it is in the if_em driver somewhere. If anyone > > wants to tackle this let me know. > > > > Hardware Involved: > > (1) Extreme Networks Summit 4 > > (2) HP LPr Dual PIII 600MHz > > (1) Intel Pro 10/100B/100+ Ethernet > > (2) Intel(R) PRO/1000 > > > > -Jake > > > -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 0: 2:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4894637B401 for ; Wed, 6 Nov 2002 00:02:48 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0739A43E7B for ; Wed, 6 Nov 2002 00:02:47 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gA682huO017453; Wed, 6 Nov 2002 10:02:43 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <05af01c2856a$f103c960$862a40c1@PHE> From: "Petri Helenius" To: "Barney Wolff" Cc: References: <03fe01c28386$186fed80$862a40c1@PHE> <20021103225402.GA28812@tp.databus.com> Subject: Re: bpf Date: Wed, 6 Nov 2002 10:03:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I believe you're misunderstanding the meaning of the timeout in select(2). > Timeout applies only when no FDs are ready. The specific problem with bpf is that one might have a half-full buffer of captured data when the select timeout hits. In that case the select returns with no FDs ready while I think it really should return with the bpf fd. (and if you look at the code on sys/net/bpf.c, there is timeout handling towards that goal) but I´ve yet to figure out where it goes wrong. IMO, at timeout the code should check if bd_slen > 0 and if yes, do ROTATE_BUFFERS and bpf_wakeup() Unfortunately I´m not a kernel wizard enough to have fixed this, at least not yet. The functionality I´m looking for is to get all the packets accumulated, say in 1 second in single read regardless of if I got a buffer´s full of data. > > Also, you might be better off setting immediate mode on your bpf fd, > if you want a return before the buffer is full. > Immediate mode practically causes the reader to be waken up for every packet, ending up with huge number of small reads which is highly ineffective. Pete > On Mon, Nov 04, 2002 at 12:12:26AM +0200, Petri Helenius wrote: > > > > I believe the select operation on bpf is not functioning as supposed to. > > I?m calling select with 100ms timeout. The bpf interface is listening to > > an interface with constant packet rate, so it?s certain that multiple packets > > have been received during the select call. However the fd for the bpf > > device is not set until the bpf buffer is full. (which might be several seconds > > away since I?m using fairly large bpf buffers) > > > > Looking at the code I get the impression that if there are packets on the bpf > > buffer when the select timeouts, it should return the fd for the bpf ? > > > > Pete > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 2:32:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5236E37B401 for ; Wed, 6 Nov 2002 02:32:43 -0800 (PST) Received: from exch01.megadat.com (exchange.megadat.com [195.22.224.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8ADF43E91 for ; Wed, 6 Nov 2002 02:32:41 -0800 (PST) (envelope-from VGirnet@MEGADAT.COM) Subject: ICMP question MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2002 12:32:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ICMP question Thread-Index: AcKFf9hvwVBUTx9IRfm/jvg8Enb4OQ== From: "Girnet Vladimir" To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I'm using FreeBSD for routing and shaping in my company. Now, I have a problem: each time the pipe queue is full, the router = sends : ICMP: Source quench. Please, help me to disable this message. Looking forward to your reply, Vladimir Girnet "MEGADAT.COM" S.R.L. MOLDOVA, Chisinau www.mdl.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 3: 8:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E38A37B401 for ; Wed, 6 Nov 2002 03:08:27 -0800 (PST) Received: from hotmail.com (f77.law15.hotmail.com [64.4.23.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56A2D43E3B for ; Wed, 6 Nov 2002 03:08:27 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 Nov 2002 03:08:27 -0800 Received: from 62.60.130.14 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 06 Nov 2002 11:08:26 GMT X-Originating-IP: [62.60.130.14] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: A Question About NetGraph ???? Date: Wed, 06 Nov 2002 11:08:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Nov 2002 11:08:27.0222 (UTC) FILETIME=[D4CDA760:01C28584] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list; i read NG manual and i cannot get something : 1. is NG just for FreeBSD nodes connection 2. is NG for p2p connection 3. can i use 2 Nodes like this ... LAN ---TCP/IP---NG1---NG connection------NG2---TCP/IP-----WAN lan doesn't have the ng run on it and also WAN but between 2 ng-nodes i can have NG connection 4. is the data messages between 2 nodes are compressed THANX _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 3:10: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F89A37B401; Wed, 6 Nov 2002 03:10:08 -0800 (PST) Received: from hotmail.com (f22.law15.hotmail.com [64.4.23.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC7BB43E75; Wed, 6 Nov 2002 03:10:07 -0800 (PST) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 6 Nov 2002 03:10:07 -0800 Received: from 62.60.130.14 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 06 Nov 2002 11:10:07 GMT X-Originating-IP: [62.60.130.14] From: "soheil soheil" To: freebsd-net@freebsd.org Subject: SPOOFING & NG Date: Wed, 06 Nov 2002 11:10:07 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Nov 2002 11:10:07.0719 (UTC) FILETIME=[10B44770:01C28585] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org HI net'ers !! i read some message on the list archive and someone says that we can use spoofing with ng how can i do spooging with ng like this ??? WAN ------- spoofer ( one ng node ) ------- lan THANX _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 3:14: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 544E237B401 for ; Wed, 6 Nov 2002 03:14:01 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4955443E3B for ; Wed, 6 Nov 2002 03:13:54 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 189O7p-000NQR-00; Wed, 06 Nov 2002 13:13:33 +0200 Date: Wed, 6 Nov 2002 13:13:33 +0200 (EET) From: Iasen Kostov To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: <200211052106.gA5L6igd039808@arch20m.dellroad.org> Message-ID: <20021106120422.G80368-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 5 Nov 2002, Archie Cobbs wrote: > Iasen Kostov writes: > > As I experience system crushes at time of mbufs exhaustion I've compiled > > a debug kernel and traced the problem. I seems the NFS functions > > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have > > allocated memory by MGET macro. > > No check is necessary if M_WAIT is specified; the M_GET() function > is always successful in that case. Same for malloc(). If that was true, I should not see any traps 12 , should I ? :) In case of nfsm_reqh MGET() called as MGET(mb, M_WAIT, MT_DATA) returns NULL in casese of mbuf exhaustion. this is fix/test a add to nfsm_reqh() function: nfs/nfs_subs.c:591 MGET(mb, M_WAIT, MT_DATA); /* * This becomes true when there is no more mbufs available. * If you don't belive me - test it :) */ if(mb == 0) { printf("nfsm_reqh: no memory for header\n"); return NULL; } If there was not this check - kernel crushes at this point: nfs/nfs_subs.c:592 // Of the original file if (hsiz >= MINCLSIZE) { MCLGET(mb, M_WAIT); } Here is the panic message: IdlePTD at phsyical address 0x00326000 initial pcb at physical address 0x00299ba0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d1864 stack pointer = 0x10:0xcd717d68 frame pointer = 0x10:0xcd717d7c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 167 (ls) interrupt mask = none trap number = 12 panic: page fault And backtrace: #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc015182b in boot (howto=256) at ../../kern/kern_shutdown.c:316 #2 0xc0151c50 in poweroff_wait (junk=0xc02734ec, howto=-1071173617) at ../../kern/kern_shutdown.c:595 #3 0xc0241382 in trap_fatal (frame=0xcd717d28, eva=12) at ../../i386/i386/trap.c:974 #4 0xc0241055 in trap_pfault (frame=0xcd717d28, usermode=0, eva=12) at ../../i386/i386/trap.c:867 #5 0xc0240c3f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 0, tf_ebp = -848200324, tf_isp = -848200364, tf_ebx = 1, tf_edx = 0, tf_ecx = 6685184, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071835036, tf_cs = 8, tf_eflags = 66183, tf_esp = 512, tf_ss = -848199992}) at ../../i386/i386/trap.c:466 #6 0xc01d1864 in nfsm_reqh (vp=0xcd70dc00, procid=4, hsiz=72, bposp=0xcd717dc0) at ../../nfs/nfs_subs.c:593 #7 0xc01d83c5 in nfs3_access_otw (vp=0xcd70dc00, wmode=63, p=0xcbff2080, cred=0xc131b100) at ../../nfs/nfs_vnops.c:292 #8 0xc01d8dab in nfs_getattr (ap=0xcd717e20) at ../../nfs/nfs_vnops.c:637 #9 0xc018660f in vn_stat (vp=0xcd70dc00, sb=0xcd717ec8, p=0xcbff2080) at vnode_if.h:276 #10 0xc01865cc in vn_statfile (fp=0xc1320fc0, sb=0xcd717ec8, p=0xcbff2080) at ../../kern/vfs_vnops.c:451 #11 0xc01468cf in fstat (p=0xcbff2080, uap=0xcd717f80) at ../../sys/file.h:206 . . . (kgdb) l nfs_subs.c:593 588 struct nfsmount *nmp; 589 int nqflag; 590 591 MGET(mb, M_WAIT, MT_DATA); << Here MGET returns NULL in mb (I'm sure - I saw it :) 592 if (hsiz >= MINCLSIZE) 593 MCLGET(mb, M_WAIT); << At this point kernel crushes 594 mb->m_len = 0; 595 bpos = mtod(mb, caddr_t); 596 597 /* As you said - MGET used with M_WAIT flag should never return NULL pointer. Is this a problem with MGET macro or it is somewhere in functions that it calls? But wherever is the problem it is a big problem :). It make (at least) NFS servers unstable and could lead to data loss (when kernel crashes). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 3:22:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C17737B401; Wed, 6 Nov 2002 03:22:51 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE4FB43E6E; Wed, 6 Nov 2002 03:22:50 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA6BMlpk001965; Wed, 6 Nov 2002 04:22:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 06 Nov 2002 04:22:33 -0700 (MST) Message-Id: <20021106.042233.54624374.imp@bsdimp.com> To: myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) From: "M. Warner Losh" In-Reply-To: References: <3DC82EB5.7974429D@exodus.net> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org : 1) Device driver in Netgraph node. When hardware is : activated new Netgraph node is created and new : kevent sent. devd (or something like devd) listens : for these events and does something (loads firmware, : activates device, etc.) Device drivers are not netgraph nodes. They will have a device_t associated with them, which already sends a message via /dev/devctl to devd. You can do anything you want with the results. There's no need to reinvent the wheel that I'm almost done inventing. There's absolutely no need to bring netgraph into it all, and doing so makes it a less generic implementation. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 3:56:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FAA237B401 for ; Wed, 6 Nov 2002 03:56:28 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C47D543E3B for ; Wed, 6 Nov 2002 03:56:26 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id gA6BuDl02538; Wed, 6 Nov 2002 12:56:13 +0100 (MET) Date: Wed, 6 Nov 2002 12:56:13 +0100 (CET) From: Harti Brandt To: Iasen Kostov Cc: Archie Cobbs , Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: <20021106120422.G80368-100000@shadowhand.OTEL.net> Message-ID: <20021106125444.K20974-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 6 Nov 2002, Iasen Kostov wrote: IK> IK> IK>On Tue, 5 Nov 2002, Archie Cobbs wrote: IK> IK>> Iasen Kostov writes: IK>> > As I experience system crushes at time of mbufs exhaustion I've compiled IK>> > a debug kernel and traced the problem. I seems the NFS functions IK>> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have IK>> > allocated memory by MGET macro. IK>> IK>> No check is necessary if M_WAIT is specified; the M_GET() function IK>> is always successful in that case. Same for malloc(). Wrong. malloc() returns always successful with M_WAIT, M_GET not. There is a timeout the M_GET() will wait, but the it will return NULL. harti To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 5:11:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F4A537B401 for ; Wed, 6 Nov 2002 05:11:53 -0800 (PST) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2A2843E75 for ; Wed, 6 Nov 2002 05:11:52 -0800 (PST) (envelope-from joe@genius.tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id 75DCB4436; Wed, 6 Nov 2002 13:11:24 +0000 (GMT) Date: Wed, 6 Nov 2002 13:11:24 +0000 From: Josef Karthauser To: Anton Vinokurov Cc: freebsd-net@freebsd.org Subject: Re: USB ethernet problem Message-ID: <20021106131124.GA8620@genius.tao.org.uk> References: <008b01c284f5$f7b603b0$14d1d0c3@main.inorg.chem.msu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <008b01c284f5$f7b603b0$14d1d0c3@main.inorg.chem.msu.ru> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 05, 2002 at 09:05:47PM +0300, Anton Vinokurov wrote: > Hi! >=20 > I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet > adapter. Unfortunately it causes my system to print something like: > kue0: watchdog timeout > kue0: usb error on tx: TIMEOUT > following by freeze. I got this problem while forwarding 50pps/64kbit UDP > packet stream which comes from Cisco ATA186 voice gateway in several minu= tes > after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver > works fine at least under one day voice traffic load. I tried original > driver and altq modifed with no success. > Could someone suggest me a way to fix my problem? There are a number of bugs in the usb stack in -stable, which are waiting for a merge from -current to get fixed. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iEYEARECAAYFAj3JFPsACgkQXVIcjOaxUBYJqwCfddQGysTWN9o8d63RixZB4+ZT wSAAoNPAHxVYUAYV/UyTAI4tvvmUeN0q =Q3ip -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 8:16:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D8D37B401 for ; Wed, 6 Nov 2002 08:16:21 -0800 (PST) Received: from coo.demizu.org (coo.demizu.org [61.194.197.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D943043E75 for ; Wed, 6 Nov 2002 08:16:19 -0800 (PST) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (localhost [127.0.0.1]) by coo.demizu.org (8.12.3/8.12.3) with ESMTP id gA6GHkKM000710; Thu, 7 Nov 2002 01:17:47 +0900 (JST) (envelope-from demizu@dd.iij4u.or.jp) Date: Thu, 07 Nov 2002 01:17:46 +0900 (JST) Message-Id: <20021107.011746.41626604.noritosi@demizu.org> From: Noritoshi Demizu To: pete@he.iki.fi Cc: freebsd-net@FreeBSD.ORG Subject: Re: bpf In-Reply-To: <05af01c2856a$f103c960$862a40c1@PHE> <03fe01c28386$186fed80$862a40c1@PHE> References: <03fe01c28386$186fed80$862a40c1@PHE> <20021103225402.GA28812@tp.databus.com> <05af01c2856a$f103c960$862a40c1@PHE> X-Mailer: Mew version 3.0.66 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I believe the select operation on bpf is not functioning as supposed to. > I'm calling select with 100ms timeout. The bpf interface is listening to > an interface with constant packet rate, so it's certain that multiple > packets have been received during the select call. However the fd for > the bpf device is not set until the bpf buffer is full. (which might be > several seconds away since I'm using fairly large bpf buffers) How about to call ioctl(fd, BIOCSRTIMEOUT, &timeval) ? I think select(2) sets the fd for the bpf if the bpf buffer is full, or if the bpf buffer is not empty after timed out. If you also want select(2) sets the fd for the bpf in the case where the bpf buffer is empty after timed out (I guess you do not want...:-), you might want the following patch. Actually, I had a different problem when I use pcap/bpf on pthread environment; The fourth argument 'read-timeout' of pcap_open_live() does not work when the bpf buffer is empty. The following patch solved my problem. I think it could also be applied to your case. In the read(2) system call procedure, the difference between with/without pthread is that bpfread() is called when without pthread, while bpfpoll() is called when with pthread. Note: in the select(2) system call procedure, bpfpoll() is called. On timed out, bpfread() returns even if d->bd_slen == 0. On the other hand, on timed out, bpfpoll() returns POLLIN|POLLRDNORM bits only if d->bd_slen != 0. The following patch makes bpfpoll() returns POLLIN|POLLRDNORM bits even if d->bd_slen == 0 on timed out and also makes bpfread() returns 0 after bpfpoll() returns those bits. Noritoshi ========================================================================= <> --- sys/net/bpf.c-ORG Mon Apr 15 06:41:48 2002 +++ sys/net/bpf.c Wed Oct 2 16:55:53 2002 @@ -480,7 +480,7 @@ * have arrived to fill the store buffer. */ while (d->bd_hbuf == 0) { - if ((d->bd_immediate || timed_out) && d->bd_slen != 0) { + if (d->bd_immediate && d->bd_slen != 0) { /* * A packet(s) either arrived since the previous * read or arrived while we were asleep. @@ -488,6 +488,8 @@ */ ROTATE_BUFFERS(d); break; + } else if (timed_out) { + goto timedout; } /* @@ -512,6 +514,7 @@ return (error); } if (error == EWOULDBLOCK) { + timedout: /* * On a timeout, return what's in the buffer, * which may be nothing. If there is something @@ -1095,8 +1098,8 @@ * (d->bd_hbuf != NULL && d->bd_hlen != 0) */ if (d->bd_hlen != 0 || - ((d->bd_immediate || d->bd_state == BPF_TIMED_OUT) && - d->bd_slen != 0)) + (d->bd_immediate && d->bd_slen != 0) || + d->bd_state == BPF_TIMED_OUT) revents |= events & (POLLIN | POLLRDNORM); else { selrecord(p, &d->bd_sel); ========================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 8:20:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7488637B401 for ; Wed, 6 Nov 2002 08:20:21 -0800 (PST) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD33B43E42 for ; Wed, 6 Nov 2002 08:20:20 -0800 (PST) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id gA6GKD5s060568; Wed, 6 Nov 2002 11:20:13 -0500 (EST) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id gA6GKD23060567; Wed, 6 Nov 2002 11:20:13 -0500 (EST) Date: Wed, 6 Nov 2002 11:20:13 -0500 From: Barney Wolff To: Petri Helenius Cc: Barney Wolff , freebsd-net@FreeBSD.ORG Subject: Re: bpf Message-ID: <20021106162013.GA60489@tp.databus.com> References: <03fe01c28386$186fed80$862a40c1@PHE> <20021103225402.GA28812@tp.databus.com> <05af01c2856a$f103c960$862a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05af01c2856a$f103c960$862a40c1@PHE> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Nov 06, 2002 at 10:03:06AM +0200, Petri Helenius wrote: > > The specific problem with bpf is that one might have a half-full buffer > of captured data when the select timeout hits. In that case the select > returns with no FDs ready while I think it really should return with > the bpf fd. (and if you look at the code on sys/net/bpf.c, there is > timeout handling towards that goal) but I?ve yet to figure out where it goes > wrong. > > IMO, at timeout the code should check if bd_slen > 0 and if yes, > do ROTATE_BUFFERS and bpf_wakeup() The bpf timeout has nothing to do with the select timeout. Two separate facilities. > The functionality I?m looking for is to get all the packets accumulated, say > in 1 second in single read regardless of if I got a buffer?s full of data. Then do a select with no FDs just to get a periodic wakeup. Then at wakeup do the bpf read, having set nonblocking and immediate mode so you don't get stuck in the read. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 8:30:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 619ED37B401 for ; Wed, 6 Nov 2002 08:30:12 -0800 (PST) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9304C43E3B for ; Wed, 6 Nov 2002 08:30:11 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA42961; Wed, 6 Nov 2002 08:19:39 -0800 (PST) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id gA6GJasb002594; Wed, 6 Nov 2002 08:19:36 -0800 (PST) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id gA6GJZ93002593; Wed, 6 Nov 2002 08:19:35 -0800 (PST) From: Archie Cobbs Message-Id: <200211061619.gA6GJZ93002593@arch20m.dellroad.org> Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: <20021106125444.K20974-100000@beagle.fokus.gmd.de> "from Harti Brandt at Nov 6, 2002 12:56:13 pm" To: Harti Brandt Date: Wed, 6 Nov 2002 08:19:35 -0800 (PST) Cc: Iasen Kostov , Archie Cobbs , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Harti Brandt writes: > IK>> > As I experience system crushes at time of mbufs exhaustion I've compiled > IK>> > a debug kernel and traced the problem. I seems the NFS functions > IK>> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have > IK>> > allocated memory by MGET macro. > IK>> > IK>> No check is necessary if M_WAIT is specified; the M_GET() function > IK>> is always successful in that case. Same for malloc(). > > Wrong. malloc() returns always successful with M_WAIT, M_GET not. There > is a timeout the M_GET() will wait, but the it will return NULL. Oops, you're right.. sorry for the misinformation. Sounds like a bug to me (did Iasen file a PR?) -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 8:52:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78AD037B404 for ; Wed, 6 Nov 2002 08:52:25 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 2CB5543E42 for ; Wed, 6 Nov 2002 08:52:24 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 6 Nov 2002 16:52:17 +0000 (GMT) To: Archie Cobbs Cc: Harti Brandt , Iasen Kostov , freebsd-net@FreeBSD.org Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: Your message of "Wed, 06 Nov 2002 08:19:35 PST." <200211061619.gA6GJZ93002593@arch20m.dellroad.org> Date: Wed, 06 Nov 2002 16:52:14 +0000 From: Ian Dowse Message-ID: <200211061652.aa61159@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <200211061619.gA6GJZ93002593@arch20m.dellroad.org>, Archie Cobbs wri tes: >Oops, you're right.. sorry for the misinformation. > >Sounds like a bug to me (did Iasen file a PR?) kern/38872 already exists, and I'm sure there is a much older PR that also describes this problem. Basically it is hard to fix because the errors are detected so deep within functions and macros that were never designed to correctly handle mbuf allocation failures. I think the most feasable solution would be to use libmchain or something like it, but even that is a huge amount of work. The workaround is of course just setting nmbclusters/nmbufs so high that they never run out... Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 8:54:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E10737B401; Wed, 6 Nov 2002 08:54:43 -0800 (PST) Received: from cheer.mahoroba.org (flets20-027.kamome.or.jp [218.45.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6850243E75; Wed, 6 Nov 2002 08:54:31 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:Kc5VZOCDT4eFX0XoejySjWPFKvCNPR/2lasSUTWPiCOwfWIkyAZFac3LG2LAqrJN@lyrics.mahoroba.org [IPv6:3ffe:505:2:0:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.6/8.12.6) with ESMTP/inet6 id gA6GsIKv007649 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 01:54:18 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 07 Nov 2002 01:54:18 +0900 Message-ID: From: Hajimu UMEMOTO To: Maxime Henrion Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable In-Reply-To: <20021106010040.GJ26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> User-Agent: xcite1.38> Wanderlust/2.9.15 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Tue, 5 Nov 2002 17:00:40 -0800 >>>>> Maxime Henrion said: mux> ipv6_enable="YES" mux> ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) mux> ipv6_prefix_xl1="2002:5143:8351:" mux> stf_interface_ipv4addr="81.67.131.81" It seems you do configure your box as follows: (6to4 router) | 2002:c058:6301:: | | | stf0 | 2002:5143:8351:0::1 (your box) | xl1 | 2002:5143:8351:0:EUI-64 | ------+------------------------------------ 2002:5143:8351:0::/64 You cannot share 2002:5143:8351:0::/64 between xl1 and stf0. Please don't use same SLA-ID for xl1 and stf0. If you want to use 0 for stf0 (default of stf_interface_ipv6_slaid), please use non-zero SLA-ID for xl1 like: ipv6_prefix_xl1="2002:5143:8351:1" Or, if you want to use 0 for xl1, please set stf_interface_ipv6_slaid. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 9:25:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ABFD37B401 for ; Wed, 6 Nov 2002 09:25:34 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD6A43E3B for ; Wed, 6 Nov 2002 09:25:34 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 1D656AE275; Wed, 6 Nov 2002 09:25:34 -0800 (PST) Date: Wed, 6 Nov 2002 09:25:34 -0800 From: Maxime Henrion To: Hajimu UMEMOTO Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable Message-ID: <20021106172533.GQ26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 5 Nov 2002 17:00:40 -0800 > >>>>> Maxime Henrion said: > > mux> ipv6_enable="YES" > mux> ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) > mux> ipv6_prefix_xl1="2002:5143:8351:" > mux> stf_interface_ipv4addr="81.67.131.81" > > It seems you do configure your box as follows: > > (6to4 router) > | 2002:c058:6301:: > | > | > | stf0 > | 2002:5143:8351:0::1 > (your box) > | xl1 > | 2002:5143:8351:0:EUI-64 > | > ------+------------------------------------ > 2002:5143:8351:0::/64 > > You cannot share 2002:5143:8351:0::/64 between xl1 and stf0. Please > don't use same SLA-ID for xl1 and stf0. If you want to use 0 for stf0 > (default of stf_interface_ipv6_slaid), please use non-zero SLA-ID for > xl1 like: > > ipv6_prefix_xl1="2002:5143:8351:1" > > Or, if you want to use 0 for xl1, please set stf_interface_ipv6_slaid. I changed my ipv6_prefix_xl1 variable as you suggested, and I'm not getting any errors at boot now, thanks! However, it still doesn't seem to work properly. When pinging an IPv6 host from a box in my local subnet, I'm getting this warning on the box running rtadvd(8) : cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, nxt 58, rcvif xl0, outif stf0 And I don't receive any ping back, though it works if I ping from the router. Moreover, the boot scripts still display : IPv4 mapped IPv6 address support=NO Even though stf(4) is configured properly. Any ideas ? Thanks, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 9:46:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D64E537B401 for ; Wed, 6 Nov 2002 09:46:42 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74E4A43E75 for ; Wed, 6 Nov 2002 09:46:40 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 189UFZ-0005IS-00; Wed, 06 Nov 2002 19:45:57 +0200 Date: Wed, 6 Nov 2002 19:45:57 +0200 (EET) From: Iasen Kostov To: Ian Dowse Cc: Archie Cobbs , Harti Brandt , Subject: Re: NFS functions does *NOT* check if they really have allocated any memory In-Reply-To: <200211061652.aa61159@salmon.maths.tcd.ie> Message-ID: <20021106193326.J80368-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 6 Nov 2002, Ian Dowse wrote: > In message <200211061619.gA6GJZ93002593@arch20m.dellroad.org>, Archie Cobbs wri > tes: > >Oops, you're right.. sorry for the misinformation. > > > >Sounds like a bug to me (did Iasen file a PR?) > > kern/38872 already exists, and I'm sure there is a much older PR > that also describes this problem. Basically it is hard to fix because > the errors are detected so deep within functions and macros that > were never designed to correctly handle mbuf allocation failures. > > I think the most feasable solution would be to use libmchain or > something like it, but even that is a huge amount of work. The > workaround is of course just setting nmbclusters/nmbufs so high > that they never run out... I don't think that is a proper way go around such bug. Thus when you are DoS-ed how can you know how much mbuf you will need ?:). My problem apeared at the moment I've tried to scan 192.168.0.0/16 with nbtscan. Mbufs were exhausted for about 2-3 second. At that moment there was NFS activity - So server crashed... Ok I won't do that again - but someone else ? And how many parts of the kernel are afected by this problem. Raising nmbclusters/nmbufs at same scan with nbtscan will give my server about 2-3 second more life. That is no good and if someone DoS-es you (local user for example) no nmbclusters/nmbufs raising will save you. Can MGET really wait for memory when M_WAIT flag is used and not to timeouts (I don't know howlong is this timeout, but system crushes at the moment of first NFS operation , thus it should be < 10ms :) ? > Ian > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 10: 0:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CEE437B401; Wed, 6 Nov 2002 10:00:33 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BDFD43E4A; Wed, 6 Nov 2002 10:00:33 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA01078; Wed, 6 Nov 2002 09:43:51 -0800 (PST) Date: Wed, 6 Nov 2002 09:43:50 -0800 (PST) From: Julian Elischer To: "M. Warner Losh" Cc: myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) In-Reply-To: <20021106.042233.54624374.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 6 Nov 2002, M. Warner Losh wrote: > : 1) Device driver in Netgraph node. When hardware is > : activated new Netgraph node is created and new > : kevent sent. devd (or something like devd) listens > : for these events and does something (loads firmware, > : activates device, etc.) > > Device drivers are not netgraph nodes. They will have a device_t > associated with them, which already sends a message via /dev/devctl to > devd. You can do anything you want with the results. There's no need > to reinvent the wheel that I'm almost done inventing. There's > absolutely no need to bring netgraph into it all, and doing so makes > it a less generic implementation. devices that are netgraph nodes may not have any entry in /dev and might only appear in the netgraph namespace.. e.g. if_ar.c if_sr.c > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 10: 4:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C091337B401 for ; Wed, 6 Nov 2002 10:04:09 -0800 (PST) Received: from orfeas.asda.gr (orfeas.asda.gr [194.219.142.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DED7143E42 for ; Wed, 6 Nov 2002 10:04:07 -0800 (PST) (envelope-from lefty@ene.asda.gr) Received: from ene.asda.gr (lefty.ene.asda.gr [193.92.118.162]) by orfeas.asda.gr (8.11.6/8.11.6) with SMTP id gA6I43h23390; Wed, 6 Nov 2002 20:04:03 +0200 Message-ID: <3DC95997.C06A8841@ene.asda.gr> Date: Wed, 06 Nov 2002 20:04:07 +0200 From: Lefteris Tsintjelis X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,el MIME-Version: 1.0 To: Andrea Venturoli Cc: freebsd-net@FreeBSD.ORG Subject: Re: Dial in only works for a while References: <200211051730.gA5HUXR14771@relay.flashnet.it> Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrea Venturoli wrote: > I don't really understand the reason why either the modem or the serial port would change their setting spontaneously. You are right. They don't. > Let's deal with the serial port: it's initialized at boot time by rc.serial, so a reboot should have set it up right. > In any case wouldn't "sh /etc/rc.serial" be enough to solve the matter in case for some reasons it wasn't > properly configured? It all depends on how you want your serial port set. I think it is initially set at 9600. > Besides, stty showed a speed of 57600 bps, so I think it was not the problem. > > The modem: doing an ATI4 shows a speed of 57600 (obviously after issuing cu -s), while ATI5 shows 9600 and 115200 > respectively for the two stored profiles. But again, now that it is working at this speed, why should it change? It shouldn't, unless it has been accessed by something else. > Furthermore, I often find that cu will only run once; after that, I get a "line in use" message, although ps shows no > process using /dev/cuaa0 (there is getty on /dev/ttyd0, but that's also true the first time I run cu). Is there > anything I can do to solve this without rebooting? Try resetting the modem instead. Try this: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html Keep also in mind that by setting the serial port to a speed doesn't necessarily mean setting the modem to that speed also. All modern modems are auto detect so by simply typing anything to it the modem's parameters are auto set. However, I would recommend to lock your serial port AND modem's serial speed to a fixed rate and best one is 115200 (or even higher if you have), specially if you are using your modem's hardware compression. I can't recall the AT commands of your 3Com but I think your modem might have some online help. I think its AT$. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 10: 5:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D80337B401; Wed, 6 Nov 2002 10:05:34 -0800 (PST) Received: from cheer.mahoroba.org (flets20-027.kamome.or.jp [218.45.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF0843E75; Wed, 6 Nov 2002 10:05:32 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:zTQ7x687MBaad/TsVpzcgc4kiMRwpF95lIz2ezWoM4JiUKIQkmKBl1+2+rp7XXrR@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.6/8.12.6) with ESMTP/inet6 id gA6I5PKv026123 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 03:05:25 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 07 Nov 2002 03:05:24 +0900 Message-ID: From: Hajimu UMEMOTO To: Maxime Henrion Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable In-Reply-To: <20021106172533.GQ26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> <20021106172533.GQ26605@elvis.mu.org> User-Agent: xcite1.38> Wanderlust/2.9.15 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Wed, 6 Nov 2002 09:25:34 -0800 >>>>> Maxime Henrion said: mux> However, it still doesn't seem to work properly. When pinging an IPv6 mux> host from a box in my local subnet, I'm getting this warning on the box mux> running rtadvd(8) : mux> cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, nxt 58, rcvif xl0, outif stf0 I suspect your box which you did ping6 from doesn't configure global address properly. I read your previous mail again, then found one more suspicious setting as follows: ipv6_prefix_xl1="2002:5143:8351:" rtadvd_interfaces="xl0" You need to advertise the prefix to the configured interface. If your actuall interface is xl1, please set xl1 to rtadvd_interfaces. mux> router. Moreover, the boot scripts still display : mux> IPv4 mapped IPv6 address support=NO You don't need to worry about this message. It shows that you don't use mapped address. It is default of 5-CURRENT. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 10:20:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 431FF37B401 for ; Wed, 6 Nov 2002 10:20:35 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0470043E6E for ; Wed, 6 Nov 2002 10:20:35 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id F358CAE312; Wed, 6 Nov 2002 10:20:30 -0800 (PST) Date: Wed, 6 Nov 2002 10:20:30 -0800 From: Maxime Henrion To: Hajimu UMEMOTO Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable Message-ID: <20021106182030.GR26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> <20021106172533.GQ26605@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Wed, 6 Nov 2002 09:25:34 -0800 > >>>>> Maxime Henrion said: > > mux> However, it still doesn't seem to work properly. When pinging an IPv6 > mux> host from a box in my local subnet, I'm getting this warning on the box > mux> running rtadvd(8) : > > mux> cannot forward src fe80:0001::0a00:20ff:fef9:8c7a, dst 3ffe:8114:1000::036b, nxt 58, rcvif xl0, outif stf0 > > I suspect your box which you did ping6 from doesn't configure global > address properly. I read your previous mail again, then found one > more suspicious setting as follows: > > ipv6_prefix_xl1="2002:5143:8351:" > rtadvd_interfaces="xl0" > > You need to advertise the prefix to the configured interface. If your > actuall interface is xl1, please set xl1 to rtadvd_interfaces. Well, my interface which is connected to the net is xl1. The interface connected to the local subnet is xl0. If I change rtadvd_interfaces to xl1, ping6 on the box behind the router gets a no route to host while the DNS lookup worked before, but I wasn't getting any replies. Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-). Thanks, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 10:44:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D0F37B401; Wed, 6 Nov 2002 10:44:13 -0800 (PST) Received: from cheer.mahoroba.org (flets20-027.kamome.or.jp [218.45.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1943943E88; Wed, 6 Nov 2002 10:44:12 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:/cptBDjLrHzErIIoIEu0+n9s8EhvNetELpCZtDXvZvt+C50rIJxnoSNE2sVLtFF2@lyrics.mahoroba.org [IPv6:3ffe:505:2:0:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.6/8.12.6) with ESMTP/inet6 id gA6Ii9Kv010804 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 03:44:09 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 07 Nov 2002 03:44:09 +0900 Message-ID: From: Hajimu UMEMOTO To: Maxime Henrion Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable In-Reply-To: <20021106182030.GR26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> <20021106172533.GQ26605@elvis.mu.org> <20021106182030.GR26605@elvis.mu.org> User-Agent: xcite1.38> Wanderlust/2.9.15 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Wed, 6 Nov 2002 10:20:30 -0800 >>>>> Maxime Henrion said: mux> Well, my interface which is connected to the net is xl1. The interface mux> connected to the local subnet is xl0. If I change rtadvd_interfaces to mux> xl1, ping6 on the box behind the router gets a no route to host while mux> the DNS lookup worked before, but I wasn't getting any replies. Now, I see your network. mux> Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-). Yes, you need to set a prefix to xl0. Rtadvd(8) takes a prefix from an interface which rtadvd(8) advertises a prefix. You are confusing about tunnel setup, not IPv6 actually. :-) Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 11: 2:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E09AE37B401 for ; Wed, 6 Nov 2002 11:02:28 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FD1A43E3B for ; Wed, 6 Nov 2002 11:02:28 -0800 (PST) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 76137AE2C5; Wed, 6 Nov 2002 11:02:28 -0800 (PST) Date: Wed, 6 Nov 2002 11:02:28 -0800 From: Maxime Henrion To: Hajimu UMEMOTO Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable Message-ID: <20021106190228.GS26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> <20021106172533.GQ26605@elvis.mu.org> <20021106182030.GR26605@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hajimu UMEMOTO wrote: > Hi, > mux> Well, my interface which is connected to the net is xl1. The interface > mux> connected to the local subnet is xl0. If I change rtadvd_interfaces to > mux> xl1, ping6 on the box behind the router gets a no route to host while > mux> the DNS lookup worked before, but I wasn't getting any replies. > > Now, I see your network. > > mux> Maybe I should set a prefix for xl0 too ? I really suck at IPv6 :-). > > Yes, you need to set a prefix to xl0. Rtadvd(8) takes a prefix from > an interface which rtadvd(8) advertises a prefix. > You are confusing about tunnel setup, not IPv6 actually. :-) Sorry to ask you about this again, but I have no idea what to set as a prefix for xl0. Does 2002:5143:8351:2 sounds sane? The prefix for xl1 is 2002:5143:8351:1 as you suggested. Thanks again, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 11: 9:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F5F937B401; Wed, 6 Nov 2002 11:09:16 -0800 (PST) Received: from cheer.mahoroba.org (flets20-027.kamome.or.jp [218.45.20.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E090D43E4A; Wed, 6 Nov 2002 11:09:14 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (IDENT:csQACOxZrMMNbZhRHyxxDe1vi1gJ0eiu1N6Xj/hLXCbpju/iMWRNuVTrl9wlNIeK@lyrics.mahoroba.org [IPv6:2001:200:301:0:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.6/8.12.6) with ESMTP/inet6 id gA6J9CKv083475 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 04:09:12 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 07 Nov 2002 04:09:12 +0900 Message-ID: From: Hajimu UMEMOTO To: Maxime Henrion Cc: net@FreeBSD.org Subject: Re: problems with stf(4) and ipv6_gateway_enable In-Reply-To: <20021106190228.GS26605@elvis.mu.org> References: <20021106010040.GJ26605@elvis.mu.org> <20021106172533.GQ26605@elvis.mu.org> <20021106182030.GR26605@elvis.mu.org> <20021106190228.GS26605@elvis.mu.org> User-Agent: xcite1.38> Wanderlust/2.9.15 (Unchained Melody) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 5.0-CURRENT MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, >>>>> On Wed, 6 Nov 2002 11:02:28 -0800 >>>>> Maxime Henrion said: mux> Sorry to ask you about this again, but I have no idea what to set as a mux> prefix for xl0. Does 2002:5143:8351:2 sounds sane? The prefix for xl1 mux> is 2002:5143:8351:1 as you suggested. Yes. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 11:56:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39EED37B404; Wed, 6 Nov 2002 11:56:43 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFD1243E42; Wed, 6 Nov 2002 11:56:40 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA6JuMpk029155; Wed, 6 Nov 2002 12:56:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 06 Nov 2002 12:55:55 -0700 (MST) Message-Id: <20021106.125555.20031393.imp@bsdimp.com> To: julian@elischer.org Cc: myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) From: "M. Warner Losh" In-Reply-To: References: <20021106.042233.54624374.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: Julian Elischer writes: : : : On Wed, 6 Nov 2002, M. Warner Losh wrote: : : > : 1) Device driver in Netgraph node. When hardware is : > : activated new Netgraph node is created and new : > : kevent sent. devd (or something like devd) listens : > : for these events and does something (loads firmware, : > : activates device, etc.) : > : > Device drivers are not netgraph nodes. They will have a device_t : > associated with them, which already sends a message via /dev/devctl to : > devd. You can do anything you want with the results. There's no need : > to reinvent the wheel that I'm almost done inventing. There's : > absolutely no need to bring netgraph into it all, and doing so makes : > it a less generic implementation. : : devices that are netgraph nodes may not have any entry in /dev : and might only appear in the netgraph namespace.. : e.g. if_ar.c if_sr.c It doesn't matter. *ALL* devices have device_t entries. Recall that device_t is not dev_t. dev_t appears in /dev/. Hardware devices have to attach to some bus. That's why devd is done in newbus land rather than in dev_t land. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 12:58:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 737AF37B401; Wed, 6 Nov 2002 12:58:25 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20D4843E91; Wed, 6 Nov 2002 12:58:24 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA00741; Wed, 6 Nov 2002 12:48:08 -0800 (PST) Date: Wed, 6 Nov 2002 12:48:07 -0800 (PST) From: Julian Elischer To: "M. Warner Losh" Cc: myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) In-Reply-To: <20021106.125555.20031393.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 6 Nov 2002, M. Warner Losh wrote: > In message: > Julian Elischer writes: > : > : > : On Wed, 6 Nov 2002, M. Warner Losh wrote: > : > : > : 1) Device driver in Netgraph node. When hardware is > : > : activated new Netgraph node is created and new > : > : kevent sent. devd (or something like devd) listens > : > : for these events and does something (loads firmware, > : > : activates device, etc.) > : > > : > Device drivers are not netgraph nodes. They will have a device_t > : > associated with them, which already sends a message via /dev/devctl to > : > devd. You can do anything you want with the results. There's no need > : > to reinvent the wheel that I'm almost done inventing. There's > : > absolutely no need to bring netgraph into it all, and doing so makes > : > it a less generic implementation. > : > : devices that are netgraph nodes may not have any entry in /dev > : and might only appear in the netgraph namespace.. > : e.g. if_ar.c if_sr.c > > It doesn't matter. *ALL* devices have device_t entries. Recall that > device_t is not dev_t. dev_t appears in /dev/. Hardware devices have > to attach to some bus. That's why devd is done in newbus land rather > than in dev_t land. Ok but there cound be netgraph nodes that have no hardware but could be called into creation by some external event. e.g. a netgraph hook on a pseudointerface like gif or tun. (not at present but a possibility I was looking at last week) > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 13: 3: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0781337B401; Wed, 6 Nov 2002 13:03:02 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838F543E6E; Wed, 6 Nov 2002 13:03:01 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id gA6L2bs7032561; Wed, 6 Nov 2002 13:02:37 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id gA6L2aRO032560; Wed, 6 Nov 2002 13:02:36 -0800 Date: Wed, 6 Nov 2002 13:02:36 -0800 From: Brooks Davis To: Julian Elischer Cc: "M. Warner Losh" , myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) Message-ID: <20021106130236.B31056@Odin.AC.HMC.Edu> References: <20021106.125555.20031393.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Wed, Nov 06, 2002 at 12:48:07PM -0800 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 06, 2002 at 12:48:07PM -0800, Julian Elischer wrote: >=20 > Ok but there cound be netgraph nodes that have no hardware but could be > called into creation by some external event. > e.g. a netgraph hook on a pseudointerface like gif or tun. > (not at present but a possibility I was looking at last week) ng_gif already exists and is in the tree. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9yYNrXY6L6fI4GtQRAhUOAJ42Jyhs6JrsEJZfcQTg4XxpJNOuowCgsqES 9MiZrOpOHJGQUq0NGFYorgQ= =mzwh -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 6 13: 3: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C96737B404; Wed, 6 Nov 2002 13:03:02 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1F5E43E88; Wed, 6 Nov 2002 13:03:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id gA6L2qpk047905; Wed, 6 Nov 2002 14:02:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 06 Nov 2002 14:02:27 -0700 (MST) Message-Id: <20021106.140227.66271045.imp@bsdimp.com> To: julian@elischer.org Cc: myevmenk@exodus.net, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Netgraph and KQUEUE(2) From: "M. Warner Losh" In-Reply-To: References: <20021106.125555.20031393.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message: Julian Elischer writes: : Ok but there cound be netgraph nodes that have no hardware but could be : called into creation by some external event. : e.g. a netgraph hook on a pseudointerface like gif or tun. : (not at present but a possibility I was looking at last week) There's an API that one could expose that would allow these sorts of things to be passed to devd. If it is a true interface, then one can discover that with routing announcements, iirc. I'd personally like to see all things in the kernel in the device tree, but there's some good reasons that this might be a touch too radical. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 4:18:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E5AF37B401 for ; Thu, 7 Nov 2002 04:18:40 -0800 (PST) Received: from relay3.flashnet.it (relay3.flashnet.it [194.247.160.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29C8843E75 for ; Thu, 7 Nov 2002 04:18:39 -0800 (PST) (envelope-from ml.ventu@flashnet.it) Received: from smtp.flashnet.it ([195.191.20.149]) by relay3.flashnet.it (/) with SMTP id gA7CIT926445 for ; Thu, 7 Nov 2002 13:18:30 +0100 Message-Id: <200211071218.gA7CIT926445@relay3.flashnet.it> To: freebsd-net@FreeBSD.ORG X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Thu, 7 Nov 2002 13:18:35 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Re: Dial in only works for a while Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ** Reply to note from Lefteris Tsintjelis Wed, 06 Nov 2002 20:04:07 +0200 >> Let's deal with the serial port: it's initialized at boot time by rc.serial, so a reboot should have set it up right. >> In any case wouldn't "sh /etc/rc.serial" be enough to solve the matter in case for some reasons it wasn't >> properly configured? >It all depends on how you want your serial port set. I think it is >initially set at 9600. I modified rc.serial so adding a "modem ..." line, according to the comments; this should set it to 57600. >> Furthermore, I often find that cu will only run once; after that, I get a "line in use" message, although ps shows no >> process using /dev/cuaa0 (there is getty on /dev/ttyd0, but that's also true the first time I run cu). Is there >> anything I can do to solve this without rebooting? >Try resetting the modem instead. This won't help: I asked someone to power the modem down and back up (it's a remote machine for me), but cuaa0 was still "in use". >Try this: >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html I had already read that carefully. >Keep also in mind that by setting the serial port to a speed doesn't >necessarily mean setting the modem to that speed also. All modern modems >are auto detect so by simply typing anything to it the modem's >parameters are auto set. However, I would recommend to lock your serial >port AND modem's serial speed to a fixed rate and best one is 115200 (or >even higher if you have), specially if you are using your modem's >hardware compression. I can't recall the AT commands of your 3Com but I >think your modem might have some online help. I think its AT$. This is what I thought I had done. I'll check again with the modem. bye & Thanks av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 9:19: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D206037B401; Thu, 7 Nov 2002 09:18:59 -0800 (PST) Received: from cisco.com (sword.cisco.com [161.44.208.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03F7443E3B; Thu, 7 Nov 2002 09:18:59 -0800 (PST) (envelope-from sjt@cisco.com) Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id MAA29653; Thu, 7 Nov 2002 12:18:58 -0500 (EST) Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id MAA08616; Thu, 7 Nov 2002 12:18:57 -0500 (EST) Date: Thu, 7 Nov 2002 12:18:57 -0500 From: Steve Tremblett To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: input source for network application Message-ID: <20021107121857.F264@sjt-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been toying with the idea of tackling a Netgraph TCP/IP implementation and want to hack out some skeleton netgraph nodes just to feel things out and play around with parsing. I'm somewhat confused on how to start. I'd like to be able to tinker as I go and I'd rather not have to write 5000 lines of code and complete a mini-stack before trying it out :) I'm in a bit of a bind. I want a sequence of ethernet frames to send up through this framework. Hooking to ng_ether will give me this but I am restricted to taking ALL frames (thus taking the machine offline) or orphaned frames (where I will have to write some sort of traffic generator to make frames of an invalid type). The third option here is to hack ng_ether to deliver frames out the lower hook as well as up into the kernel IP stack, thus giving me a complete stream without taking the box offline. I've gotten libnet which seems to fit the bill to generate any orphans I want, but making a stream of frames by hand is a pain. I've read about ng_tee but haven't had an opportunity to play with it. Could I hack together something like this for an input source? Would this allow for uninterrupted operation of the workstation while also giving a stream of test data? kernel ip_input() \ \-| |- upper hook-\ ng_ether ng_tee----> |- lower hook-/ | wire In case that diagram doesn't display in your mailer, I'm thinking of connecting ng_tee to recieve input from ng_ether's lower hook and pass it out through ng_ether's upper hook as well as into the input hook of my own netgraph node. Does anyone have any suggestions or ideas on tools or methods to assist me in starting this venture? Am I thinking about this problem from the right angle or is my head up my ass? :) Thanks all :) -- Steve Tremblett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 9:28:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF3137B401; Thu, 7 Nov 2002 09:28:45 -0800 (PST) Received: from scl8owa02.int.exodus.net (scl8out02.exodus.net [66.35.230.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFCA643E6E; Thu, 7 Nov 2002 09:28:41 -0800 (PST) (envelope-from Maksim.Yevmenkin@exodus.net) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by scl8owa02.int.exodus.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 09:28:41 -0800 Received: from exodus.net ([206.220.227.147]) by scl8owa01.int.exodus.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.5329); Thu, 7 Nov 2002 09:28:41 -0800 Message-ID: <3DCAA2C7.12D6ED3E@exodus.net> Date: Thu, 07 Nov 2002 09:28:39 -0800 From: Maksim Yevmenkin X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Steve Tremblett Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: input source for network application References: <20021107121857.F264@sjt-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2002 17:28:41.0343 (UTC) FILETIME=[1D7E00F0:01C28683] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Steve Tremblett wrote: > > I've been toying with the idea of tackling a Netgraph TCP/IP > implementation and want to hack out some skeleton netgraph nodes just > to feel things out and play around with parsing. I'm somewhat confused > on how to start. I'd like to be able to tinker as I go and I'd rather > not have to write 5000 lines of code and complete a mini-stack before > trying it out :) > > I'm in a bit of a bind. I want a sequence of ethernet frames to send > up through this framework. Hooking to ng_ether will give me this but I > am restricted to taking ALL frames (thus taking the machine offline) or > orphaned frames (where I will have to write some sort of traffic > generator to make frames of an invalid type). The third option here is > to hack ng_ether to deliver frames out the lower hook as well as up > into the kernel IP stack, thus giving me a complete stream without > taking the box offline. I've gotten libnet which seems to fit the bill > to generate any orphans I want, but making a stream of frames by hand > is a pain. why do you need ng_ether, ng_tee etc. at all? can't you just write your code with assumption that there will be one (or few) input hooks? can't you just connect *user-space* Ethernet/IP frame generator to the input hook(s) and send frames? that's what i did in HCI/Bluetooth stack when i had no *real* Bluetooth hardware. i just wrote simple *user-space* Bluetooth device simulator and connected it to the stack. then i run VMWare and debug my code. you can use tcpdump and save dumps to the file and then just read it and re-inject them into your node. this way you can test at least basic stuff, i.e. frame parsing etc. > I've read about ng_tee but haven't had an opportunity to play with it. > Could I hack together something like this for an input source? Would > this allow for uninterrupted operation of the workstation while also > giving a stream of test data? > > kernel > ip_input() > \ > \-| > |- upper hook-\ > ng_ether ng_tee----> > |- lower hook-/ > | > wire > > In case that diagram doesn't display in your mailer, I'm thinking of > connecting ng_tee to recieve input from ng_ether's lower hook and pass > it out through ng_ether's upper hook as well as into the input hook of > my own netgraph node. > > Does anyone have any suggestions or ideas on tools or methods to assist > me in starting this venture? Am I thinking about this problem from the > right angle or is my head up my ass? :) see above. max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 9:34:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B5C37B401; Thu, 7 Nov 2002 09:34:36 -0800 (PST) Received: from cisco.com (sword.cisco.com [161.44.208.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id C44E843E42; Thu, 7 Nov 2002 09:34:35 -0800 (PST) (envelope-from sjt@cisco.com) Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id MAA00571; Thu, 7 Nov 2002 12:34:34 -0500 (EST) Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id MAA09490; Thu, 7 Nov 2002 12:34:34 -0500 (EST) Date: Thu, 7 Nov 2002 12:34:34 -0500 From: Steve Tremblett To: Maksim Yevmenkin Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: input source for network application Message-ID: <20021107123434.G264@sjt-u10.cisco.com> References: <20021107121857.F264@sjt-u10.cisco.com> <3DCAA2C7.12D6ED3E@exodus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DCAA2C7.12D6ED3E@exodus.net>; from myevmenk@exodus.net on Thu, Nov 07, 2002 at 09:28:39AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org +---- Maksim Yevmenkin wrote: | > I'm in a bit of a bind. I want a sequence of ethernet frames to send | > up through this framework. Hooking to ng_ether will give me this but I | > am restricted to taking ALL frames (thus taking the machine offline) or | > orphaned frames (where I will have to write some sort of traffic | > generator to make frames of an invalid type). The third option here is | > to hack ng_ether to deliver frames out the lower hook as well as up | > into the kernel IP stack, thus giving me a complete stream without | > taking the box offline. I've gotten libnet which seems to fit the bill | > to generate any orphans I want, but making a stream of frames by hand | > is a pain. | | why do you need ng_ether, ng_tee etc. at all? can't you just write | your code with assumption that there will be one (or few) input | hooks? can't you just connect *user-space* Ethernet/IP frame generator | to the input hook(s) and send frames? that's what i did in HCI/Bluetooth | stack when i had no *real* Bluetooth hardware. i just wrote simple | *user-space* Bluetooth device simulator and connected it to the stack. | then i run VMWare and debug my code. | | you can use tcpdump and save dumps to the file and then just read it | and re-inject them into your node. this way you can test at least | basic stuff, i.e. frame parsing etc. Thought of this just after I sent the email - d'oh! Thanks! -- Steve Tremblett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 10:41:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D7C037B401; Thu, 7 Nov 2002 10:41:24 -0800 (PST) Received: from InterJet.elischer.org (12-232-206-8.client.attbi.com [12.232.206.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CEB743E6E; Thu, 7 Nov 2002 10:41:24 -0800 (PST) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA05933; Thu, 7 Nov 2002 10:36:05 -0800 (PST) Date: Thu, 7 Nov 2002 10:36:04 -0800 (PST) From: Julian Elischer To: Steve Tremblett Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: input source for network application In-Reply-To: <20021107121857.F264@sjt-u10.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 7 Nov 2002, Steve Tremblett wrote: > I've been toying with the idea of tackling a Netgraph TCP/IP > implementation and want to hack out some skeleton netgraph nodes just > to feel things out and play around with parsing. I'm somewhat confused > on how to start. I'd like to be able to tinker as I go and I'd rather > not have to write 5000 lines of code and complete a mini-stack before > trying it out :) > > I'm in a bit of a bind. I want a sequence of ethernet frames to send > up through this framework. Hooking to ng_ether will give me this but I > am restricted to taking ALL frames (thus taking the machine offline) or > orphaned frames (where I will have to write some sort of traffic > generator to make frames of an invalid type). The third option here is > to hack ng_ether to deliver frames out the lower hook as well as up > into the kernel IP stack, thus giving me a complete stream without > taking the box offline. I've gotten libnet which seems to fit the bill > to generate any orphans I want, but making a stream of frames by hand > is a pain. Also look at ng_etf the ethertype filter.. it is designed to connect to an ether node and filter out packets with a particular ethertype. yuo could alter it to examine for a particular tcp port number too. > > I've read about ng_tee but haven't had an opportunity to play with it. > Could I hack together something like this for an input source? Would > this allow for uninterrupted operation of the workstation while also > giving a stream of test data? > > kernel > ip_input() > \ > \-| > |- upper hook-\ > ng_ether ng_tee----> > |- lower hook-/ > | > wire > > In case that diagram doesn't display in your mailer, I'm thinking of > connecting ng_tee to recieve input from ng_ether's lower hook and pass > it out through ng_ether's upper hook as well as into the input hook of > my own netgraph node. yes that would work.. you would get a copy of all packets entering the machine. > > Does anyone have any suggestions or ideas on tools or methods to assist > me in starting this venture? Am I thinking about this problem from the > right angle or is my head up my ass? :) No you have the right idea. One possibility I am looking at is adding a netgraph hook onto ipfw so one could grab a packet on ipfw and force it out to a netgraph hook. > > Thanks all :) > > -- > Steve Tremblett > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 11:21:30 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id BC62B37B401; Thu, 7 Nov 2002 11:21:29 -0800 (PST) Date: Thu, 7 Nov 2002 11:21:29 -0800 From: Prafulla Deuskar To: freebsd-net@freebsd.org Cc: Jason Carroll Subject: Re: Trouble with gigabit cards Message-ID: <20021107112129.A8657@hub.freebsd.org> References: <20021105181641.C78733@hub.freebsd.org> <20021107134624.A14591-100000@digitas.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021107134624.A14591-100000@digitas.harvard.edu>; from jecarrol@digitas.harvard.edu on Thu, Nov 07, 2002 at 01:50:33PM -0500 X-Operating-System: FreeBSD 4.7-RC on an i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you don't want to go the sysctl route Change IFQ_MAXLEN to something reasonable in /usr/src/sys/net/if.h and recompile the kernel. There was discussion on net.inet.ip.intr_queue values recently on -net. So you might want to go through that thread. Thanks, Prafulla Jason Carroll [jecarrol@digitas.harvard.edu] wrote: > > Sorry for the slow reply; one of my email addresses seems to get rejected > by freebsd.org. > > It seems like net.inet.ip.intr_queue counts exactly the packets that are > dropped. I set the ...maxlen variable that appears to go with it up to > 200 (from 50), and this seems to have solved the problem. Any guidelines > for reasonable values? Is there some way I can set this in the kernel > other than by using sysctl? > > Thanks for your help! > Jason Carroll > > On Tue, 5 Nov 2002, Prafulla Deuskar wrote: > > > What does sysctl net.inet.ip.intr_queue_drops show? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 11:39:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B54A37B401 for ; Thu, 7 Nov 2002 11:39:34 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B35743E3B for ; Thu, 7 Nov 2002 11:39:32 -0800 (PST) (envelope-from pasi.savanain@kolumbus.fi) Received: from kolumbus.fi ([80.186.22.134]) by fep07-app.kolumbus.fi with ESMTP id <20021107193926.TJZU16201.fep07-app.kolumbus.fi@kolumbus.fi> for ; Thu, 7 Nov 2002 21:39:26 +0200 Message-ID: <3DCAC178.7040304@kolumbus.fi> Date: Thu, 07 Nov 2002 21:39:36 +0200 From: Pasi Savanainen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: arp reply Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Why the arp reply receiver interface has to have IP-address? -- Pasi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 14:33:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEB2337B401; Thu, 7 Nov 2002 14:33:42 -0800 (PST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7222143E42; Thu, 7 Nov 2002 14:33:42 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0030.cvx40-bradley.dialup.earthlink.net ([216.244.42.30] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 189vDO-0001dV-00; Thu, 07 Nov 2002 14:33:31 -0800 Message-ID: <3DCAE9E1.768685AF@mindspring.com> Date: Thu, 07 Nov 2002 14:32:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Steve Tremblett , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: input source for network application References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer wrote: > Also look at ng_etf the ethertype filter.. > it is designed to connect to an ether node and filter out packets > with a particular ethertype. yuo could alter it to examine for a > particular tcp port number too. [ ... ] A more interesting problem is how to hook an address family to a netgraph node. > One possibility I am looking at is adding a netgraph hook onto ipfw > so one could grab a packet on ipfw and force it out to a netgraph hook. This would be moderately useful. Another alternative would be to provide a means of hooking all input from a particular ethernet card into the netgraph framework, and run the machine with multiple ethernet cards -- one for the normal stack, and one for the alternate stack. Another method is to use an alternate (fictitious) protocol family and therefore ethertype that's a duplicate of the TCP stack, and do the processing there, instead. This is also rather trivial. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 19: 8:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B8B137B401 for ; Thu, 7 Nov 2002 19:08:39 -0800 (PST) Received: from web20003.mail.yahoo.com (web20003.mail.yahoo.com [216.136.225.48]) by mx1.FreeBSD.org (Postfix) with SMTP id 71EC343E3B for ; Thu, 7 Nov 2002 19:08:39 -0800 (PST) (envelope-from vctw@yahoo.com) Message-ID: <20021108030809.76286.qmail@web20003.mail.yahoo.com> Received: from [168.95.19.3] by web20003.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 19:08:09 PST Date: Thu, 7 Nov 2002 19:08:09 -0800 (PST) From: Vincent Chen Subject: racoon questions? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, all I have a ipsec tunnel with 2 freebsd in each end. It just came to me recently, how safe if racoon accept anonymous connection? Is it possible that somebody just create a fake certificate and feed it to racoon, then got access? BTW: I didn't check peer's identifier at this time. Will it be safer to check? Thanks, __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 19:18:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 624B337B401 for ; Thu, 7 Nov 2002 19:18:54 -0800 (PST) Received: from web20010.mail.yahoo.com (web20010.mail.yahoo.com [216.136.225.73]) by mx1.FreeBSD.org (Postfix) with SMTP id 1F7DA43E3B for ; Thu, 7 Nov 2002 19:18:54 -0800 (PST) (envelope-from vctw@yahoo.com) Message-ID: <20021108031853.91619.qmail@web20010.mail.yahoo.com> Received: from [168.95.19.3] by web20010.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 19:18:53 PST Date: Thu, 7 Nov 2002 19:18:53 -0800 (PST) From: Vincent Chen Subject: configure ipsec to accept roaming users? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, all I already done some test on ipsec transport and tunnel test successfully. Now, I try to figure out how to deal with roaming users. Here is the situation: internal <---> freebsd <---> roaming user freebsd's external NIC has a public, to accept incoming ipsec from roaming user. freebsd's internal NIC has a private IP, which connect to internal network. How can I write a proper ipsec policy? Is it necessary to add a route manually after connection is up? Please provide your successfully story. Thanks, __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 19:45:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 350C537B401; Thu, 7 Nov 2002 19:45:44 -0800 (PST) Received: from laurie.sux.org.uk (laurie.sux.org.uk [212.74.113.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id D021943E4A; Thu, 7 Nov 2002 19:45:43 -0800 (PST) (envelope-from krad@krad.org.uk) Received: from krad by laurie.sux.org.uk with local (Exim 3.36 #3) id 18A05V-000Axt-00; Fri, 08 Nov 2002 03:45:41 +0000 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: IP aliasing with ppp Message-Id: From: krad Date: Fri, 08 Nov 2002 03:45:41 +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, I currently have a /29 assigned by my isp for my dsl. I have got my bsd box connecting fine and natd is working off one off the ips. I would like to bind the remaining 5 ips to the tun0 interface on the bsd box and enable static nating to certain boxes behind the firewall. I am however having problems as when I use ifconfig i get strange results e.g. tun0: flags=8151 mtu 1500 inet 123.54.67.94 --> 65.4.32.1 netmask 0xffffff00 Opened by PID 6896 root on gateway# ifconfig tun0 alias inet 123.54.67.93 root on gateway# ifconfig tun0 tun0: flags=8151 mtu 1500 inet 123.54.67.94 --> 65.4.32.1 netmask 0xffffff00 inet 192.168.0.254 --> 123.54.67.93. netmask 0xffffff00 Opened by PID 6896 root on gateway# im not sure whats going on here but it certainly isnt correct. I have also tried playing around with ifalias commands in ppp with no problems. Am I going about this in completely the wrong way or is my syntax wrong when using ifconfig. regards Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Nov 7 20:30:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8DD537B401 for ; Thu, 7 Nov 2002 20:30:43 -0800 (PST) Received: from lawyers.ir.bbn.com (d53-203-209.clv.wideopenwest.com [64.53.209.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE64743E75 for ; Thu, 7 Nov 2002 20:30:42 -0800 (PST) (envelope-from mallman@lawyers.ir.bbn.com) Received: from lawyers (mallman@localhost) by lawyers.ir.bbn.com (8.9.3/8.9.3) with ESMTP id XAA29327; Thu, 7 Nov 2002 23:28:33 -0500 Message-Id: <200211080428.XAA29327@lawyers.ir.bbn.com> To: freebsd-net@FreeBSD.ORG Cc: Fran.Lawas-Grodek@grc.nasa.gov, Cindy.Tran@grc.nasa.gov Cc: "Joseph Ishac" , bdimond@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: Problem in High Speed and Long Delay with FreeBSD In-Reply-To: <20021101112001.E3259@grc.nasa.gov> Organization: BBN Technologies/NASA GRC Song-of-the-Day: Born in the USA Date: Thu, 07 Nov 2002 23:28:33 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Folks- Lots of interesting thoughts on this thread already. But, we have not yet figured it out. So, a further data point... I have been playing this evening on my machine at home -- a way old p5 running freebsd 4.7. I am seeing the same problem as we see at GRC on the freebsd 4.1 boxes. As I see it we can have one of a few possible problems: * For some reason the application is not able to fill the socket buffer. * For some reason TCP is not grabbing everything from the socket buffer. * TCP's congestion control is getting hosed somehow into thinking we need to slow down. So, my idea goes something like this: Say I have a connection with a X byte socket buffer. I start a timer, open a TCP connection, write Y bytes (Y < X), close the connection and stop the timer. The time should be very small in this case, because I am really timing how long it take the app to send data to the OS. (I am not enabling SO_LINGER). So, I ran some tests, as follows (sockbuf == X, dataen == Y): sockbuf datalen snd_time rcv_time --------------------------------------------- 16384 15000 0.000 0.617 150000 140000 0.003 4.021 500000 495000 0.015 14.083 1000000 995000 0.042 28.577 1500000 1490000 0.079 47.986 1600000 1590000 0.088 44.055 1800000 1790000 0.108 50.810 1900000 1890000 0.117 55.010 2000000 1990000 1.011 57.666 2100000 2090000 3.845 60.233 3000000 2990000 39.594 122.308 So, except for the last 3 lines all the tests easily filled up the socket buffers and exited. But, in the third line from the bottom we started to see something else. We "filled" the buffers until we could fill no more and had to wait for some ACKs to allow the buffer to drain before dumping everything in it. But, the socket buffer is bigger than the data stream so this should not be an issue, right? The situation only gets worse as we increase the transfer sizes (and socket buffer sizes). The break point seems to be somewhere near 2MB. For instance, when sending almost 3MB the sender though the transfer took ~40 seconds, while the receiver accurately shows ~122 seconds. That shows that the sender had to wait for a third of the data to drain from the network to get all its data into the socket buffers. But, that should not have been. One more piece of information... The socket descriptor is placed in non-blocking mode. I write in 8KB chunks. So, I do a select(), and write accordingly. However, even though I cannot write into the socket buffer at times, select() never fails to say that I can write the descriptor *and* I never see a short write(). But, clearly I am blocking or I'd shoot everything into the socket buffer. Does any of this make any sense to anyone? Any ideas on what might be wrong here? Any suggestions on places to start looking? Thanks! allman -- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 8 2:53: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0142237B401 for ; Fri, 8 Nov 2002 02:53:00 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id A119043E42 for ; Fri, 8 Nov 2002 02:52:58 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 68414 invoked from network); 8 Nov 2002 10:49:20 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Nov 2002 10:49:20 -0000 Message-ID: <3DCB974E.2703E90E@pipeline.ch> Date: Fri, 08 Nov 2002 11:51:58 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@grc.nasa.gov Cc: freebsd-net@FreeBSD.ORG, Fran.Lawas-Grodek@grc.nasa.gov, Cindy.Tran@grc.nasa.gov, Joseph Ishac , bdimond@grc.nasa.gov Subject: Re: Problem in High Speed and Long Delay with FreeBSD References: <200211080428.XAA29327@lawyers.ir.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mark Allman wrote: > > Folks- > > Lots of interesting thoughts on this thread already. But, we have > not yet figured it out. So, a further data point... > > I have been playing this evening on my machine at home -- a way old > p5 running freebsd 4.7. I am seeing the same problem as we see at > GRC on the freebsd 4.1 boxes. As I see it we can have one of a few > possible problems: > > * For some reason the application is not able to fill the socket > buffer. > > * For some reason TCP is not grabbing everything from the socket > buffer. > > * TCP's congestion control is getting hosed somehow into thinking > we need to slow down. Try to enable the TCP inflight code from Matt Dillon. Have a look at man tuning and turn the sysctls on. Also turn on the debug sysctl and watch the bandwidthdelay product calculations. That might give you some more hints on what is going on. -- Andre > So, my idea goes something like this: Say I have a connection with a > X byte socket buffer. I start a timer, open a TCP connection, write > Y bytes (Y < X), close the connection and stop the timer. The time > should be very small in this case, because I am really timing how > long it take the app to send data to the OS. (I am not enabling > SO_LINGER). So, I ran some tests, as follows (sockbuf == X, dataen > == Y): > > sockbuf datalen snd_time rcv_time > --------------------------------------------- > 16384 15000 0.000 0.617 > 150000 140000 0.003 4.021 > 500000 495000 0.015 14.083 > 1000000 995000 0.042 28.577 > 1500000 1490000 0.079 47.986 > 1600000 1590000 0.088 44.055 > 1800000 1790000 0.108 50.810 > 1900000 1890000 0.117 55.010 > 2000000 1990000 1.011 57.666 > 2100000 2090000 3.845 60.233 > 3000000 2990000 39.594 122.308 > > So, except for the last 3 lines all the tests easily filled up the > socket buffers and exited. But, in the third line from the bottom > we started to see something else. We "filled" the buffers until we > could fill no more and had to wait for some ACKs to allow the buffer > to drain before dumping everything in it. But, the socket buffer is > bigger than the data stream so this should not be an issue, right? > The situation only gets worse as we increase the transfer sizes (and > socket buffer sizes). The break point seems to be somewhere near > 2MB. For instance, when sending almost 3MB the sender though the > transfer took ~40 seconds, while the receiver accurately shows ~122 > seconds. That shows that the sender had to wait for a third of the > data to drain from the network to get all its data into the socket > buffers. But, that should not have been. > > One more piece of information... The socket descriptor is placed in > non-blocking mode. I write in 8KB chunks. So, I do a select(), and > write accordingly. However, even though I cannot write into the > socket buffer at times, select() never fails to say that I can write > the descriptor *and* I never see a short write(). But, clearly I am > blocking or I'd shoot everything into the socket buffer. > > Does any of this make any sense to anyone? Any ideas on what might > be wrong here? Any suggestions on places to start looking? > > Thanks! > > allman > > -- > Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 8 5:21:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3759B37B401 for ; Fri, 8 Nov 2002 05:21:44 -0800 (PST) Received: from web41213.mail.yahoo.com (web41213.mail.yahoo.com [66.218.93.46]) by mx1.FreeBSD.org (Postfix) with SMTP id 06BAA43E4A for ; Fri, 8 Nov 2002 05:21:44 -0800 (PST) (envelope-from shubha_mr@yahoo.com) Message-ID: <20021108132143.87891.qmail@web41213.mail.yahoo.com> Received: from [12.151.32.25] by web41213.mail.yahoo.com via HTTP; Fri, 08 Nov 2002 13:21:43 GMT Date: Fri, 8 Nov 2002 13:21:43 +0000 (GMT) From: =?iso-8859-1?q?shubha=20mr?= To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I wanted to know if there is any bypass for TCP/IP in freeBSD? Also does anyone know of the tcp/ip stack implemented in user space in freeBSD? Thanks shubha __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 8 6:10:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB99737B401 for ; Fri, 8 Nov 2002 06:10:25 -0800 (PST) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id B380443E4A for ; Fri, 8 Nov 2002 06:10:24 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id gA8EACuO039644; Fri, 8 Nov 2002 16:10:16 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <006e01c28730$916858f0$a230a8c0@PHE> From: "Petri Helenius" To: "shubha mr" , References: <20021108132143.87891.qmail@web41213.mail.yahoo.com> Subject: Re: Date: Fri, 8 Nov 2002 16:10:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ng_ether can be used to capture packets below the ip layer and not pass them along to upper layers. Additionally you can write outbound packets to the node. Pete ----- Original Message ----- From: "shubha mr" To: Sent: Friday, November 08, 2002 3:21 PM > Hi, > I wanted to know if there is any bypass for TCP/IP in > freeBSD? > Also does anyone know of the tcp/ip stack implemented > in user space in freeBSD? > > Thanks > shubha > > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 8 6:28:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A915337B401 for ; Fri, 8 Nov 2002 06:28:11 -0800 (PST) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A2B943E3B for ; Fri, 8 Nov 2002 06:28:06 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (unknown [161.53.19.180]) by premijer.tel.fer.hr (Postfix) with ESMTP id 6F8501380; Fri, 8 Nov 2002 15:27:37 +0100 (MET) Message-ID: <3DCBC9E9.1D790204@tel.fer.hr> Date: Fri, 08 Nov 2002 15:27:53 +0100 From: Marko Zec X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: shubha mr Cc: "freebsd-net@FreeBSD.org" Subject: Re: Userland TCP implementation References: <20021108132143.87891.qmail@web41213.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org shubha mr wrote: > Also does anyone know of the tcp/ip stack implemented > in user space in freeBSD? http://citeseer.nj.nec.com/ely01alpine.html http://citeseer.nj.nec.com/huang99entrapid.html Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 8 9:35:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E354737B401 for ; Fri, 8 Nov 2002 09:35:09 -0800 (PST) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DDCA43E8A for ; Fri, 8 Nov 2002 09:35:09 -0800 (PST) (envelope-from rick.norman@lmco.com) Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id gA8HZ2x24957; Fri, 8 Nov 2002 12:35:03 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1 #40643) id <0H5900501Q68RF@lmco.com>; Fri, 08 Nov 2002 09:35:01 -0800 (PST) Received: from lmco.com ([129.197.244.3]) by lmco.com (PMDF V6.1-1 #40643) with ESMTP id <0H5900DBLQ627P@lmco.com>; Fri, 08 Nov 2002 09:34:50 -0800 (PST) Date: Fri, 08 Nov 2002 09:28:35 -0800 From: rick norman Subject: Re: tcp/ip in user space To: shubha mr Cc: freebsd-net@FreeBSD.ORG Message-id: <3DCBF443.FCCF0FDB@lmco.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20021108132143.87891.qmail@web41213.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A while back, Mitre did a an implementation of SCPS (basically a hacked freebsd tcp running in user space). A reference implementation used to be available. http://www.scps.org/ shubha mr wrote: > Hi, > I wanted to know if there is any bypass for TCP/IP in > freeBSD? > Also does anyone know of the tcp/ip stack implemented > in user space in freeBSD? > > Thanks > shubha > > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- "I'm a-goin' to stay where you sleep all day Where they hung the jerk that invented work In the Big Rock Candy Mountains" wk: 408 742 1619 rick.norman@lmco.com hm: 650 726 0677 rnorman@ikaika.com cell: 650 303 3877 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 12:14:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B432537B401 for ; Sat, 9 Nov 2002 12:14:10 -0800 (PST) Received: from mx1.rzeznia.eu.org (pa81.pleszew.sdi.tpnet.pl [217.96.180.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685D343E42 for ; Sat, 9 Nov 2002 12:14:00 -0800 (PST) (envelope-from jr@rzeznia.eu.org) Received: by mx1.rzeznia.eu.org (Postfix, from userid 1001) id 1BC52489; Sat, 9 Nov 2002 21:18:07 +0100 (CET) Date: Sat, 9 Nov 2002 21:18:07 +0100 From: Bartek Marcinkiewicz To: freebsd-net@freebsd.org Subject: ipfw dummynet and ipfilter conflict? Message-ID: <20021109201807.GB3529@rzeznia.eu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello. I use ipfilter to do NAT and stateful ip filtering and i really like it. I use dummynet to limit bandwidth and i really like it too. The problem is they don't work together in specific situation. my ipf.rules (in simplification): block in log all block out log all pass out quick on ppp0 proto tcp all flags S keep state keep frags pass out quick on ppp0 proto udp all keep state keep frags pass out quick on ppp0 proto icmp all keep state keep frags ipfw configuration (excluding counters): ipfw add pipe 1 tcp from any 1025-2400 to any out ipfw pipe 1 config bw 4Kbytes/s ipfw add pipe 2 tcp from any 20 to any out ipfw pipe 2 config bw 3Kbytes/s ipfw allow all from any to any So i noticed that ipfilter isn't keeping state correctly on outcoming tcp connections when above ipfw rules are in charge. For example ipfstat -t shows connections that are never fully established, they stop at 4/3. There is no data exchange. I observed that: gateway.36023 -> mailhost.25 S mailhost.25 -> gateway.36023 SA mailhost.25 -> gateway.36023 SA and connection is not established.. in ipflog we can see: ppp0: @0:7 b 217.96.180.81,36023 -> 213.180.130.33,25 PR tcp len 20 52 -AF OUT Packet was blocked. But it shouldn't be.. I can successfuly connect to this mailhost if before "ipfw add pipe ..." rules I had put ipfw add allow ip from any to any. Summarizing: When I try to limit bandwidth i can't use tcp with keep state. Precisely: I can't use tcp from hosts behind gateway (NAT), I can establish tcp connections from gateway. I don't think that exhausting state table is the case here. Even when I had done ipf -FSs tcp didn't work. Perhaps I'm missing something obvious (too much time i spent on this problem), I will be very grateful for every idea, explanation, hint or solution. best regards, B. ps. I'm attaching revelant tcpdump, ipfstat -s and ipnat -s output. --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=ipfstat-s # ipfstat -s IP states added: 10111 TCP 3335 UDP 5330 ICMP 1017243 hits 654090 misses 0 maximum 0 no memory 526 bkts in use 545 active 8665 expired 9566 closed # ipnat -s mapped in 140179 out 138894 added 11916 expired 11343 no memory 0 bad nat 0 inuse 573 rules 15 wilds 0 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mailhost 20:54:54.835061 217.96.180.81.37836 > 213.180.130.33.25: S 1001007946:1001007946(0) win 16060 (DF) [tos 0x10] 20:54:54.877479 213.180.130.33.25 > 217.96.180.81.37836: S 3076683582:3076683582(0) ack 1001007947 win 10136 (DF) 20:54:58.243475 213.180.130.33.25 > 217.96.180.81.37836: S 3076683582:3076683582(0) ack 1001007947 win 10136 (DF) 20:55:04.964428 213.180.130.33.25 > 217.96.180.81.37836: S 3076683582:3076683582(0) ack 1001007947 win 10136 (DF) --cWoXeonUoKmBZSoM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 15: 0:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13EF537B401 for ; Sat, 9 Nov 2002 15:00:14 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9822E43E75 for ; Sat, 9 Nov 2002 15:00:13 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9V8V5>; Sat, 9 Nov 2002 18:00:12 -0500 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: Suggestions for tcbhashsize size? Date: Sat, 9 Nov 2002 18:00:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Are there any guidelines for setting the tcbhashsize ? I have a system which I'm expecting to keep ~50K TCP connections going. Does it follow standard hash table rules that it should be less than half full? I currently have net.inet.tcp.tcbhashsize: 4096 --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 19:39:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DB7937B401 for ; Sat, 9 Nov 2002 19:39:51 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 546E043E3B for ; Sat, 9 Nov 2002 19:39:50 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9V8ZG>; Sat, 9 Nov 2002 22:39:49 -0500 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: bug in bge driver with ENOBUFS on 4.7 Date: Sat, 9 Nov 2002 22:39:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In bge_rxeof(), there can end up being a condition which causes the driver to endlessly interrupt. if (bge_newbuf_std(sc, sc->bge_std, NULL) == ENOBUFS) { ifp->if_ierrors++; bge_newbuf_std(sc, sc->bge_std, m); continue; } happens. Now, bge_newbuf_std returns ENOBUFS. 'm' is also NULL. This causes the received packet to not be dequeued, and the driver will then go straight back into interrupt as the chip will reassert the interrupt as soon as we return. Suggestions on a fix? I'm not sure why I ran out of mbufs, I have kern.ipc.nmbclusters: 90000 kern.ipc.nmbufs: 280000 (kgdb) p/x mbstat $11 = {m_mbufs = 0x3a0, m_clusters = 0x39c, m_spare = 0x0, m_clfree = 0x212, m_drops = 0x0, m_wait = 0x0, m_drain = 0x0, m_mcfail = 0x0, m_mpfail = 0x0, m_msize = 0x100, m_mclbytes = 0x800, m_minclsize = 0xd5, m_mlen = 0xec, m_mhlen = 0xd4} but bge_newbuf_std() does this: if (m == NULL) { MGETHDR(m_new, M_DONTWAIT, MT_DATA); if (m_new == NULL) { return(ENOBUFS); } and then returns ENOBUFS. This is with 4.7-RELEASE. --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 20:53:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 290DD37B401 for ; Sat, 9 Nov 2002 20:53:42 -0800 (PST) Received: from shell.dragondata.com (shell.dragondata.com [66.250.147.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CACB43E3B for ; Sat, 9 Nov 2002 20:53:40 -0800 (PST) (envelope-from toasty@dragondata.com) Received: (from root@localhost) by shell.dragondata.com (8.11.4/8.11.3) id gAA4rd310631 for freebsd-net@freebsd.org; Sat, 9 Nov 2002 22:53:39 -0600 (CST) (envelope-from toasty@dragondata.com) Received: from KEVIN-AW.dragondata.com (dsl092-133-143.chi1.dsl.speakeasy.net [66.92.133.143]) by shell.dragondata.com (8.11.4/8.11.3av) with ESMTP id gAA4rb010606 for ; Sat, 9 Nov 2002 22:53:38 -0600 (CST) (envelope-from toasty@dragondata.com) Message-Id: <5.1.1.5.2.20021109202725.00b61a10@127.0.0.1> X-Sender: toasty@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 09 Nov 2002 22:53:36 -0600 To: freebsd-net@freebsd.org From: Kevin Day Subject: Packet forwarding overhead - with ipfw counting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by dragondata.com virus scanner Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a server acting as a router. Dual bge gigabit network interfaces (PCI-X), one is the WAN side the other is the LAN side. When we're pushing 250-300mbits through, we're using about 15% of its 2.4Ghz P4 Xeon CPU. All of it is in "interrupt" time... that seems a bit high, but that'll still let us max things out at 1gbit so we're ok. However, we wanted to do some MRTG style traffic charts per ip. I added about 30 sets of ipfw rules like this: count ip from 10.0.0.160 to any count ip from any to 10.0.0.160 Having these in place more than tripled the CPU usage. Am I just hitting a non-optimized codepath in ipfw, or is this normal for these kind of rules? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 22:22:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EF5D37B401 for ; Sat, 9 Nov 2002 22:22:59 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05DEE43E88 for ; Sat, 9 Nov 2002 22:22:56 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gAA6KoAf070013 for ; Sun, 10 Nov 2002 11:20:50 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gAA6Fdm23723 for ; Sun, 10 Nov 2002 11:15:39 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gAA6KXDx013639 for ; Sun, 10 Nov 2002 11:20:34 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <007601c28882$10c8b430$02010101@wall> From: "Dmitry A. Bondareff" To: References: <200211052108.gA5L8iCg039833@arch20m.dellroad.org> Subject: HTTPS throw tunnels Date: Sun, 10 Nov 2002 11:26:10 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! Who knows why the HTTPS protocol work too slow throw tunnels (like IPSEC and MPD) ?? With best regards, Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 22:26: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07EC837B401 for ; Sat, 9 Nov 2002 22:26:06 -0800 (PST) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D3043E4A for ; Sat, 9 Nov 2002 22:26:04 -0800 (PST) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0.1) with PIPE id 2340248; Sun, 10 Nov 2002 09:25:58 +0300 Date: Sun, 10 Nov 2002 09:25:57 +0300 From: Nikolai Saoukh To: freebsd-net@FreeBSD.ORG Subject: Re: HTTPS throw tunnels Message-ID: <20021110062557.GA22951@otdel1.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <200211052108.gA5L8iCg039833@arch20m.dellroad.org> <007601c28882$10c8b430$02010101@wall> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007601c28882$10c8b430$02010101@wall> User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org | Who knows why the HTTPS protocol work too slow throw tunnels (like IPSEC and | MPD) ?? Well, to be precise -- any kind of traffic through mpd tunnel is slow. A least slower then pptp tunnel between to windows computers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 9 23: 5:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36C3437B401 for ; Sat, 9 Nov 2002 23:05:35 -0800 (PST) Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34ADD43E77 for ; Sat, 9 Nov 2002 23:05:33 -0800 (PST) (envelope-from freebsd@mmk.ru) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.12.6/8.12.6) with ESMTP id gAA73cAf070488; Sun, 10 Nov 2002 12:03:38 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id gAA6wRv25956; Sun, 10 Nov 2002 11:58:27 +0500 (ESK) Received: from wall (localhost [127.0.0.1]) by wall.mmk.ru (8.12.6/8.12.6) with SMTP id gAA73LDx013700; Sun, 10 Nov 2002 12:03:22 +0500 (YEKT) (envelope-from freebsd@mmk.ru) Message-ID: <00ae01c28888$0bc8e440$02010101@wall> From: "Dmitry A. Bondareff" To: "Nikolai Saoukh" , References: <200211052108.gA5L8iCg039833@arch20m.dellroad.org> <007601c28882$10c8b430$02010101@wall> <20021110062557.GA22951@otdel1.org> Subject: Re: HTTPS throw tunnels Date: Sun, 10 Nov 2002 12:09:00 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org And how to find answer ? ----- Original Message ----- From: "Nikolai Saoukh" To: Sent: Sunday, November 10, 2002 11:25 AM Subject: Re: HTTPS throw tunnels > | Who knows why the HTTPS protocol work too slow throw tunnels (like IPSEC and > | MPD) ?? > > Well, > to be precise -- any kind of traffic through mpd tunnel is slow. > A least slower then pptp tunnel between to windows computers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message