From owner-freebsd-net Sun Jun 9 3:17:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id A17AE37B40C for ; Sun, 9 Jun 2002 03:17:31 -0700 (PDT) Received: (qmail 84907 invoked from network); 9 Jun 2002 10:16:58 -0000 Received: from unknown (HELO pipeline.ch) ([195.134.148.7]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Jun 2002 10:16:58 -0000 Message-ID: <3D032AE7.8B8CB2A@pipeline.ch> Date: Sun, 09 Jun 2002 12:16:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Andy Sparrow , Larry Rosenman , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MIB support for network devices in FreeBSD? References: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> <3D02E7F4.432854D0@mindspring.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 Terry Lambert wrote: > > Andy Sparrow wrote: > > But these stats don't seem to be collected for at least some network card > > drivers, presumably because those drivers aren't collecting those stats, e.g. > > they don't #include , and thus don't allocate a mib structure or > > increment any counters in that structure. > > > > I can confirm that it definately doesn't work for the 'wi' and 'lo' drivers... > > > > However, it definately seems to work for the xl driver... > > Benchmark the driver. > > If it's fast, it doesn't collect the statistics. Come on, this is bullshit. whatever++ hardly makes any difference. There are other places where way more cycles are wasted for less. -- Andre > Just like "WITNESS": if your machine is fast, "WITNESS" is disabled. > > 8-). > > Bascially, most of these statistics are "manager fluff" (as opposed > to "seat cushion fluuf" or "pocket fluff"). > > What you want is statistics that are managed universally; see > "netstat -ibdt" for the usefult statistics kept per interface. > > -- Terry > > 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 Jun 9 5:23:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 62C3437B40C; Sun, 9 Jun 2002 05:22:59 -0700 (PDT) Received: from pool0011.cvx22-bradley.dialup.earthlink.net ([209.179.198.11] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17H1iM-0004tn-00; Sun, 09 Jun 2002 05:22:34 -0700 Message-ID: <3D034864.BC63469C@mindspring.com> Date: Sun, 09 Jun 2002 05:21:56 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andre Oppermann Cc: Andy Sparrow , Larry Rosenman , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: MIB support for network devices in FreeBSD? References: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> <3D02E7F4.432854D0@mindspring.com> <3D032AE7.8B8CB2A@pipeline.ch> 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 Andre Oppermann wrote: > > Benchmark the driver. > > > > If it's fast, it doesn't collect the statistics. > > Come on, this is bullshit. whatever++ hardly makes any difference. > There are other places where way more cycles are wasted for less. You removed my "8-)" by truncating my statement, and seperating it out. However, if you're going to be insistant, my statement was really like foam rubber duct taped to an aluminum baseball bat: a core of truth wrapped in humor, so it didn't hurt as much. Without the atomic increment code that John Baldwin and Julian Elisher have asked to be adopted time and again, each place you increment has to lock, increment, then unlock the interface statistics structure. Similar locks occur on the global statistics, which are contended between all interfaces, rather than aggregated out of per interface statistics, with no locking whatsoever (like "ps", they are a snapshot of system state; the only accuracy needs to be in their incrementing, not in their instantaneous value). The upshot is serialization of routing and/or multicast on multiple interface systems. You end up having to implement increment locking in any case, if you insist on your snapshot, even for a single interface, have inter-element consistency for the aggregate of all values for a given interface (you must write lock so that writing respects the read lock, since writes are per elemenet, and reads are per aggregate). This is particularly true for "bad packet" counters, where the decision about what constitutes a bad packet is most often made by higher protocol layers, and thus is not intrinsically "per interface" -- worse, they run at NETISR in 4.x, and are expected to run in an interrupt thread, in 5.x. Getting rid of NETISR entirely (*not* replacing it with interrupt threads running the stack) would get rid of the contention, in that there would be implicit locking of the structure, were it per interface. You'd still need to aggregate it for global stats (e.g. the output of "netstat -s"), but, per above, that would not require locking, since it's a read-only operation, and is statistical in natures. For statistics, read locking implies write locking which implies locking on every update operation, even when the vast majority of times there is no possiblity of contention, because no one really cares about the stats values, for the most part. If you insist on exactitude, then you end up seperately serializing all statistics updates -- after all, statistics are gathered as the result of conditions which are rarely simultaneously handled in the code. Most of the stuff the original post wanted to monitor is not really defined for STD-0050 (RFC-1643), RFC-2665 or RFC-3201. Further, interface statistics are peculiar to the abstract concept "interface", and should have nothing whatsoever to do with the driver. If there is explicit driver support required, then there is an intrinsic problem, in that the MIB elements in question are not uniform across drivers for real hardware reasons, not just because someone forgot to add them. Probably, it would be good to implement them at a higher "interface layer", on top of all drivers. Bill Paul and Archie Cobbs would bot be good people to involve in any discussion, but to me, it makes no sense to modify individual drivers to resolve the original issue, rather than writing common code once, in lieu of replicating (hopefully) identical code in a grundle of drivers. The real answer should have been "For what purpose are these statistics to be gathered?", particularly since a many of them are in fact not RFC mandated for Interfaces, and are really only valuable in particular application domains (and may have their own MIBs for those domains, e.g. Frame Relay, DSL, or 802.12, etc.. So if you want to be picky, let me change my answer: For what purpose are these statistics to be gathered? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 9 21:41:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 77C5937B400; Sun, 9 Jun 2002 21:40:50 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5A4ebj21169; Sun, 9 Jun 2002 22:40:37 -0600 (MDT) (envelope-from ken) Date: Sun, 9 Jun 2002 22:40:37 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020609224036.A21143@panzer.kdm.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 I have released a new zero copy sockets snapshot, the code and a brief update on what has been fixed is here: http://people.FreeBSD.org/~ken/zero_copy In short, I fixed the following things, which were found by Alfred Perlstein: - fix a race in the vm object allocation in jumbo_vm_init() - use a sysinit to initialize the jumbo_mutex, since there is really no other way to avoid a race between checking the mutex to see if it has been initialized and actually initializing it. - use SLIST_FIRST instead of directly accessing the first element in the inuse list. - don't call malloc(9) with M_WAITOK while holding a mutex. Between the last snapshot and this one, jhb (or someone else, can't remember who) turned on the WITNESS logging that flags when there is a potential sleep while a mutex is held. That has uncovered a whole slew of warnings in the zero copy code. Some of the warnings are present in the ti(4) driver without my patches, some of them are only triggered by the zero copy patches. Below is an abbreviated list of places where I found problems. Most of these problems are in areas where I could use some help to figure out what the best course of action to take is. So any comments on how to get these things fixed up (or better yet, code!) would be welcome! 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls ends up calling vm_map_entry_create(). vm_map_entry_create() calls uma_zalloc() with M_WAITOK. 2. sf_buf_init() calls malloc() *with* M_NOWAIT, but the VM code ends up calling vm_map_entry_create(), so you have the same problem as above. 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls ends up calling vm_map_entry_create(), same problem as above. 4. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls malloc() with M_WAITOK. 5. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls kthread_create(), which calls fork1(), which calls uma_zalloc() with M_WAITOK. 6. ti_attach() calls bus_setup_intr(), which through various calls ends up calling ithread_create(), which calls kthread_create(), which calls fork1(), which calls MALLOC() with M_WAITOK in various places. 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() with M_WAITOK. 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls vm_map_find(), which through several calls calls vm_map_entry_create(). 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), which does a uma_zalloc() with M_WAITOK. 11. ti_attach() calls bus_setup_intr(), which ends up calling ithread_add_handler() through several layers of indirection. ithread_add_handler() calls malloc with M_WAITOK. 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() calls vm_map_insert(), which calls vm_map_entry_create(), which calls uma_zalloc with M_WAITOK. 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization function), which calls kmem_alloc_pageable(). See number 1 above, same problem here with vm_map_entry_create(). 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() gets called, which calls vm_map_entry_create(), which calls uma_zalloc() with M_WAITOK. 15. several more instances, the same as 14, but vm_map_entry_create() gets called through a slightly different path from the same root malloc() call in jumbo_vm_init(). 16. ti_newbuf_std() calls MCLGET(), *with* M_DONTWAIT set, but m_clget() calls mb_alloc(), which calls mb_pop_cont(), which calls kmem_malloc(), which calls vm_map_insert(), which calls vm_map_entry_create(), which calls uma_zalloc() with M_WAITOK. I could keep going almost indefinitely, but I'm getting kinda tired of going through stack traces, and this is enough to talk about for the moment. There seem to be two general problems here: - the M_WAITOK call to uma_zalloc in vm_map_entry_create() is the cause of the problems in entries 1, 2, 3, 12, 13, 14, 15 and 16 - the bus_setup_intr(), or rather the kthread code in general apparantly isn't safe to be called while holding a mutex. This is the cause of the problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. Several of the interfaces, most notably malloc(), contigmalloc(), and MCLGET(), offer "don't wait" interfaces, but the functions that they call don't necessarily respect or know about those flags. There are a lot more problems I ran into, some similar to the ones above. This is enough to get started with. If anyone wants to see the full console log, it is available at: http://people.FreeBSD.org/~ken/zero_copy/session.log.20020609 There was one other problem I ran into that wasn't related to sleeping while holding a mutex: db> c lock order reversal 1st 0xe7920bc0 ti0 (network driver) @ /usr/home/ken/perforce/FreeBSD-zero/src/sys/pci/if_ti.c:2126 2nd 0xc036c7c0 allproc (allproc) @ /usr/home/ken/perforce/FreeBSD-zero/src/sys/kern/kern_fork.c:309 Debugger("witness_lock") Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db> trace Debugger(c0318067) at Debugger+0x46 witness_lock(c036c7c0,8,c0311480,135,c04fcae8) at witness_lock+0x533 _sx_xlock(c036c7c0,c0311480,135,c01dc94b,c03cae10) at _sx_xlock+0x7d fork1(c0367d00,60034,c04fcabc) at fork1+0x1a0 kthread_create(c01d59c0,d8364400,c04fcae8,60000,c0311841) at kthread_create+0x37 ithread_create(c04fcb1c,10,0,c02e197a,c02e192c,c03381fd,10) at ithread_create+0x96 inthand_add(e7929480,10,c027aec4,e791e000,4) at inthand_add+0x6e nexus_setup_intr(e5dc4a00,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at nexus_setup_intr+0x61 bus_generic_setup_intr(e5dc4600,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at bus_generic_setup_intr+0x77 bus_generic_setup_intr(e7938700,e7938600,e78f37c0,4,c027aec4,e791e000,e791e150) at bus_generic_setup_intr+0x77 bus_setup_intr(e7938600,e78f37c0,4,c027aec4,e791e000) at bus_setup_intr+0x79 ti_attach(e7938600) at ti_attach+0x226 device_probe_and_attach(e7938600) at device_probe_and_attach+0x9c bus_generic_attach(e7938700) at bus_generic_attach+0x14 device_probe_and_attach(e7938700) at device_probe_and_attach+0x9c bus_generic_attach(e5dc4600,e5dc4600,c03398b8,2,e5dc4600) at bus_generic_attach+0x14 nexus_pcib_attach(e5dc4600) at nexus_pcib_attach+0x21 device_probe_and_attach(e5dc4600) at device_probe_and_attach+0x9c bus_generic_attach(e5dc4a00,e5dc4a00,e788f090,e5dc4a00,c04fcd60) at bus_generic_attach+0x14 nexus_attach(e5dc4a00) at nexus_attach+0xf device_probe_and_attach(e5dc4a00) at device_probe_and_attach+0x9c root_bus_configure(e5dc4c80,c0331000,0) at root_bus_configure+0x16 configure(0,4f9c00,4f9000,0,c012a1cc) at configure+0x20 mi_startup() at mi_startup+0x93 begin() at begin+0x43 db> c As I said above, any comments would be welcome! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 9 23: 8:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.simplexity.net (adsl-216-103-84-145.dsl.snfc21.pacbell.net [216.103.84.145]) by hub.freebsd.org (Postfix) with ESMTP id B5C9337B403; Sun, 9 Jun 2002 23:08:14 -0700 (PDT) Received: from localhost (localhost.skymind.com [127.0.0.1]) by iguana.simplexity.net (8.12.3/8.11.1) with ESMTP id g5A689vi017850; Sun, 9 Jun 2002 23:08:10 -0700 (PDT) (envelope-from ocrow@simplexity.net) Date: Sun, 9 Jun 2002 23:08:08 -0700 (PDT) From: Oliver Crow To: freebsd-stable@FreeBSD.ORG Cc: Mike Nowlin , Archie Cobbs , Subject: Re: Clockwork 24 hour crash in 4.5-RELEASE-p5 In-Reply-To: <20020603192117.E79925-100000@iguana.simplexity.net> Message-ID: <20020609224325.T17826-100000@iguana.simplexity.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 Archie Cobbs (the mpd maintainer) took a look at one of the crash dumps, and concluded that the address list hanging off of the loopback interface (lo0) was corrupted, hence the crash. Recompiling the kernel without IPv6 support seems to prevent the crashes (ie comment out 'options INET6' in kernel config). It is not clear what precisely the problem is, but it seems likely that it's an interaction between mpd and IPv6. Disabling either one appears to be a sufficent workaround to prevent the crashes. If anyone who knows the IPv6 code is interested in looking at the crash dumps, I'll be happy to arrange. Thanks to everone for helping out with this, especially Mike and Archie. Oliver > > On Sat, Jun 01, 2002 at 08:37:21PM -0700, Oliver Crow wrote: > > > > I have a FreeBSD 4.5-p5 system that's crashing reliably every 24 hours > > +/- a few minutes. It's been doing this ever since I compiled a > > 4.5-p4 kernel on March 25th. I cvsup'd to 4.5-p5 and recompiled, but > > it's still crashing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 9 23:33:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 3956937B400; Sun, 9 Jun 2002 23:33:21 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g5A6XC866306; Mon, 10 Jun 2002 15:33:12 +0900 (JST) Date: Mon, 10 Jun 2002 15:33:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Oliver Crow Cc: freebsd-stable@FreeBSD.ORG, Mike Nowlin , Archie Cobbs , Subject: Re: Clockwork 24 hour crash in 4.5-RELEASE-p5 In-Reply-To: <20020609224325.T17826-100000@iguana.simplexity.net> References: <20020603192117.E79925-100000@iguana.simplexity.net> <20020609224325.T17826-100000@iguana.simplexity.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 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, 9 Jun 2002 23:08:08 -0700 (PDT), >>>>> Oliver Crow said: > Archie Cobbs (the mpd maintainer) took a look at one of the crash dumps, > and concluded that the address list hanging off of the loopback interface > (lo0) was corrupted, hence the crash. > Recompiling the kernel without IPv6 support seems to prevent the crashes > (ie comment out 'options INET6' in kernel config). It is not clear what > precisely the problem is, but it seems likely that it's an interaction > between mpd and IPv6. Disabling either one appears to be a sufficent > workaround to prevent the crashes. > If anyone who knows the IPv6 code is interested in looking at the crash > dumps, I'll be happy to arrange. Thanks to everone for helping out with > this, especially Mike and Archie. Seems like the garbage collection timer of neighbor discovery entries is related to the crash. If the crash can be reproduced regardless of the local network environment, we'll be able to figure it out. Could you show us the kernel configuration? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 10 1: 7:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (asplinux.ru [195.133.213.194]) by hub.freebsd.org (Postfix) with ESMTP id C696A37B40A for ; Mon, 10 Jun 2002 01:07:26 -0700 (PDT) Received: from vova by vbook.express.ru with local (Exim 3.36 #1) id 17HKCv-0000CD-00; Mon, 10 Jun 2002 12:07:21 +0400 Subject: Re: [HELP] IPless VLAN interfaces From: "Vladimir B. " Grebenschikov To: Christophe Prevotaux Cc: "net@freebsd.org" In-Reply-To: <20020607172757.4f37c70c.c.prevotaux@hexanet.fr> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> <1023376206.470.40.camel@vbook.express.ru> <20020607172757.4f37c70c.c.prevotaux@hexanet.fr> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:07:20 +0400 Message-Id: <1023696440.576.17.camel@vbook.express.ru> Mime-Version: 1.0 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 =F7 Fri, 07.06.2002, =D7 19:27, Christophe Prevotaux =CE=C1=D0=C9=D3=C1=CC: > try to setup this (it won't work) your example does not work As I already said you need to remove interface route here (or apply changes sugessted by Iasen Kostoff ) > ifconfig fxp0 inet 192.168.1.1/24 up > ifconfig fxp0 inet 192.168.1.1/32 alias=20 route delete 192.168.1.1 > ifconfig fxp0 inet 192.168.1.1/32 alias <--- here it will not work anymor= e With route line it will work > this is the same thing with vlan interfaces under FreeBSD > you can't have more than 1 interface with the same IP/NETMASK >=20 > ifconfig fxp0 inet 192.168.1.1/24 up > ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/32 up route delete 192.168.1.1 > ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/32 up <-- this= does not work before each new vlan initialization you need remove interface route=20 > let's say for the example sake , that you want only to have 1 vlan on the= fxp0 > then you can setup the interface as shown above but you can't route anyth= ing thru it >=20 > route add 192.168.1.2 -interface vlan0=20 >=20 > will not route properly the packets thru vlan0 either because it is a /32= (AFAIK) It is not valid command, see: # route add 1.2.3.4 -interface fxp0 add host 1.2.3.4: gateway fxp0 # netstat -rn | fgrep 1.2.3.4 1.2.3.4 00:00:00:00:00:00 UHLS 0 0 fxp0 # It is invalid route, -interface command add route direct reachable via interface (ppp interface for example) but there we have ethernet with indirect access (you need mac-resolve first) see: # route add -net 1.2.3.4/32 -cloning -iface fxp0 add net 1.2.3.4: gateway fxp0 # netstat -rn | fgrep 1.2.3.4 1.2.3.4/32 link#3 UCS 0 0 fxp0 # So, it is net-route and it will be cloned at request (arp-request will be sent) # ping -c1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes 64 bytes from 1.2.3.4: icmp_seq=3D0 ttl=3D64 time=3D1.799 ms --- 1.2.3.4 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 1.799/1.799/1.799/0.000 ms # netstat -rn | fgrep 1.2.3.4 1.2.3.4 00:01:03:d6:9e:9f UHLW 0 2 fxp0 =20 1192 =3D> 1.2.3.4/32 link#3 UCS 1 0 fxp0 # you see at this stage you have cloning(C) netroute and cloned(W) hostroute to your NIC with 1.2.3.4 If you do not want arp-resolve you can specify MAC-address (link-layer address): # route add -host 4.3.2.1 -link aa:bb:cc:dd:ee:ff -ifp fxp0 add host 4.3.2.1: gateway aa:bb:cc:dd:ee:ff # netstat -rn | fgrep 4.3.2.1 4.3.2.1 aa:bb.cc.dd.ee.ff UGHS 0 0 fxp0 # Ruslan Ermilov knows more about routes setup and may be correct me if I am mistaken. > and even if you could do it , then the problem is that you are limited to= having > only one vlan per interface, which sucks BIG TIME. No, see above > under Linux you can have the equivalent of the following setup: >=20 > 192.168.1.2/24 > 192.168.1.3/24 > 192.168.1.4/24 >=20 > are machines behind the switch vlan 1 2 3 ports respectively >=20 > ifconfig fxp0 inet 192.168.1.1/24 up > ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/24 up > ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/24 up > ifconfig create vlan2 inet vlan 3 vlandev fxp0 192.168.1.1/24 up >=20 > etc... etc... >=20 > and then you do the equivalent of=20 >=20 > route add 192.168.1.2 -interface vlan0=20 > route add 192.168.1.3 -interface vlan1=20 > route add 192.168.1.4 -interface vlan2=20 As I said -interface flag is invalid here, Linux or too smart or too stupid here. > and it works just fine, with no problems whatsoever. >=20 > What I want to do is just this but under FreeBSD. >=20 > My question is : How can I do it ?=20 See above =20 PS:=20 As I already said, route manpage need some work, because it is very unclean, may be somebody who knows English well will do it ... --=20 Vladimir B. Grebenschikov vova@sw.ru, SWsoft, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 10 1:49:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 4D34837B401 for ; Mon, 10 Jun 2002 01:49:32 -0700 (PDT) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.3/8.12.3) with SMTP id g5A8nTE8044857; Mon, 10 Jun 2002 10:49:29 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Mon, 10 Jun 2002 10:49:29 +0200 From: Christophe Prevotaux To: "Vladimir B. " Grebenschikov Cc: net@FreeBSD.ORG Subject: Re: [HELP] IPless VLAN interfaces Message-Id: <20020610104929.1660ea4f.c.prevotaux@hexanet.fr> In-Reply-To: <1023696440.576.17.camel@vbook.express.ru> References: <20020606125126.3d44145c.c.prevotaux@hexanet.fr> <1023373804.470.20.camel@vbook.express.ru> <3CFF7644.F4F5CC1@tel.fer.hr> <1023376206.470.40.camel@vbook.express.ru> <20020607172757.4f37c70c.c.prevotaux@hexanet.fr> <1023696440.576.17.camel@vbook.express.ru> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-portbld-freebsd4.4) X-NCC-RegID: fr.hexanet 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 Thank you I will try all this , i appreciate you taking the time to answer. On 10 Jun 2002 12:07:20 +0400 "Vladimir B. "Grebenschikov wrote: > ÷ Fri, 07.06.2002, × 19:27, Christophe Prevotaux ÎÁÐÉÓÁÌ: > > try to setup this (it won't work) your example does not work > > As I already said you need to remove interface route here > (or apply changes sugessted by Iasen Kostoff ) > > > ifconfig fxp0 inet 192.168.1.1/24 up > > ifconfig fxp0 inet 192.168.1.1/32 alias > route delete 192.168.1.1 > > ifconfig fxp0 inet 192.168.1.1/32 alias <--- here it will not work > > anymore > > > With route line it will work > > > this is the same thing with vlan interfaces under FreeBSD > > you can't have more than 1 interface with the same IP/NETMASK > > > > ifconfig fxp0 inet 192.168.1.1/24 up > > ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/32 up > route delete 192.168.1.1 > > ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/32 up <-- > > this does not work > > before each new vlan initialization you need remove interface route > > > let's say for the example sake , that you want only to have 1 vlan > > on the fxp0 then you can setup the interface as shown above but you > > can't route anything thru it > > > > route add 192.168.1.2 -interface vlan0 > > > > will not route properly the packets thru vlan0 either because it is > > a /32 (AFAIK) > > It is not valid command, see: > > # route add 1.2.3.4 -interface fxp0 > add host 1.2.3.4: gateway fxp0 > # netstat -rn | fgrep 1.2.3.4 > 1.2.3.4 00:00:00:00:00:00 UHLS 0 0 fxp0 > # > It is invalid route, -interface command add route direct reachable via > interface (ppp interface for example) but there we have ethernet with > indirect access (you need mac-resolve first) > > see: > > # route add -net 1.2.3.4/32 -cloning -iface fxp0 > add net 1.2.3.4: gateway fxp0 > # netstat -rn | fgrep 1.2.3.4 > 1.2.3.4/32 link#3 UCS 0 0 fxp0 > # > > So, it is net-route and it will be cloned at request (arp-request will > be sent) > > # ping -c1 1.2.3.4 > PING 1.2.3.4 (1.2.3.4): 56 data bytes > 64 bytes from 1.2.3.4: icmp_seq=0 ttl=64 time=1.799 ms > --- 1.2.3.4 ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.799/1.799/1.799/0.000 ms > # netstat -rn | fgrep 1.2.3.4 > 1.2.3.4 00:01:03:d6:9e:9f UHLW 0 2 fxp0 > 1192 => > 1.2.3.4/32 link#3 UCS 1 0 fxp0 > # > > you see at this stage you have cloning(C) netroute and cloned(W) > hostroute to your NIC with 1.2.3.4 > > If you do not want arp-resolve you can specify MAC-address (link-layer > address): > > # route add -host 4.3.2.1 -link aa:bb:cc:dd:ee:ff -ifp fxp0 > add host 4.3.2.1: gateway aa:bb:cc:dd:ee:ff > # netstat -rn | fgrep 4.3.2.1 > 4.3.2.1 aa:bb.cc.dd.ee.ff UGHS 0 0 fxp0 > # > > Ruslan Ermilov knows more about routes setup and may > be correct me if I am mistaken. > > > and even if you could do it , then the problem is that you are > > limited to having only one vlan per interface, which sucks BIG TIME. > > No, see above > > > under Linux you can have the equivalent of the following setup: > > > > 192.168.1.2/24 > > 192.168.1.3/24 > > 192.168.1.4/24 > > > > are machines behind the switch vlan 1 2 3 ports respectively > > > > ifconfig fxp0 inet 192.168.1.1/24 up > > ifconfig create vlan0 inet vlan 1 vlandev fxp0 192.168.1.1/24 up > > ifconfig create vlan1 inet vlan 2 vlandev fxp0 192.168.1.1/24 up > > ifconfig create vlan2 inet vlan 3 vlandev fxp0 192.168.1.1/24 up > > > > etc... etc... > > > > and then you do the equivalent of > > > > route add 192.168.1.2 -interface vlan0 > > route add 192.168.1.3 -interface vlan1 > > route add 192.168.1.4 -interface vlan2 > > As I said -interface flag is invalid here, Linux or too smart or too > stupid here. > > > and it works just fine, with no problems whatsoever. > > > > What I want to do is just this but under FreeBSD. > > > > My question is : How can I do it ? > > See above > > PS: > As I already said, route manpage need some work, because it is very > unclean, may be somebody who knows English well will do it ... -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 10 11: 5:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id A9E5C37B4A7; Mon, 10 Jun 2002 11:03:01 -0700 (PDT) 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 <0GXI0002E4T1I2@mta6.snfc21.pbi.net>; Mon, 10 Jun 2002 11:03:01 -0700 (PDT) Date: Mon, 10 Jun 2002 11:03:09 -0700 From: Jeffrey Hsu Subject: Re: new zero copy sockets snapshot, WITNESS problems In-reply-to: "Message from Kenneth D. Merry" "of Sun, 09 Jun 2002 22:40:37 MDT." <20020609224036.A21143@panzer.kdm.org> To: "Kenneth D. Merry" Cc: current@FreeBSD.org, net@FreeBSD.org Message-id: <0GXI0002F4T1I2@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 > 1. sf_buf_init() calls kmem_alloc_pageable(), which through several calls > ends up calling vm_map_entry_create(). vm_map_entry_create() calls > uma_zalloc() with M_WAITOK. Alan Cox and Tor Egge just fixed this in -current in rev 1.247 of vm_map.c. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 10 11:45:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A50F537B40B for ; Mon, 10 Jun 2002 11:45:27 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g5AIjKDK081778; Mon, 10 Jun 2002 14:45:20 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g5AIjJTE081775; Mon, 10 Jun 2002 14:45:20 -0400 (EDT) (envelope-from wollman) Date: Mon, 10 Jun 2002 14:45:20 -0400 (EDT) From: Garrett Wollman Message-Id: <200206101845.g5AIjJTE081775@khavrinen.lcs.mit.edu> To: Andy Sparrow Cc: freebsd-net@FreeBSD.ORG Subject: Re: MIB support for network devices in FreeBSD? In-Reply-To: <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> References: <1023592304.349.20.camel@lerlaptop> <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> 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 < said: > datamib[5] = IFDATA_GENERAL; > *ip = drvdata->ifmd_data.ifi_ipackets; > *op = drvdata->ifmd_data.ifi_opackets; > *ib = drvdata->ifmd_data.ifi_ibytes; > *ob = drvdata->ifmd_data.ifi_obytes; The ``general'' part of the interface MIB is implemented by generic code in net/if_mib.c, and uses the same counters as (e.g.) `netstat' examines. IWBRNI more drivers implemented the medium-specific MIB, but that's not necessary to provide this information. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 10 20:28: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from pacbell.net (adsl-63-199-179-203.dsl.snfc21.pacbell.net [63.199.179.203]) by hub.freebsd.org (Postfix) with ESMTP id 75FA237B404; Mon, 10 Jun 2002 20:27:57 -0700 (PDT) Received: (from paleph@localhost) by pacbell.net (8.11.0/8.9.3) id g5B2x3M01869; Mon, 10 Jun 2002 19:59:03 -0700 From: paleph@pacbell.net Message-Id: <200206110259.g5B2x3M01869@pacbell.net> Subject: bge driver hangs seen with FreeBSD 4.5 To: freebsd-net@FreeBSD.ORG Date: Mon, 10 Jun 2002 19:59:02 -0700 (PDT) Cc: freebsd-question@FreeBSD.ORG X-Mailer: ELM [version 2.5 PL3] 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 We're experiencing problems with the bge gigabit ethernet driver. We have a 100 Mbit ethernet network and are running 4.5 standard install kernels. We have two 4.5 machines A (with a bge gigabit driver) and machine B with ed0 interface. With small packets or low load, there is no problem sending data (via ftp) from B to A. However when we attempt to ftp a large file, about 16 Megabytes, from machine B to machine A, the connection immediately hangs and we start seeing timeout messages from the bge driver on machine A. The interface is completely locked up and machine A no longer responds to pings. If we abort the ftp request, machine A heals after a while (5 - 10 minutes). and things start working again. I grabbed the latest bge sources from FreeBSD.org and rebuilt a 4.5 kernel with them. The problem still occurs. Has anyone seen this hang before with 4.5 and know of any fixes? I've just started to look at it. I looked at the bug list and didn't see anything reported for the bge driver. Machine A is a Dell 4650. Paul Fronberg paleph@pacbell.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 1:39:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id ACBF937B40F for ; Tue, 11 Jun 2002 01:37:14 -0700 (PDT) Received: (qmail 9855 invoked from network); 11 Jun 2002 08:37:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Jun 2002 08:37:12 -0000 Received: from laptop.baldwin.cx ([206.187.69.211]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g5B8bAQ81411; Tue, 11 Jun 2002 04:37:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020609224036.A21143@panzer.kdm.org> Date: Tue, 11 Jun 2002 04:37:04 -0400 (EDT) From: John Baldwin To: "Kenneth D. Merry" Subject: RE: new zero copy sockets snapshot, WITNESS problems Cc: net@FreeBSD.org, current@FreeBSD.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 On 10-Jun-2002 Kenneth D. Merry wrote: > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > ends up calling vm_map_entry_create(), same problem as above. > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls malloc() with M_WAITOK. > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls uma_zalloc() with M_WAITOK. > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > calling ithread_create(), which calls kthread_create(), which calls > fork1(), which calls MALLOC() with M_WAITOK in various places. > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > with M_WAITOK. > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > vm_map_find(), which through several calls calls vm_map_entry_create(). > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > which does a uma_zalloc() with M_WAITOK. > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > ithread_add_handler() through several layers of indirection. > ithread_add_handler() calls malloc with M_WAITOK. ti_attach() doesn't need to hold its lock while doing these things. Don't actually enable the logical network device until all the setup for it is done. > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > uma_zalloc with M_WAITOK. > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > function), which calls kmem_alloc_pageable(). See number 1 above, same > problem here with vm_map_entry_create(). > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > gets called, which calls vm_map_entry_create(), which calls > uma_zalloc() with M_WAITOK. > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > called through a slightly different path from the same root malloc() > call in jumbo_vm_init(). Same as above with regards to ti_attach(). > - the bus_setup_intr(), or rather the kthread code in general apparantly > isn't safe to be called while holding a mutex. This is the cause of the > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. Yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 9:29:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d146.as9.nwbl0.wi.voyager.net [169.207.133.212]) by hub.freebsd.org (Postfix) with ESMTP id 6D18A37B401 for ; Tue, 11 Jun 2002 09:29:33 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g5BGUu9I024093; Tue, 11 Jun 2002 11:30:56 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g5BGULip024090; Tue, 11 Jun 2002 11:30:37 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 11 Jun 2002 11:30:20 -0500 (CDT) From: Mike Silbersack To: Mikael Olsson Cc: Phil Dibowitz , Jean-Yves Lefort , Subject: Re: Broken PMTUD in FreeBSD? In-Reply-To: <3D060A6C.5204B402@clavister.com> Message-ID: <20020611112119.N23986-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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'm redirecting this back to freebsd-net, as it doesn't seem appropriate for bugtraq.) I did some quick investigation last night, and agree with Phil that this is a bug. When the syncache was implemented, only a subset of the normal tcp output code was copied over for the purpose of sending syn-acks. One part of the code that was not moved over was the part that determines when the DF and tos bits are set. I also agree with Mikael that this isn't an important issue, given that syn-ack packets are quite tiny. Nonetheless, I will commit a fix in the next few days. However, it's too late to MFC it in time for 4.6-release. Phil: In the future, please try a bit harder to notify someone if you believe that a bug is serious enough for posting to bugtraq. freebsd-net is a relatively busy list, and things do get missed. Mike "Silby" Silbersack On Tue, 11 Jun 2002, Mikael Olsson wrote: > > Phil Dibowitz wrote: > > > > [FreeBSD doesn't set DF in SYN/ACK] > > > > I don't consider this a big security hole, but it is a bug. It could > > be used to do TCP fingerprinting, and it also breaks a standard > > Is this really a bug? I wouldn't be so sure. What is the purpose of > setting DF in a SYN/ACK segment ? It's not like it can react to > returned ICMP errors and decrease the size of segment (only 40 bytes > of IP and TCP header and a few options). > > I'd even argue that it's a feature. If something has an MTU that > is so small that it can't pass TCP segments without data, there's > nothing to be done about it, and you should let fragmentation occur. > > > The fingerprinting point is sort of valid, I guess. However, since > there are already BSD boxes out there doing this, the fingerprint > value would be even greater (the fingerprint match more narrow) if > one were to change it now. > > -- > Mikael Olsson, Clavister AB > Storgatan 12, Box 393, SE-891 28 =D6RNSK=D6LDSVIK, Sweden > Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 > Fax: +46 (0)660 122 50 WWW: http://www.clavister.com > > "Senex semper diu dormit" > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 9:36:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 0E70C37B40F; Tue, 11 Jun 2002 09:36:00 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g5BGZxQ33413; Tue, 11 Jun 2002 10:35:59 -0600 (MDT) (envelope-from ken) Date: Tue, 11 Jun 2002 10:35:59 -0600 From: "Kenneth D. Merry" To: John Baldwin Cc: net@FreeBSD.org, current@FreeBSD.org Subject: Re: new zero copy sockets snapshot, WITNESS problems Message-ID: <20020611103559.A33391@panzer.kdm.org> References: <20020609224036.A21143@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Jun 11, 2002 at 04:37:04AM -0400 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, Jun 11, 2002 at 04:37:04 -0400, John Baldwin wrote: > On 10-Jun-2002 Kenneth D. Merry wrote: > > 3. ti_attach() calls bus_alloc_resource(), which through a ton of calls > > ends up calling vm_map_entry_create(), same problem as above. > > > > 4. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls malloc() with M_WAITOK. > > > > 5. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls uma_zalloc() with M_WAITOK. > > > > 6. ti_attach() calls bus_setup_intr(), which through various calls ends up > > calling ithread_create(), which calls kthread_create(), which calls > > fork1(), which calls MALLOC() with M_WAITOK in various places. > > > > 7. see the previous entry, fork1() calls fdcopy(), which calls MALLOC() > > with M_WAITOK. > > > > 8. see entry 6, fork1() calls vm_forkproc(), which calls pmap_new_proc(), > > which calls vm_object_allocate(), which does a uma_zalloc with M_WAITOK. > > > > 9. see above, pmap_new_proc() calls kmem_alloc_nofault(), which calls > > vm_map_find(), which through several calls calls vm_map_entry_create(). > > > > 10. fork1() calls pmap_new_thread(), which calls vm_object_allocate(), > > which does a uma_zalloc() with M_WAITOK. > > > > 11. ti_attach() calls bus_setup_intr(), which ends up calling > > ithread_add_handler() through several layers of indirection. > > ithread_add_handler() calls malloc with M_WAITOK. > > ti_attach() doesn't need to hold its lock while doing these things. Don't > actually enable the logical network device until all the setup for it is done. Okay, will do. > > 12. ti_attach() calls contigmalloc() *with* M_NOWAIT, but contigmalloc1() > > calls vm_map_insert(), which calls vm_map_entry_create(), which calls > > uma_zalloc with M_WAITOK. > > > > 13. ti_attach() calls jumbo_vm_init() (jumbo buffer initialization > > function), which calls kmem_alloc_pageable(). See number 1 above, same > > problem here with vm_map_entry_create(). > > > > 14. jumbo_vm_init() calls malloc() *with* M_NOWAIT, but vm_map_insert() > > gets called, which calls vm_map_entry_create(), which calls > > uma_zalloc() with M_WAITOK. > > > > 15. several more instances, the same as 14, but vm_map_entry_create() gets > > called through a slightly different path from the same root malloc() > > call in jumbo_vm_init(). > > Same as above with regards to ti_attach(). > > > - the bus_setup_intr(), or rather the kthread code in general apparantly > > isn't safe to be called while holding a mutex. This is the cause of the > > problems in entries 4, 5, 6, 7, 8, 9, 10, and 11. > > Yes. Thanks! Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 9:50:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id 5A62637B40A for ; Tue, 11 Jun 2002 09:50:13 -0700 (PDT) Received: from user-112159e.dsl.mindspring.com ([66.32.149.46] helo=ipom.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HoqK-0006uK-00; Tue, 11 Jun 2002 09:50:04 -0700 Message-ID: <3D062B0A.90803@ipom.com> Date: Tue, 11 Jun 2002 09:53:30 -0700 From: Phil Dibowitz Organization: Insanity Palace of Metallica User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Mike Silbersack Cc: Mikael Olsson , Jean-Yves Lefort , freebsd-net@freebsd.org, mss@ipom.com Subject: Re: Broken PMTUD in FreeBSD? References: <20020611112119.N23986-100000@patrocles.silby.com> 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 Mike Silbersack wrote: > (I'm redirecting this back to freebsd-net, as it doesn't seem appropriate > for bugtraq.) > > I did some quick investigation last night, and agree with Phil that this > is a bug. When the syncache was implemented, only a subset of the normal > tcp output code was copied over for the purpose of sending syn-acks. One > part of the code that was not moved over was the part that determines when > the DF and tos bits are set. Ahhh. Sounds like many of the bugs I've found in my own software. > I also agree with Mikael that this isn't an important issue, given that > syn-ack packets are quite tiny. Nonetheless, I will commit a fix in the > next few days. However, it's too late to MFC it in time for 4.6-release. It's certainly not a security-threatening issue... but, as you said, it is a bug. > Phil: In the future, please try a bit harder to notify someone if you > believe that a bug is serious enough for posting to bugtraq. freebsd-net > is a relatively busy list, and things do get missed. Certainly. I appologize if I caused the FreeBSD developers any grief over my post. I'm not a FreeBSD user myself and wasn't aware of the http://www.freebsd.org/send-pr.html page until yesterday. I did submit a bug report there yesterday, which got assigned an ID of kern/39141, so when you commit the fix, you can update/close that case as well. Thanks again for your quick response. Phil Dibowitz (on Behalf of myself and Richard van den Berg) -- Insanity Palace of Metallica http://www.ipom.com webmaster@ipom.com -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 14:20:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f177.law11.hotmail.com [64.4.17.177]) by hub.freebsd.org (Postfix) with ESMTP id 7503537B405 for ; Tue, 11 Jun 2002 14:20:35 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 14:20:35 -0700 Received: from 152.75.99.55 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 11 Jun 2002 21:20:34 GMT X-Originating-IP: [152.75.99.55] From: "Kim Okasawa" To: freebsd-net@freebsd.org Subject: FreeBSD+Win2K+Wireless LAN Date: Wed, 12 Jun 2002 06:20:34 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2002 21:20:35.0289 (UTC) FILETIME=[D34CEC90:01C2118D] 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 all, I want to set up my home network to take advantage of the D-Link DWL-120 USB wireless adapter. I have set up the network as follow (see graph below), and the FreeBSD and Win2K boxes can access to the Internet but the WinXP notebook computer CAN NOT. I know somewhere along the line I did something wrong. Can someone help me to fix the problem? Thank you. Regards, Kim .-------------. ( Internet ) .------+------. | | +------+------+ | Cable Modem | +------+------+ | | +-------+--------+ <-- NIC (rl0): (DHCP) get ip from comcast | FreeBSD 4.5 | | Running natd. | +-------+--------+ <-- NIC (fxp0): Private IP: 172.16.0.1 | | | +-------+--------+ <-- NIC: Private IP: 172.16.0.2 | | Default Gateway: 172.16.0.1 | Windows 2000 | | | +-------+--------+ <-- Wireless Adapter (D-Link DWL-120 USB) | IP: 192.168.0.1 | Default Gateway: 172.16.0.2 | +---..))) (Wireless LAN, Ad-Hoc mode) +---..))) | | +------------------+ <-- Wireless Adapter (D-Link DWL-120 USB) | Notebook - WinXP | IP: 192.168.0.2 +------------------+ Default Gateway: 192.168.0.1 _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 15: 4: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from avengers.ivision.co.uk (avengers.ivision.co.uk [212.25.225.7]) by hub.freebsd.org (Postfix) with ESMTP id 650C037B40B for ; Tue, 11 Jun 2002 15:04:03 -0700 (PDT) Received: from [212.25.225.7] (helo=avengers) by avengers.ivision.co.uk with esmtp (Exim 3.33 #1) id 17Htk8-0002KE-00; Tue, 11 Jun 2002 23:04:00 +0100 Date: Tue, 11 Jun 2002 23:04:00 +0100 (BST) From: Jasper Wallace To: Kim Okasawa Cc: Subject: Re: FreeBSD+Win2K+Wireless LAN In-Reply-To: Message-ID: X-NCC-RegID: uk.instant-web 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, 12 Jun 2002, Kim Okasawa wrote: > Dear all, > > I want to set up my home network to take advantage of the D-Link DWL-120 USB > wireless adapter. I have set up the network as follow (see graph below), > and the FreeBSD and Win2K boxes can access to the Internet but the WinXP > notebook computer CAN NOT. I know somewhere along the line I did something > wrong. Can someone help me to fix the problem? Thank you. The freebsd machine dosn't know where to send packets for 192.168.0.2 to - add a static route like: route add -net 192.168.0.0/24 172.16.0.2 (i'm guessing the netmask there, it may be /16). Also the win2k box will need ip forwarding enabled (routing). (i have no idea how to do that - i've only used win2k breifly). I'm confused by the win2k machine having two default gateways - 172.16.0.2 and 172.16.0.1 - it should only need 172.16.0.1. I wrote a very basic guide to tcpip routing for consume.net - it describes almost exactly the problem you are having, you can find it here: http://pointless.net/~jasper/consume/docs/my-docs/routeing-intro.html > .-------------. > ( Internet ) > .------+------. > | > | > +------+------+ > | Cable Modem | > +------+------+ > | > | > +-------+--------+ <-- NIC (rl0): (DHCP) get ip from comcast > | FreeBSD 4.5 | > | Running natd. | > +-------+--------+ <-- NIC (fxp0): Private IP: 172.16.0.1 > | > | > | > +-------+--------+ <-- NIC: Private IP: 172.16.0.2 > | | Default Gateway: 172.16.0.1 > | Windows 2000 | > | | > +-------+--------+ <-- Wireless Adapter (D-Link DWL-120 USB) > | IP: 192.168.0.1 > | Default Gateway: 172.16.0.2 > | > +---..))) > > > (Wireless LAN, Ad-Hoc mode) > > > +---..))) > | > | > +------------------+ <-- Wireless Adapter (D-Link DWL-120 USB) > | Notebook - WinXP | IP: 192.168.0.2 > +------------------+ Default Gateway: 192.168.0.1 -- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 18: 1:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d15.as8.nwbl0.wi.voyager.net [169.207.132.15]) by hub.freebsd.org (Postfix) with ESMTP id 8D3E437B408 for ; Tue, 11 Jun 2002 18:01:51 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g5C13I9I025990; Tue, 11 Jun 2002 20:03:18 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g5C13GXW025987; Tue, 11 Jun 2002 20:03:17 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Tue, 11 Jun 2002 20:03:16 -0500 (CDT) From: Mike Silbersack To: Phil Dibowitz Cc: Mikael Olsson , Jean-Yves Lefort , , Subject: Re: Broken PMTUD in FreeBSD? In-Reply-To: <3D062B0A.90803@ipom.com> Message-ID: <20020611195604.T25854-100000@patrocles.silby.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 Tue, 11 Jun 2002, Phil Dibowitz wrote: > Ahhh. Sounds like many of the bugs I've found in my own software. Yep, just an oversight. There have been larger, more serious ones. :) > > Phil: In the future, please try a bit harder to notify someone if you > > believe that a bug is serious enough for posting to bugtraq. freebsd-net > > is a relatively busy list, and things do get missed. > > Certainly. I appologize if I caused the FreeBSD developers any grief over my > post. I'm not a FreeBSD user myself and wasn't aware of the > http://www.freebsd.org/send-pr.html page until yesterday. I did submit a bug > report there yesterday, which got assigned an ID of kern/39141, so when you > commit the fix, you can update/close that case as well. Thanks again for your > quick response. > > > Phil Dibowitz I don't think you caused any grief; releasing this information didn't hurt anyone. Had it been some remotely exploitable bug which was not yet patched, then I would be annoyed. For the record, filing a PR isn't always enough, either. There are a lot filed, and we often get very behind on them. :) So, if you do find a security issue in the future, please directly e-mail security-officer@freebsd.org so that it gets handled properly. If you find less serious bugs, feel free to drop me an e-mail if mail to the -net list falls on deaf ears. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 18:27:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from tomts17-srv.bellnexxia.net (tomts17.bellnexxia.net [209.226.175.71]) by hub.freebsd.org (Postfix) with ESMTP id 707BD37B408; Tue, 11 Jun 2002 18:27:50 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.95.179.11]) by tomts17-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020612012749.QXJH2581.tomts17-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 11 Jun 2002 21:27:49 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.3/8.11.3) with SMTP id g5C0Dxb81927; Tue, 11 Jun 2002 20:13:59 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <006601c211b0$5cc44c80$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: , Subject: Problems with PPP and one annoying ISP Date: Tue, 11 Jun 2002 21:27:48 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0063_01C2118E.D5526410" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C2118E.D5526410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I've got this ISP who won't provide support for UNIX that I have to get working on UNIX. I can dial up to the ISP perfectly fine using Windows 95, but whenever I try and configure my FreeBSD machine to dial up, ppp never works right. Here's the chunk of my ppp.conf: [dumbisp] set authname **** set authkey **** set phone 17603320155 add default HISADDR As you can see, pretty plain-vanilla. When I dial interactively, I see "PPp>" and then the modem hangs up. I'm not sure why, but it just is. I'm passing the PAP authentication phase, so I know I haven't typed in my password incorrectly. Attached is the output in /var/log/ppp.log (gzipped, since hub refused my message the first time around.). If there are any PPP wizards out there who can help me through this, it would be greatly appreciated. -- Matt Emmerton ------=_NextPart_000_0063_01C2118E.D5526410 Content-Type: application/x-gzip; name="ppp.log.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ppp.log.gz" H4sICDycBj0AA3BwcC5sb2cA7Zptb+I4EMff36eY2xen9tQuDk9tI93pcgnc0i2Q5aFvqp5kggu5 QpJNnD58+7NDAjQhiZ2yt9JpqVQK0vw8nvl7xnZ6HTqgKFBHagupzTYs8Gz2Cp7n3TVaF/cq0NBB Kujueo2duQq1OXmqUfqqwtzGK/jpWsjcXOKAqDALnfmKvXcCimcrO1hK2s/Jw8p2HlWwVm5A5nD+ O7gecWxnURWku45DLErmP1clJA4wX2Qioi8x5TDXYTDloo0ajTpSWi05+60XBh8aU0rWHgUF3Af2 S4o0Jjy72uTvvpxd58Vj8Ttpnaow/Jw2vSg0HRGL2E8kHjY7sKj18LOsbTLZX7pKR/mCZM2PNOft 6N9j6sZkT3RZyJVIAJqIRUAfDgYdffIGoKioGLAfhpQnKV8kUIkn9ctLhGra6EvtttGs3Whmv3bb rP/ZG4uj04s8WtlshVvY923ipzAKEsRExdMKMVaYtwb7nka1pyou8YY5tnIXtlOVszHmFMsTZdzo pgrdcV+FacDL34eY9gFwABioj53Ac30qxdt6NKaYErCW2FkQ6Dk2jeLPPNQ3hf/90BjEmWPqel4W qghBb/Ar8Rk5O1Mxe74eWRN6sBcj8vVEOYUg8vK3Sl6Bpnf1Yd+8q9/L2Zmj4WRYyVLT9b5m3rXv Ab2g+CVH6I+md817UFrShtpfPX0w7W8Gb1tKizQblxXTsK+NJPRcHCwr5yxHmew235fdStiC9Bbb FaW3bMTy9BYTCtJbYiiUXrE8sCbxtMmDZj2+Ow+HVbNFcdmwYc5H1lNm+bYk3eWyabZ2/lbiprOI D2WxhDCdfIpUxHOJXixUb8CJqZmncpi3OUUXFkKENOQYRWIuC0Pe8inxepRouN6Us+wMDKM31vl0 b1yL9TBtPvdZw8VKNWHs15N/jiCMyjPLk2r7h1S/q1S/neB44fyR3v9bevcb2DajvIENPeJkd59i 1GhPPM0cJfKMU5dDWkiXrI3aFndNDrH1YGkHTKJMFWewth0uV8d1ZGkm9mAYUi/kFy3Wgh0q/+Di t60wwPBr/EozL78Bs+SUypk9J0KOp7reGY/hJLMa8hg9k6duc4ajvr1YsPMkZqIiQQDoY/QjitIr HgkLeVWPhGLQ3entoxSgb5odFQYuBZa32YrAs02XbkhB/6SZl5nFKDjDvMNChRmC0eneaJMOL5LP 7HCvtOTMzVHHUHh5OkKy9o7aedtt0XsYfkERX/pKIpLqMiD02fUf5ZbHEUW9AR5b1SlqBVmn/TqO FjdU9qYZxoh3LdmaEgN4s9w0fc5Q2nB7DcHKpUG08KI/wXLXHi9btiusjaJkvEO12R3yhPisDzF6 tEm+2IXzcJsVA0dZNtxn4elmt3Zbv6Ld3ZH8ehPGGLS9Z0s/q6lWUt6ctSOhV+ZGUezajh0s5XpA 3t1R7Az3LFnQFatdVOYOX8tWUfS7gnaowkhGbYOIn7gBtddsrggCYgX83bUoYevZds52H3hHlYJz kIetxx0p+SSNAupSljoEs1dKghpz8ww8gh/3vwFWaiYhgTS3jlD9GBk7gpiSvrdd6Sn7uuhDAj1+ 2MDKYjqSuYyyO9ZkajliFOTuafEojpXGXDhmhh1Yhx8wS0DiPc/KXWQ1/B97snGBOcNDFaaLkriU 3pSARjOuAQ22aPaqQENp5tcB4bFUvvXdLwlXBSWhjBrXBHbISxeFq3ZJVWDoA1VBeBpxwPkjyEMb sDJOUgUMgjOmeQ9IDvzLx9fQzoQszzw5nJrmrvbM4cRx/TVenbKm8S+g7vo7eSIAAA== ------=_NextPart_000_0063_01C2118E.D5526410-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 19:11:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 2ECFD37B409 for ; Tue, 11 Jun 2002 19:11:12 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g5C2B806090085; Wed, 12 Jun 2002 03:11:09 +0100 (BST) (envelope-from brian@FreeBSD.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g5C2B6aM040269; Wed, 12 Jun 2002 03:11:06 +0100 (BST) (envelope-from brian@FreeBSD.org) Date: Wed, 12 Jun 2002 03:11:06 +0100 From: Brian Somers To: "Matthew Emmerton" Cc: freebsd-net@FreeBSD.org Subject: Re: Problems with PPP and one annoying ISP Message-Id: <20020612031106.27aa2caf.brian@FreeBSD.org> In-Reply-To: <006601c211b0$5cc44c80$1200a8c0@gsicomp.on.ca> References: <006601c211b0$5cc44c80$1200a8c0@gsicomp.on.ca> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 Hi, Does it make a difference if you set ifaddr x.x.x.x y.y.y.y in your config ? Perhaps your ISP is expecting you to specify an IP number.... I'm guessing this because the peer is bringing things down as soon as you send an IPCP request for 0.0.0.0. On Tue, 11 Jun 2002 21:27:48 -0400, "Matthew Emmerton" wrote: > I've got this ISP who won't provide support for UNIX that I have to get > working on UNIX. > > I can dial up to the ISP perfectly fine using Windows 95, but whenever I try > and configure my FreeBSD machine to dial up, ppp never works right. > > Here's the chunk of my ppp.conf: > > [dumbisp] > set authname **** > set authkey **** > set phone 17603320155 > add default HISADDR > > As you can see, pretty plain-vanilla. > > When I dial interactively, I see "PPp>" and then the modem hangs up. I'm > not sure why, but it just is. I'm passing the PAP authentication phase, so > I know I haven't typed in my password incorrectly. > > Attached is the output in /var/log/ppp.log (gzipped, since hub refused my > message the first time around.). If there are any PPP wizards > out there who can help me through this, it would be greatly appreciated. > > -- > Matt Emmerton -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 11 19:59:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from tomts26-srv.bellnexxia.net (tomts26.bellnexxia.net [209.226.175.189]) by hub.freebsd.org (Postfix) with ESMTP id 9DE2A37B401; Tue, 11 Jun 2002 19:59:38 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.95.179.11]) by tomts26-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20020612025934.HLQH8711.tomts26-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 11 Jun 2002 22:59:34 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.3/8.11.3) with SMTP id g5C1jlb82126; Tue, 11 Jun 2002 21:45:47 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002d01c211bd$2fa9bf20$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Brian Somers" Cc: References: <006601c211b0$5cc44c80$1200a8c0@gsicomp.on.ca> <20020612031106.27aa2caf.brian@FreeBSD.org> Subject: Re: Problems with PPP and one annoying ISP Date: Tue, 11 Jun 2002 22:59:35 -0400 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.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 Sadly, no. The connection comes down even if I specify the static IP (with or without the netmask) that we're supposed to get. I left it out because on Win95 I say "obtain IP address automatically" which DTRT. Matt ----- Original Message ----- From: "Brian Somers" To: "Matthew Emmerton" Cc: Sent: Tuesday, June 11, 2002 10:11 PM Subject: Re: Problems with PPP and one annoying ISP > Hi, > > Does it make a difference if you > > set ifaddr x.x.x.x y.y.y.y > > in your config ? Perhaps your ISP is expecting you to specify an IP > number.... I'm guessing this because the peer is bringing things down > as soon as you send an IPCP request for 0.0.0.0. > > On Tue, 11 Jun 2002 21:27:48 -0400, "Matthew Emmerton" wrote: > > I've got this ISP who won't provide support for UNIX that I have to get > > working on UNIX. > > > > I can dial up to the ISP perfectly fine using Windows 95, but whenever I try > > and configure my FreeBSD machine to dial up, ppp never works right. > > > > Here's the chunk of my ppp.conf: > > > > [dumbisp] > > set authname **** > > set authkey **** > > set phone 17603320155 > > add default HISADDR > > > > As you can see, pretty plain-vanilla. > > > > When I dial interactively, I see "PPp>" and then the modem hangs up. I'm > > not sure why, but it just is. I'm passing the PAP authentication phase, so > > I know I haven't typed in my password incorrectly. > > > > Attached is the output in /var/log/ppp.log (gzipped, since hub refused my > > message the first time around.). If there are any PPP wizards > > out there who can help me through this, it would be greatly appreciated. > > > > -- > > Matt Emmerton > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > 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 Jun 11 20:37:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 8346F37B401 for ; Tue, 11 Jun 2002 20:37:13 -0700 (PDT) Received: from user-112159e.dsl.mindspring.com ([66.32.149.46] helo=ipom.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17HywO-0003jK-00; Tue, 11 Jun 2002 20:37:00 -0700 Message-ID: <3D06C2AD.5020502@ipom.com> Date: Tue, 11 Jun 2002 20:40:29 -0700 From: Phil Dibowitz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Mike Silbersack Cc: Mikael Olsson , Jean-Yves Lefort , freebsd-net@freebsd.org, mss@ipom.com Subject: Re: Broken PMTUD in FreeBSD? References: <20020611195604.T25854-100000@patrocles.silby.com> 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 Mike Silbersack wrote: > I don't think you caused any grief; releasing this information didn't hurt > anyone. Had it been some remotely exploitable bug which was not yet > patched, then I would be annoyed. > > For the record, filing a PR isn't always enough, either. There are a lot > filed, and we often get very behind on them. :) > > So, if you do find a security issue in the future, please directly e-mail > security-officer@freebsd.org so that it gets handled properly. If you > find less serious bugs, feel free to drop me an e-mail if mail to the -net > list falls on deaf ears. Had it been a security flaw I would have looked for a security list and posted atleast twice. With this bug, I posted, gave it sometime, and went to bugtraq cause I figured it wouldn't be a big deal and maybe someone on that list would know something I didn't. Glad it's fixed, and thanks for the info. Phil -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 12 0:30:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d135.as15.nwbl0.wi.voyager.net [169.207.136.73]) by hub.freebsd.org (Postfix) with ESMTP id 308BE37B407 for ; Wed, 12 Jun 2002 00:30:37 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g5C7W69I027275; Wed, 12 Jun 2002 02:32:06 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g5C7W2hG027272; Wed, 12 Jun 2002 02:32:03 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 12 Jun 2002 02:32:02 -0500 (CDT) From: Mike Silbersack To: Phil Dibowitz Cc: Mikael Olsson , Jean-Yves Lefort , , Subject: Re: Broken PMTUD in FreeBSD? In-Reply-To: <3D06C2AD.5020502@ipom.com> Message-ID: <20020612023120.Q27256-100000@patrocles.silby.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 Tue, 11 Jun 2002, Phil Dibowitz wrote: > Glad it's fixed, and thanks for the info. > > > Phil Well, it's not fixed yet, but it will be. (Probably a week at least, I don't have the time to devote to it right now, despite it being a simple change.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 12 1:39:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.fr.ipricot.com (imaps.fr.ipricot.com [195.154.74.8]) by hub.freebsd.org (Postfix) with ESMTP id 513C137B40D for ; Wed, 12 Jun 2002 01:39:23 -0700 (PDT) Received: from jeff2.fr.ipricot.com (omuffatjoly.fr.ipricot.com [192.168.31.184]) by mail.fr.ipricot.com (8.12.2/8.12.2) with SMTP id g5C8dG8J056999; Wed, 12 Jun 2002 10:39:20 +0200 (CEST) (envelope-from jean-francois.legros@ipricot.com) Date: Wed, 12 Jun 2002 10:39:17 +0200 From: jean-francois.legros@ipricot.com To: "Jasper Wallace" Cc: kimokasawa@hotmail.com, freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD+Win2K+Wireless LAN Message-Id: <20020612103917.6f643522.jean-francois.legros@ipricot.com> In-Reply-To: References: Organization: IPricot X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i386-portbld-freebsd4.6) 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 In his (her ?) last exciting post, with subject: Re: FreeBSD+Win2K+Wireless LAN, "Jasper Wallace" wrote: > On Wed, 12 Jun 2002, Kim Okasawa wrote: > Also the win2k box will need ip forwarding enabled (routing). (i have no > idea how to do that - i've only used win2k breifly). Where is my sysctl net.inet.ip.forwarding ?? IP forwading (routing) is a service in win2K ! Just start it from the Services listing, do not forget to set it to starting mode : auto in case of reboot. -- TCHO Jeff ---- Jean-François Legros jean-francois.legros@ipricot.com IPricot European Headquarters Tel +33 (0) 1 46 52 53 00 10-12 Avenue de Verdun Fax +33 (0) 1 46 52 53 02 F-92250 LA GARENNE-COLOMBES http://www.IPricot.com/ FRANCE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 12 7:22:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f67.law11.hotmail.com [64.4.17.67]) by hub.freebsd.org (Postfix) with ESMTP id E398B37B401 for ; Wed, 12 Jun 2002 07:22:25 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 12 Jun 2002 07:22:25 -0700 Received: from 152.75.99.55 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 12 Jun 2002 14:22:24 GMT X-Originating-IP: [152.75.99.55] From: "Kim Okasawa" To: jasper@ivision.co.uk Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD+Win2K+Wireless LAN Date: Wed, 12 Jun 2002 23:22:24 +0900 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2002 14:22:25.0814 (UTC) FILETIME=[93389B60:01C2121C] 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 Thanks for the info. I added the route to the FreeBSD box and it can now ping the notebook computer but NOT vice versa (i.e. notebook cannot ping the FBSD box.) Any idea what might be wrong? Thanks. BTW, I did set the Win2K's 2nd NIC's gateway to 172.16.0.1. Sorry for the typo. Kim ----Original Message Follows---- From: Jasper Wallace To: Kim Okasawa CC: Subject: Re: FreeBSD+Win2K+Wireless LAN Date: Tue, 11 Jun 2002 23:04:00 +0100 (BST) On Wed, 12 Jun 2002, Kim Okasawa wrote: > Dear all, > > I want to set up my home network to take advantage of the D-Link DWL-120 USB > wireless adapter. I have set up the network as follow (see graph below), > and the FreeBSD and Win2K boxes can access to the Internet but the WinXP > notebook computer CAN NOT. I know somewhere along the line I did something > wrong. Can someone help me to fix the problem? Thank you. The freebsd machine dosn't know where to send packets for 192.168.0.2 to - add a static route like: route add -net 192.168.0.0/24 172.16.0.2 (i'm guessing the netmask there, it may be /16). Also the win2k box will need ip forwarding enabled (routing). (i have no idea how to do that - i've only used win2k breifly). I'm confused by the win2k machine having two default gateways - 172.16.0.2 and 172.16.0.1 - it should only need 172.16.0.1. I wrote a very basic guide to tcpip routing for consume.net - it describes almost exactly the problem you are having, you can find it here: http://pointless.net/~jasper/consume/docs/my-docs/routeing-intro.html > .-------------. > ( Internet ) > .------+------. > | > | > +------+------+ > | Cable Modem | > +------+------+ > | > | > +-------+--------+ <-- NIC (rl0): (DHCP) get ip from comcast > | FreeBSD 4.5 | > | Running natd. | > +-------+--------+ <-- NIC (fxp0): Private IP: 172.16.0.1 > | > | > | > +-------+--------+ <-- NIC: Private IP: 172.16.0.2 > | | Default Gateway: 172.16.0.1 > | Windows 2000 | > | | > +-------+--------+ <-- Wireless Adapter (D-Link DWL-120 USB) > | IP: 192.168.0.1 > | Default Gateway: 172.16.0.1 > | > +---..))) > > > (Wireless LAN, Ad-Hoc mode) > > > +---..))) > | > | > +------------------+ <-- Wireless Adapter (D-Link DWL-120 USB) > | Notebook - WinXP | IP: 192.168.0.2 > +------------------+ Default Gateway: 192.168.0.1 _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 12 17:20:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id EA00C37B408 for ; Wed, 12 Jun 2002 17:20:48 -0700 (PDT) Received: from user-uivefeb.dsl.mindspring.com ([165.247.61.203] helo=compaq) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 17IILz-0006NA-00; Wed, 12 Jun 2002 20:20:43 -0400 Message-ID: <002201c21270$75c6dfc0$5ab9fea9@compaq> From: "Naga Narayanaswamy" To: "Matthew Emmerton" Cc: References: <006601c211b0$5cc44c80$1200a8c0@gsicomp.on.ca> <20020612031106.27aa2caf.brian@FreeBSD.org> <002d01c211bd$2fa9bf20$1200a8c0@gsicomp.on.ca> Subject: Re: Problems with PPP and one annoying ISP Date: Wed, 12 Jun 2002 20:22:53 -0400 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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 In your config, are you negotiating anything related to VJ compression ? Did you try increasing timeout values ? ----- Original Message ----- From: "Matthew Emmerton" To: "Brian Somers" Cc: Sent: Tuesday, June 11, 2002 10:59 PM Subject: Re: Problems with PPP and one annoying ISP > Sadly, no. The connection comes down even if I specify the static IP (with > or without the netmask) that we're supposed to get. I left it out because > on Win95 I say "obtain IP address automatically" which DTRT. > > Matt > > ----- Original Message ----- > From: "Brian Somers" > To: "Matthew Emmerton" > Cc: > Sent: Tuesday, June 11, 2002 10:11 PM > Subject: Re: Problems with PPP and one annoying ISP > > > > Hi, > > > > Does it make a difference if you > > > > set ifaddr x.x.x.x y.y.y.y > > > > in your config ? Perhaps your ISP is expecting you to specify an IP > > number.... I'm guessing this because the peer is bringing things down > > as soon as you send an IPCP request for 0.0.0.0. > > > > On Tue, 11 Jun 2002 21:27:48 -0400, "Matthew Emmerton" > wrote: > > > I've got this ISP who won't provide support for UNIX that I have to get > > > working on UNIX. > > > > > > I can dial up to the ISP perfectly fine using Windows 95, but whenever I > try > > > and configure my FreeBSD machine to dial up, ppp never works right. > > > > > > Here's the chunk of my ppp.conf: > > > > > > [dumbisp] > > > set authname **** > > > set authkey **** > > > set phone 17603320155 > > > add default HISADDR > > > > > > As you can see, pretty plain-vanilla. > > > > > > When I dial interactively, I see "PPp>" and then the modem hangs up. > I'm > > > not sure why, but it just is. I'm passing the PAP authentication phase, > so > > > I know I haven't typed in my password incorrectly. > > > > > > Attached is the output in /var/log/ppp.log (gzipped, since hub refused > my > > > message the first time around.). If there are any PPP wizards > > > out there who can help me through this, it would be greatly appreciated. > > > > > > -- > > > Matt Emmerton > > > > -- > > Brian > > > > Don't _EVER_ lose your sense of humour ! > > > > 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 Wed Jun 12 17:22: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 17B9B37B41B for ; Wed, 12 Jun 2002 17:21:49 -0700 (PDT) Received: from isi.edu (m685sms57u3eg15z@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5D0Lmr29425 for ; Wed, 12 Jun 2002 17:21:48 -0700 (PDT) Message-ID: <3D07E59A.7000702@isi.edu> Date: Wed, 12 Jun 2002 17:21:46 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org Subject: netgraph encryption? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060702090807000506070401" 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 cryptographically signed message in MIME format. --------------ms060702090807000506070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, anyone know of a netgraph node that implements decent-strength encryption (Blowfish, etc.)? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms060702090807000506070401 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxMzAwMjE0OFowIwYJKoZIhvcNAQkEMRYEFFx3ObXepm0i Sw+pgpO9LXFCOmPdMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAubs+RueCudtnoovg4dhNsPO800ZNsXjTY0WyYIiSkcRWU RoJh2ODnAiZa8S1497+QSaAcpOGt1PDOl3NOsloWX5GKkVxzmgdPNoiMibVdMKoYC3MxDQ8Y vzuBeIrCHgmBeBaOEmq1oCgt+SidoS+hXeJ75OtEjt9KBn0Wkg2iiwAAAAAAAA== --------------ms060702090807000506070401-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 12 22:15:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 756B237B407 for ; Wed, 12 Jun 2002 22:15:09 -0700 (PDT) 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 WAA53393; Wed, 12 Jun 2002 22:08:38 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5D58J517220; Wed, 12 Jun 2002 22:08:19 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206130508.g5D58J517220@arch20m.dellroad.org> Subject: Re: netgraph encryption? In-Reply-To: <3D07E59A.7000702@isi.edu> "from Lars Eggert at Jun 12, 2002 05:21:46 pm" To: Lars Eggert Date: Wed, 12 Jun 2002 22:08:19 -0700 (PDT) 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 Lars Eggert writes: > anyone know of a netgraph node that implements decent-strength > encryption (Blowfish, etc.)? None that I know of... ng_mppc(4) implements lame-strength encryption. It would be easy to write one. The only complexity is dealing with lost packets and synchronizing state. -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 Thu Jun 13 0: 2:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id CA2C837B43D for ; Thu, 13 Jun 2002 00:02:23 -0700 (PDT) Received: from isi.edu (c1-vpn4.isi.edu [128.9.176.34]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5D72Mr25422; Thu, 13 Jun 2002 00:02:22 -0700 (PDT) Message-ID: <3D08437A.1060005@isi.edu> Date: Thu, 13 Jun 2002 00:02:18 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Archie Cobbs Cc: net@FreeBSD.ORG Subject: Re: netgraph encryption? References: <200206130508.g5D58J517220@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090905060400050509060209" 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 cryptographically signed message in MIME format. --------------ms090905060400050509060209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie Cobbs wrote: >>anyone know of a netgraph node that implements decent-strength >>encryption (Blowfish, etc.)? > > None that I know of... > > ng_mppc(4) implements lame-strength encryption. I looked briefly at ng_mppc but and was under the impression it needed a ppp node above it. The packets I'd like to feed to an encryption node are UDP (and soon TCP and IP). Or am I wrong? Lars -- Lars Eggert USC Information Sciences Institute --------------ms090905060400050509060209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxMzA3MDIxOFowIwYJKoZIhvcNAQkEMRYEFCW1d2Aue+Wt RiNwyX6JfS4lmYyiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCf020I1vhV8saBgPpSp1g0ndgiGSQH+UnZBXXU4HOLAqau TKIxAE7YI8Z0NnnJtXZlUtCM9TX4K3hWraTQCX/xeEqL79coGjzPB/HNjIdx4OF9nEe3PEIE 2oQkuv7E2XYpQjF4xiw9XDyMEw83rChjadFAojygrhqVHNfxgpQUsAAAAAAAAA== --------------ms090905060400050509060209-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 7:28:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from avengers.ivision.co.uk (avengers.ivision.co.uk [212.25.225.7]) by hub.freebsd.org (Postfix) with ESMTP id 9FBC737B438 for ; Thu, 13 Jun 2002 07:28:22 -0700 (PDT) Received: from [212.25.225.7] (helo=avengers) by avengers.ivision.co.uk with esmtp (Exim 3.33 #1) id 17IVFM-0007gb-00; Thu, 13 Jun 2002 15:06:44 +0100 Date: Thu, 13 Jun 2002 15:06:44 +0100 (BST) From: Jasper Wallace To: Kim Okasawa Cc: Subject: Re: FreeBSD+Win2K+Wireless LAN In-Reply-To: Message-ID: X-NCC-RegID: uk.instant-web 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, 12 Jun 2002, Kim Okasawa wrote: > > Thanks for the info. I added the route to the FreeBSD box and it can now > ping the notebook computer but NOT vice versa (i.e. notebook cannot ping the > FBSD box.) Any idea what might be wrong? Thanks. Probably some firewalling somewhere blocking the ping packets. since you can ping from FreeBSD -> notebook then the win2k box is forwarding packets ok. The other thing to try would be to run a packet sniffer on the FreeBSD machine when the notebook is trying to ping it and see what you get. > BTW, I did set the Win2K's 2nd NIC's gateway to 172.16.0.1. Sorry for the > typo. -- Internet Vision Internet Consultancy Tel: 020 7589 4500 60 Albert Court & Web development Fax: 020 7589 4522 Prince Consort Road vision@ivision.co.uk London SW7 2BE http://www.ivision.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 8:39:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.giranti.co.id (ns.giranti.co.id [202.95.136.78]) by hub.freebsd.org (Postfix) with SMTP id 9F2B337B40B for ; Thu, 13 Jun 2002 08:39:11 -0700 (PDT) Received: (qmail 1209 invoked by uid 1008); 13 Jun 2002 15:34:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jun 2002 15:34:51 -0000 Date: Thu, 13 Jun 2002 22:34:51 +0700 (WIT) From: hantu To: freebsd-net@freebsd.org Subject: digiboard pc/8i Message-ID: <20020613223434.S1196-100000@ns.giranti.co.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 dear ,.. i have old digiboard card pc/8i adapter, but my freebsd can't detect it :( i'm using fbsd 45R i was compile new kernel with add line with this : OPTIONS NDGBPORTS=8 OPTIONS COM_MULTIPORT device dgb0 i can't write "device dgb0 at isa? bla... bla... because if i write this my kernel can't be compile with error message " no isa ... bla.. bla.. on that line". i need help, please.... regards newbie ________________________________________________ Message sent using MAIL 0.0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" 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 Jun 13 9:18:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.giranti.co.id (ns.giranti.co.id [202.95.136.78]) by hub.freebsd.org (Postfix) with SMTP id 7F44A37B417 for ; Thu, 13 Jun 2002 09:18:05 -0700 (PDT) Received: (qmail 1261 invoked by uid 1008); 13 Jun 2002 16:08:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jun 2002 16:08:53 -0000 Date: Thu, 13 Jun 2002 23:08:53 +0700 (WIT) From: hantu To: Jonathan Lemon , Subject: Re: digiboard pc/8i In-Reply-To: <200206131549.g5DFnXD85274@prism.flugsvamp.com> Message-ID: <20020613230603.K1259-100000@ns.giranti.co.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, 13 Jun 2002, Jonathan Lemon wrote: > In article you write: > > > >dear ,.. > >i have old digiboard card pc/8i adapter, but my freebsd can't detect it :( > >i'm using fbsd 45R > >i was compile new kernel with add line with this : > >OPTIONS NDGBPORTS=8 > >OPTIONS COM_MULTIPORT > >device dgb0 > > > >i can't write "device dgb0 at isa? bla... bla... > >because if i write this my kernel can't be compile with error message " no > >isa ... bla.. bla.. on that line". > > Make sure that you have "device isa0" in your config file as well. > -- > Jonathan > the problem was fix it but, still can't detect digiboard :( any suggestion ? thanks regards saaal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 11:10: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from web13301.mail.yahoo.com (web13301.mail.yahoo.com [216.136.175.37]) by hub.freebsd.org (Postfix) with SMTP id E001637B41B for ; Thu, 13 Jun 2002 11:09:56 -0700 (PDT) Message-ID: <20020613180956.54535.qmail@web13301.mail.yahoo.com> Received: from [206.220.224.4] by web13301.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 11:09:56 PDT Date: Thu, 13 Jun 2002 11:09:56 -0700 (PDT) From: Maksim Yevmenkin Subject: Bluetooth stack for FreeBSD To: current@freebsd.net Cc: 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 [cc: mobile@freebsd.org] Hackers, Another developer snapshot is available at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020613.tar.gz This release is for -current DP1 only. I had to downgrade back to DP1 due to huge amount of changes in -current. Brief list of changes - Basic support for USB devices. I got myself a 3Com USB Bluetooth dongle (aka ToothBrush :) - Make everything GCC 3.X friendly. - Minor bug fixes As always, i would like to get some feedback. I'm very interested to hear from people who familiar with FreeBSD kernel, Netgraph, Bluetooth and/or USB. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 11:41:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id 6051C37B433 for ; Thu, 13 Jun 2002 11:41:55 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020613184018.GPQH1024.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 13 Jun 2002 18:40:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA95054; Thu, 13 Jun 2002 11:34:59 -0700 (PDT) Date: Thu, 13 Jun 2002 11:34:58 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: current@freebsd.net, net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: <20020613180956.54535.qmail@web13301.mail.yahoo.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 what a coincidence! I was just discussing this with people here at USENIX and I'd like to start the process for committing this. Do you think it deserves a separate directory under netgraph, or maybe a netbluetooth directory. the documentation needs to be made 'commit-ready' too, as well as some examples ready to put in /usr/share/examples/netgraph. On Thu, 13 Jun 2002, Maksim Yevmenkin wrote: > [cc: mobile@freebsd.org] > > Hackers, > > Another developer snapshot is available at > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020613.tar.gz > > This release is for -current DP1 only. I had to > downgrade back to DP1 due to huge amount of changes > in -current. > > Brief list of changes > > - Basic support for USB devices. I got myself a > 3Com USB Bluetooth dongle (aka ToothBrush :) > > - Make everything GCC 3.X friendly. > > - Minor bug fixes > > As always, i would like to get some feedback. I'm very > interested to hear from people who familiar with FreeBSD > kernel, Netgraph, Bluetooth and/or USB. > > thanks, > max > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.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 Thu Jun 13 12: 3:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id DFDE537B410; Thu, 13 Jun 2002 12:03:45 -0700 (PDT) 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 LAA57729; Thu, 13 Jun 2002 11:35:07 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5DIYkE19471; Thu, 13 Jun 2002 11:34:46 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206131834.g5DIYkE19471@arch20m.dellroad.org> Subject: Re: mpd for pptp - can't connect In-Reply-To: "from Dan Langille at Jun 13, 2002 07:52:12 am" To: Dan Langille Date: Thu, 13 Jun 2002 11:34:46 -0700 (PDT) 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 [ moving discussion to freebsd-net ] Dan Langille writes: > A while back, mpd was suggested as a pptp client. I've started looking at > it. However, I'm having trouble getting it to connect. The office has a > MS server and I'm trying to connect using mpd. FWIW, I can connect via > pptp-client. > > The office IP is 1.2.3.4 > My dual homed gateway has an internal address of 192.168.0.21 (ie. that's > my default address for boxes on the home LAN). > The office server has internal address of 10.0.0.18 > I can connect using MS CHAP V2, MPPE 128, MPPC from my W2K box. > > Of note, I see this in the logs but don't know the significance: "pptp0: > CID 0xbc51 in SetLinkInfo not found" That can be safely ignored. Just another harmless Windows bug. > vpn: > new -i ng1 vpn vpn > set iface disable on-demand > set iface addrs 192.168.0.21 10.0.1.18 > set iface idle 0 > set iface route 10.0.1.0/24 > set pptp peer 1.2.3.4 > set bundle disable multilink > set bundle authname dan > set bundle password secret > set link yes acfcomp protocomp > set link no pap > set link enable chap ^^^^^^^^^^^^^^^^^^^^ > set link accept chap > set ipcp no vjcomp Try "set link disable chap" instead. The Windows box may be getting confused when you try to authenticate 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 Thu Jun 13 12: 4:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from web13305.mail.yahoo.com (web13305.mail.yahoo.com [216.136.175.41]) by hub.freebsd.org (Postfix) with SMTP id 4FF6237B406 for ; Thu, 13 Jun 2002 12:04:03 -0700 (PDT) Message-ID: <20020613190255.8938.qmail@web13305.mail.yahoo.com> Received: from [206.220.224.4] by web13305.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 12:02:55 PDT Date: Thu, 13 Jun 2002 12:02:55 -0700 (PDT) From: Maksim Yevmenkin Subject: Re: Bluetooth stack for FreeBSD To: Julian Elischer Cc: current@freebsd.org, net@freebsd.org In-Reply-To: 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 Julian, > I was just discussing this with people here at USENIX and I'd like to > start the process for committing this. Oh, gee, thanks :) but, i'm not so sure about committing. There are several important bits and pieces that needed to be done. First of all, i do want to see properly tested code with all documentation in the tree. I cannot say this about current snapshots. Things that MUST be fixed *before* commiting (IMO) sorted by priority - Documentation, examples & man pages - Multiple control hooks for HCI/L2CAP nodes - HCI/L2CAP tools > Do you think it deserves a separate directory under netgraph, > or maybe a netbluetooth directory. I'd rather not put it under netbluetooth, because it is a Netgraph specific code. It probably makes sense to put it somewhere under netgraph directory. > the documentation needs to be made 'commit-ready' too, as well as some > examples ready to put in /usr/share/examples/netgraph. yeah, i know... i really should spend some time and write all documentation. thanks, max __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 12: 6:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from m20.unixathome.org (m20.unixathome.org [216.187.106.227]) by hub.freebsd.org (Postfix) with ESMTP id 8A1F337B44B for ; Thu, 13 Jun 2002 12:04:10 -0700 (PDT) Received: by m20.unixathome.org (Postfix, from userid 1001) id EEC307A11; Thu, 13 Jun 2002 15:01:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by m20.unixathome.org (Postfix) with ESMTP id B68A21F03; Thu, 13 Jun 2002 15:01:38 -0400 (EDT) Date: Thu, 13 Jun 2002 15:01:38 -0400 (EDT) From: Dan Langille X-X-Sender: dan@m20.unixathome.org To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: mpd for pptp - can't connect In-Reply-To: <200206131834.g5DIYkE19471@arch20m.dellroad.org> Message-ID: <20020613150052.P15223-100000@m20.unixathome.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 Thu, 13 Jun 2002, Archie Cobbs wrote: > [ moving discussion to freebsd-net ] > > Dan Langille writes: > > A while back, mpd was suggested as a pptp client. I've started looking at > > it. However, I'm having trouble getting it to connect. The office has a > > MS server and I'm trying to connect using mpd. FWIW, I can connect via > > pptp-client. > > > > The office IP is 1.2.3.4 > > My dual homed gateway has an internal address of 192.168.0.21 (ie. that's > > my default address for boxes on the home LAN). > > The office server has internal address of 10.0.0.18 > > I can connect using MS CHAP V2, MPPE 128, MPPC from my W2K box. > > > > Of note, I see this in the logs but don't know the significance: "pptp0: > > CID 0xbc51 in SetLinkInfo not found" > > That can be safely ignored. Just another harmless Windows bug. > > > vpn: > > new -i ng1 vpn vpn > > set iface disable on-demand > > set iface addrs 192.168.0.21 10.0.1.18 > > set iface idle 0 > > set iface route 10.0.1.0/24 > > set pptp peer 1.2.3.4 > > set bundle disable multilink > > set bundle authname dan > > set bundle password secret > > set link yes acfcomp protocomp > > set link no pap > > set link enable chap > ^^^^^^^^^^^^^^^^^^^^ > > set link accept chap > > set ipcp no vjcomp > > Try "set link disable chap" instead. The Windows box may be > getting confused when you try to authenticate it. Thanks. [root@bast:/home/dan] # /usr/local/sbin/mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 88277, version 3.8 (root@bast.unixathome.org 06:56 13-Jun-2002) [vpn] ppp node is "mpd88277-vpn" [vpn] using interface ng1 [vpn] IFACE: Open event [vpn] IPCP: Open event [vpn] IPCP: state change Initial --> Starting [vpn] IPCP: LayerStart [vpn:vpn] [vpn] bundle: OPEN event in state CLOSED [vpn] opening link "vpn"... [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Initial --> Starting [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN pptp0: connecting to 1.2.3.4:1723 [vpn] device is now in state OPENING pptp0: connected to 1.2.3.4:1723 pptp0: attached to connection with 1.2.3.4:1723 pptp0-0: outgoing call connected at 14808325 bps [vpn] PPTP call successful [vpn] device: UP event in state OPENING [vpn] device is now in state UP [vpn] link: UP event [vpn] link: origination is local [vpn] LCP: Up event [vpn] LCP: state change Starting --> Req-Sent [vpn] LCP: phase shift DEAD --> ESTABLISH [vpn] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 3edcfa59 [vpn] LCP: rec'd Configure Request #0 link 0 (Req-Sent) AUTHPROTO CHAP MSOFTv2 MAGICNUM 7ef15c22 PROTOCOMP ACFCOMP CALLBACK Not supported MP MRRU 1614 ENDPOINTDISC [LOCAL] 71 35 8f ec 71 33 4c 72 b2 5e 3e c3 c4 1f 11 c5 00 00 00 00 UNKNOWN[23] len=4 [vpn] LCP: SendConfigRej #0 CALLBACK MP MRRU 1614 UNKNOWN[23] len=4 [vpn] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 3edcfa59 [vpn] LCP: state change Req-Sent --> Ack-Rcvd [vpn] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) AUTHPROTO CHAP MSOFTv2 MAGICNUM 7ef15c22 PROTOCOMP ACFCOMP ENDPOINTDISC [LOCAL] 71 35 8f ec 71 33 4c 72 b2 5e 3e c3 c4 1f 11 c5 00 00 00 00 [vpn] LCP: SendConfigAck #1 AUTHPROTO CHAP MSOFTv2 MAGICNUM 7ef15c22 PROTOCOMP ACFCOMP ENDPOINTDISC [LOCAL] 71 35 8f ec 71 33 4c 72 b2 5e 3e c3 c4 1f 11 c5 00 00 00 00 [vpn] LCP: state change Ack-Rcvd --> Opened [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want nothing [vpn] LCP: LayerUp pptp0: CID 0xf158 in SetLinkInfo not found [vpn] CHAP: rec'd CHALLENGE #0 Name: "ROGERT" Using authname "dan" [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #0 MESG: S=BABBB2EEDA09AEB119FD3A08673B8AAC8C4587E8 [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE --> NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting --> Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 192.168.0.21 [vpn] rec'd unexpected protocol CCP on link 0, rejecting [vpn] IPCP: rec'd Configure Request #4 link 0 (Req-Sent) IPADDR 10.0.1.18 10.0.1.18 is OK [vpn] IPCP: SendConfigAck #4 IPADDR 10.0.1.18 [vpn] IPCP: state change Req-Sent --> Ack-Sent [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) IPADDR 10.0.1.26 10.0.1.26 is unacceptable [vpn] IPCP: SendConfigReq #2 IPADDR 192.168.0.21 pptp0: CID 0xf158 in SetLinkInfo not found [vpn] LCP: rec'd Terminate Request #5 link 0 (Opened) [vpn] LCP: state change Opened --> Stopping [vpn] LCP: phase shift NETWORK --> TERMINATE [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Ack-Sent --> Starting [vpn] LCP: SendTerminateAck #2 [vpn] LCP: LayerDown [vpn] LCP: rec'd Terminate Request #6 link 0 (Stopping) [vpn] LCP: SendTerminateAck #3 [vpn] LCP: state change Stopping --> Stopped [vpn] LCP: phase shift TERMINATE --> ESTABLISH [vpn] LCP: LayerFinish [vpn] device: CLOSE event in state UP pptp0-0: clearing call [vpn] device is now in state CLOSING [vpn] device: DOWN event in state CLOSING [vpn] device is now in state DOWN [vpn] link: DOWN event [vpn] LCP: Down event [vpn] LCP: state change Stopped --> Starting [vpn] LCP: phase shift ESTABLISH --> DEAD [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN [vpn] pausing 7 seconds before open [vpn] device is now in state DOWN [vpn] device: OPEN event in state DOWN [vpn] device is now in state DOWN pptp0-0: peer call disconnected res=zero? err=none pptp0-0: killing channel pptp0: closing connection with 1.2.3.4:1723 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 12:15: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 80F1537B41D for ; Thu, 13 Jun 2002 12:15:02 -0700 (PDT) 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 LAA57717; Thu, 13 Jun 2002 11:30:44 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5DIUOv19457; Thu, 13 Jun 2002 11:30:24 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206131830.g5DIUOv19457@arch20m.dellroad.org> Subject: Re: netgraph encryption? In-Reply-To: <3D08437A.1060005@isi.edu> "from Lars Eggert at Jun 13, 2002 00:02:18 am" To: Lars Eggert Date: Thu, 13 Jun 2002 11:30:24 -0700 (PDT) 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 Lars Eggert writes: > > ng_mppc(4) implements lame-strength encryption. > > I looked briefly at ng_mppc but and was under the impression it needed a > ppp node above it. The packets I'd like to feed to an encryption node > are UDP (and soon TCP and IP). Or am I wrong? In reality you can feed it anything you want. It's not PPP specific. You would however have to rig up a node that handles packets going out and returning on the same hook (ng_bpf(4) could be configured to do this). -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 Thu Jun 13 13: 0: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id C593837B423 for ; Thu, 13 Jun 2002 13:00:02 -0700 (PDT) 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 MAA58202; Thu, 13 Jun 2002 12:56:59 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5DJud819813; Thu, 13 Jun 2002 12:56:39 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206131956.g5DJud819813@arch20m.dellroad.org> Subject: Re: mpd for pptp - can't connect In-Reply-To: <20020613150052.P15223-100000@m20.unixathome.org> "from Dan Langille at Jun 13, 2002 03:01:38 pm" To: Dan Langille Date: Thu, 13 Jun 2002 12:56:39 -0700 (PDT) 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 Dan Langille writes: > [vpn] rec'd unexpected protocol CCP on link 0, rejecting The peer wants to do MPPE encryption but you haven't enabled it. > [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) > IPADDR 10.0.1.26 > 10.0.1.26 is unacceptable You need to relax your 'set ipcp ranges' as the peer wants to assign you an IP address and you're not letting it. It looks like you cut & pasted from the 'vpn' configuration instead of the 'pptp client' configuration.. ? -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 Thu Jun 13 13:15:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from m20.unixathome.org (m20.unixathome.org [216.187.106.227]) by hub.freebsd.org (Postfix) with ESMTP id 2B99E37B437 for ; Thu, 13 Jun 2002 13:15:16 -0700 (PDT) Received: by m20.unixathome.org (Postfix, from userid 1001) id A866F7A11; Thu, 13 Jun 2002 16:13:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by m20.unixathome.org (Postfix) with ESMTP id 7444C1E9C; Thu, 13 Jun 2002 16:13:46 -0400 (EDT) Date: Thu, 13 Jun 2002 16:13:46 -0400 (EDT) From: Dan Langille X-X-Sender: dan@m20.unixathome.org To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: mpd for pptp - can't connect In-Reply-To: <200206131956.g5DJud819813@arch20m.dellroad.org> Message-ID: <20020613160129.P17320-100000@m20.unixathome.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 Thu, 13 Jun 2002, Archie Cobbs wrote: > Dan Langille writes: > > [vpn] rec'd unexpected protocol CCP on link 0, rejecting > > The peer wants to do MPPE encryption but you haven't enabled it. > > > [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) > > IPADDR 10.0.1.26 > > 10.0.1.26 is unacceptable > > You need to relax your 'set ipcp ranges' as the peer wants to > assign you an IP address and you're not letting it. I did have: set ipcp ranges 192.168.0.21/32 10.0.1.18/32 I just tried: set ipcp ranges 10.0.1.0/24 10.0.1.0/24 [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #0 MESG: S=A900924089CB64D1C2696C418A9D5392FE7F289F [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE --> NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting --> Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 10.0.1.0 [vpn] rec'd unexpected protocol CCP on link 0, rejecting [vpn] IPCP: rec'd Configure Request #4 link 0 (Req-Sent) IPADDR 10.0.1.18 10.0.1.18 is OK [vpn] IPCP: SendConfigAck #4 IPADDR 10.0.1.18 [vpn] IPCP: state change Req-Sent --> Ack-Sent [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) IPADDR 10.0.1.26 10.0.1.26 is OK [vpn] IPCP: SendConfigReq #2 IPADDR 10.0.1.26 [vpn] LCP: rec'd Terminate Request #5 link 0 (Opened) [vpn] LCP: state change Opened --> Stopping [vpn] LCP: phase shift NETWORK --> TERMINATE [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Ack-Sent --> Starting [vpn] LCP: SendTerminateAck #2 [vpn] LCP: LayerDown pptp0: CID 0x4ac3 in SetLinkInfo not found [vpn] LCP: rec'd Terminate Request #6 link 0 (Stopping) [vpn] LCP: SendTerminateAck #3 [vpn] LCP: state change Stopping --> Stopped [vpn] LCP: phase shift TERMINATE --> ESTABLISH [vpn] LCP: LayerFinish [vpn] device: CLOSE event in state UP pptp0-0: clearing call [vpn] device is now in state CLOSING [vpn] device: DOWN event in state CLOSING [vpn] device is now in state DOWN [vpn] link: DOWN event [vpn] LCP: Down event [vpn] LCP: state change Stopped --> Starting [vpn] LCP: phase shift ESTABLISH --> DEAD [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN [vpn] pausing 9 seconds before open [vpn] device is now in state DOWN [vpn] device: OPEN event in state DOWN [vpn] device is now in state DOWN pptp0-0: peer call disconnected res=zero? err=none pptp0-0: killing channel pptp0: closing connection with 1.2.3.4:1723 > It looks like you cut & pasted from the 'vpn' configuration > instead of the 'pptp client' configuration.. ? Yes. I am already running ppp for my DSL connection. mpd is just for a VPN to the office. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 14:45:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 3083D37B42F for ; Thu, 13 Jun 2002 14:45:08 -0700 (PDT) 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 OAA58762; Thu, 13 Jun 2002 14:43:20 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5DLh0g20100; Thu, 13 Jun 2002 14:43:00 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206132143.g5DLh0g20100@arch20m.dellroad.org> Subject: Re: mpd for pptp - can't connect In-Reply-To: <20020613160129.P17320-100000@m20.unixathome.org> "from Dan Langille at Jun 13, 2002 04:13:46 pm" To: Dan Langille Date: Thu, 13 Jun 2002 14:43:00 -0700 (PDT) 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 Dan Langille writes: > > > [vpn] rec'd unexpected protocol CCP on link 0, rejecting > > > > The peer wants to do MPPE encryption but you haven't enabled it. > > > > > [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) > > > IPADDR 10.0.1.26 > > > 10.0.1.26 is unacceptable > > > > You need to relax your 'set ipcp ranges' as the peer wants to > > assign you an IP address and you're not letting it. > > I did have: set ipcp ranges 192.168.0.21/32 10.0.1.18/32 > > I just tried: set ipcp ranges 10.0.1.0/24 10.0.1.0/24 > > [vpn] CHAP: sending RESPONSE > [vpn] CHAP: rec'd SUCCESS #0 > MESG: S=A900924089CB64D1C2696C418A9D5392FE7F289F > [vpn] LCP: authorization successful > [vpn] LCP: phase shift AUTHENTICATE --> NETWORK > [vpn] up: 1 link, total bandwidth 64000 bps > [vpn] IPCP: Up event > [vpn] IPCP: state change Starting --> Req-Sent > [vpn] IPCP: SendConfigReq #1 > IPADDR 10.0.1.0 > [vpn] rec'd unexpected protocol CCP on link 0, rejecting > [vpn] IPCP: rec'd Configure Request #4 link 0 (Req-Sent) > IPADDR 10.0.1.18 > 10.0.1.18 is OK > [vpn] IPCP: SendConfigAck #4 > IPADDR 10.0.1.18 > [vpn] IPCP: state change Req-Sent --> Ack-Sent > [vpn] IPCP: rec'd Configure Nak #1 link 0 (Ack-Sent) > IPADDR 10.0.1.26 > 10.0.1.26 is OK > [vpn] IPCP: SendConfigReq #2 > IPADDR 10.0.1.26 > [vpn] LCP: rec'd Terminate Request #5 link 0 (Opened) ^^^^^^^^^^^^^^^^^^^^^^^ The windows box is still hanging up on you. Did you try turning on MPPE encryption? See mpd.conf.sample for how to do so. -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 Thu Jun 13 15:17: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id C7D0C37B41F for ; Thu, 13 Jun 2002 15:16:58 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g5DMCEwm004075; Thu, 13 Jun 2002 23:12:15 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [IPv6:::1]) by hak.lan.Awfulhak.org (8.12.3/8.12.3) with SMTP id g5DMC6aM086184; Thu, 13 Jun 2002 23:12:06 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Thu, 13 Jun 2002 23:12:06 +0100 From: Brian Somers To: hantu Cc: jlemon@flugsvamp.com, freebsd-net@FreeBSD.ORG Subject: Re: digiboard pc/8i Message-Id: <20020613231206.37869911.brian@Awfulhak.org> In-Reply-To: <20020613230603.K1259-100000@ns.giranti.co.id> References: <200206131549.g5DFnXD85274@prism.flugsvamp.com> <20020613230603.K1259-100000@ns.giranti.co.id> X-Mailer: Sylpheed version 0.7.5claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) 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 What does dgb say when you boot with -v ? I have one of these boards here - it worked last time I tried it.... On Thu, 13 Jun 2002 23:08:53 +0700 (WIT), hantu wrote: > > > On Thu, 13 Jun 2002, Jonathan Lemon wrote: > > > In article you write: > > > > > >dear ,.. > > >i have old digiboard card pc/8i adapter, but my freebsd can't detect it :( > > >i'm using fbsd 45R > > >i was compile new kernel with add line with this : > > >OPTIONS NDGBPORTS=8 > > >OPTIONS COM_MULTIPORT > > >device dgb0 > > > > > >i can't write "device dgb0 at isa? bla... bla... > > >because if i write this my kernel can't be compile with error message " no > > >isa ... bla.. bla.. on that line". > > > > Make sure that you have "device isa0" in your config file as well. > > -- > > Jonathan > > > > the problem was fix it but, still can't detect digiboard :( > any suggestion ? > > thanks > > regards > saaal -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 17:13:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 8DE9D37B400; Thu, 13 Jun 2002 17:13:20 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5E0DKp94630; Thu, 13 Jun 2002 17:13:20 -0700 (PDT) (envelope-from rizzo) Date: Thu, 13 Jun 2002 17:13:19 -0700 From: "'Luigi Rizzo'" To: arch@freebsd.org Subject: ipfw rewrite - new snapshot available Message-ID: <20020613171319.D93980@iguana.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 [Bcc to -net] Hi, as I mentioned in a posting to -net a few days ago, over the past weeks I have done an extensive rewrite of the ipfw code (both userland and kernel) in an attempt to make it faster, more flexible and more manageable. The code is now almost ready for commit, so I would appreciate some feedback if any of you feels like trying it and, even better, run some performance test. You can fetch the code from http://info.iet.unipi.it/~luigi/ipfw5.20020613.tgz This is for a -current after May 15th, and replaces sys/netinet/ip_fw.c sys/netinet/ip_fw.h sys/netinet/ip_dummynet.c sbin/ipfw/ipfw.c The idea behind this work was to replace the old ipfw rules (macroinstructions) with a set of microinstructions, each of them performing a single operation such as matching an address, or a port range, or a protocol flag, etc. -- much in the spirit of BPF and derivatives -- and to let the userland front-end compile ipfw(8) commands into an appropriate set of microinstructions. There are several advantages in using this technique: first of all, instructions are typically shorter and faster, because the old code had to check for the presence of all the possible options (there are over 25 of them!) in a rule, whereas the new one can simply do just the things that are required. I have implemented all the actions (accept/deny/pipe/divert/forward ...) and almost all the 25+ (ouch!) different options that can be specified in a rule. The syntax for the userland program is 100% backward compatible. I have also implemented a few extensions to demonstrate the flexibility of the new approach: you can put "or" connectives between fields, so you can write things like ipfw add allow ip from host1 or host2 or host3 or not net1/24 to any and the like, and this greatly simplifies writing rulesets as you can imagine. Other extensions (in the form of address sets, multiple rule chains to be used on layer-2 and layer-3 firewalls, etc. will be trivial to implement. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 20: 1:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 5EC4F37B428 for ; Thu, 13 Jun 2002 20:01:51 -0700 (PDT) Received: from isi.edu (jebtlxnjub72mrst@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5E31or03413; Thu, 13 Jun 2002 20:01:50 -0700 (PDT) Message-ID: <3D095C9B.6050201@isi.edu> Date: Thu, 13 Jun 2002 20:01:47 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: net@FreeBSD.ORG Subject: Re: netgraph encryption? References: <200206131830.g5DIUOv19457@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010003060700010405000308" 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 cryptographically signed message in MIME format. --------------ms010003060700010405000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie Cobbs wrote: >>I looked briefly at ng_mppc but and was under the impression it needed a >>ppp node above it. The packets I'd like to feed to an encryption node >>are UDP (and soon TCP and IP). Or am I wrong? > > In reality you can feed it anything you want. It's not PPP specific. > > You would however have to rig up a node that handles packets going > out and returning on the same hook (ng_bpf(4) could be configured > to do this). OK, I'll look into it. Or I'll try to find an undergrad to build ng_blowfish :-) As an aside, do netgraph interfaces have problems with multicast? I've seen crashes using both mrouted and pim6dd when I had a netgraph interface configured. I'll try to produce a dump next time. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010003060700010405000308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxNDAzMDE0OVowIwYJKoZIhvcNAQkEMRYEFI/vQWRur4lF chirPPxGGGcbdkhfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBxbsRVoNkRraHF6twSrmEV83Dl59KMPmpYZcfwfOnFPPuQ JqUw0of59OifeTxCmFITYFNNP5a8gtgUFnR6WPGtYyUI2H1+RsR7bIRdxc843vUMO48e5++5 J8UhhnrNvdJ5xduZoj2/SF7PoTrqyfBqY8JAK68DoR8qje6MuKNxYAAAAAAAAA== --------------ms010003060700010405000308-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 13 21:15:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 4DEE637B41D for ; Thu, 13 Jun 2002 21:15:03 -0700 (PDT) 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 VAA60875; Thu, 13 Jun 2002 21:05:22 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5E451B21338; Thu, 13 Jun 2002 21:05:01 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206140405.g5E451B21338@arch20m.dellroad.org> Subject: Re: netgraph encryption? In-Reply-To: <3D095C9B.6050201@isi.edu> "from Lars Eggert at Jun 13, 2002 08:01:47 pm" To: Lars Eggert Date: Thu, 13 Jun 2002 21:05:01 -0700 (PDT) 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 Lars Eggert writes: > As an aside, do netgraph interfaces have problems with multicast? I've > seen crashes using both mrouted and pim6dd when I had a netgraph > interface configured. I'll try to produce a dump next time. Not that I know of.. If you can get a stack trace I'd be interested in taking a look. -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 Thu Jun 13 23: 0:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by hub.freebsd.org (Postfix) with ESMTP id 67B3637B41C for ; Thu, 13 Jun 2002 23:00:19 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020614060018.JLWJ20219.sccrmhc03.attbi.com@InterJet.elischer.org>; Fri, 14 Jun 2002 06:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA97555; Thu, 13 Jun 2002 22:46:32 -0700 (PDT) Date: Thu, 13 Jun 2002 22:46:31 -0700 (PDT) From: Julian Elischer To: Lars Eggert Cc: Archie Cobbs , net@FreeBSD.ORG Subject: Re: netgraph encryption? In-Reply-To: <3D095C9B.6050201@isi.edu> 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 I haven't seen a problem with multicast and netgraph but that doesn't mean there isn't a problem. Let us see if there is a traceback. On Thu, 13 Jun 2002, Lars Eggert wrote: > Archie Cobbs wrote: > >>I looked briefly at ng_mppc but and was under the impression it needed a > >>ppp node above it. The packets I'd like to feed to an encryption node > >>are UDP (and soon TCP and IP). Or am I wrong? > > > > In reality you can feed it anything you want. It's not PPP specific. > > > > You would however have to rig up a node that handles packets going > > out and returning on the same hook (ng_bpf(4) could be configured > > to do this). > > OK, I'll look into it. Or I'll try to find an undergrad to build > ng_blowfish :-) > > As an aside, do netgraph interfaces have problems with multicast? I've > seen crashes using both mrouted and pim6dd when I had a netgraph > interface configured. I'll try to produce a dump next time. > > Lars > -- > Lars Eggert USC Information Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 8: 5:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from sbserv0.intra.selectbourse.net (APuteaux-107-2-1-3.abo.wanadoo.fr [217.128.228.3]) by hub.freebsd.org (Postfix) with ESMTP id BF96937B406 for ; Fri, 14 Jun 2002 08:05:14 -0700 (PDT) Received: from there (artik.intra.selectbourse.net [172.16.2.3]) by sbserv0.intra.selectbourse.net (Postfix) with SMTP id 56E86BAE9 for ; Fri, 14 Jun 2002 17:01:30 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Sebastien Petit To: freebsd-net@freebsd.org Subject: Problem using ng_ether Date: Fri, 14 Jun 2002 17:10:21 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020614150130.56E86BAE9@sbserv0.intra.selectbourse.net> 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've a problem with ng_ether and xl0 driver, when I connect upper <-> lower directly, packets have ip sum to 0 and a wrong tcp and udp cksum. I try to use my test code on rl0 driver, and it work fine. Julian or Archie, can you say me if I must recompute ip/tcp/udp checksum for all packets read on upper and then writed on lower hook ? Here is my code: This code must normally connect upper and lower together and so the packets flow normally upwards and downwards (like if there is nothing connected to hooks) #include #include #include #include #include #include #include #include #include #include #include #include #define HOOKNAME "myhook" #define HOOKNAME2 "myhook2" int main(int argc, char **argv) { int csock, dsock; int csock2, dsock2; struct ngm_connect ngc; struct ngm_connect ngc2; int bytesread; size_t bytesread2; unsigned char buf[4096]; char buf2[4096]; char hookname[4096]; fd_set fds; u_short *csum; int cpt; struct ether_header *eth = (struct ether_header *)buf; struct ip *iph = (struct ip *)&buf[sizeof(struct ether_header)]; struct tcphdr *tcph = (struct tcphdr *)&buf[sizeof(struct ether_header)+sizeof(struct ip)]; NgMkSockNode(NULL, &csock, &dsock); snprintf(ngc.path, sizeof(ngc.path), "xl0:"); snprintf(ngc.ourhook, sizeof(ngc.ourhook), HOOKNAME); snprintf(ngc.peerhook, sizeof(ngc.peerhook), "upper"); NgSendMsg(csock, ".", NGM_GENERIC_COOKIE, NGM_CONNECT, &ngc, sizeof(ngc)); snprintf(ngc.path, sizeof(ngc.path), "xl0:"); snprintf(ngc.ourhook, sizeof(ngc.ourhook), HOOKNAME2); snprintf(ngc.peerhook, sizeof(ngc.peerhook), "lower"); NgSendMsg(csock, ".", NGM_GENERIC_COOKIE, NGM_CONNECT, &ngc, sizeof(ngc)); for (;;) { bzero(buf, sizeof(buf)); bytesread = NgRecvData(dsock, buf, sizeof(buf), hookname); printf("bytes = %d\n", bytesread); printf("name = %s\n", hookname); if (! strcmp(hookname, "myhook")) { printf("%s !\n", hookname); NgSendData(dsock, HOOKNAME2, buf, bytesread); } else if (! strcmp(hookname, "myhook2")) { printf("%s !\n", hookname); NgSendData(dsock, HOOKNAME, buf, bytesread); } } } Output of 'ngctl show xl0:': [root@artik ~]# ngctl show xl0: Name: xl0 Type: ether ID: 00000001 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- lower socket 00000055 myhook2 upper socket 00000055 myhook If now I try to telnet an other host on the same lan on ssh port, here there is the result of tcpdump on this another host: 16:56:06.971008 172.16.2.3.1218 > 172.16.1.1.22: S [bad tcp cksum ea9c!] 2063189250:2063189250(0) win 65535 (DF) [tos 0x10] (ttl 64, id 4078, len 44, bad cksum 0!) 0x0000 4510 002c 0fee 4000 4006 0000 ac10 0203 E..,..@.@....... 0x0010 ac10 0101 04c2 0016 7af9 c502 0000 0000 ........z....... 0x0020 6002 ffff 5b43 0000 0204 05b4 0000 `...[C........ 16:56:09.965572 172.16.2.3.1218 > 172.16.1.1.22: S [bad tcp cksum ea9c!] 2063189250:2063189250(0) win 65535 (DF) [tos 0x10] (ttl 64, id 54488, len 44, bad cksum 0!) 0x0000 4510 002c d4d8 4000 4006 0000 ac10 0203 E..,..@.@....... 0x0010 ac10 0101 04c2 0016 7af9 c502 0000 0000 ........z....... 0x0020 6002 ffff 5b43 0000 0204 05b4 0000 `...[C........ 16:56:12.964827 172.16.2.3.1218 > 172.16.1.1.22: S [bad tcp cksum ea9c!] 2063189250:2063189250(0) win 65535 (DF) [tos 0x10] (ttl 64, id 5274, len 44, bad cksum 0!) 0x0000 4510 002c 149a 4000 4006 0000 ac10 0203 E..,..@.@....... 0x0010 ac10 0101 04c2 0016 7af9 c502 0000 0000 ........z....... 0x0020 6002 ffff 5b43 0000 0204 05b4 0000 `...[C........ 16:56:15.965646 172.16.2.3.1218 > 172.16.1.1.22: S [bad tcp cksum ea9c!] 2063189250:2063189250(0) win 65535 (DF) [tos 0x10] (ttl 64, id 58146, len 44, bad cksum 0!) 0x0000 4510 002c e322 4000 4006 0000 ac10 0203 E..,."@.@....... 0x0010 ac10 0101 04c2 0016 7af9 c502 0000 0000 ........z....... 0x0020 6002 ffff 5b43 0000 0204 05b4 0000 `...[C........ 16:56:18.965003 172.16.2.3.1218 > 172.16.1.1.22: S [bad tcp cksum ea9c!] 2063189250:2063189250(0) win 65535 (DF) [tos 0x10] (ttl 64, id 25692, len 44, bad cksum 0!) 0x0000 4510 002c 645c 4000 4006 0000 ac10 0203 E..,d\@.@....... 0x0010 ac10 0101 04c2 0016 7af9 c502 0000 0000 ........z....... 0x0020 6002 ffff 5b43 0000 0204 05b4 0000 `...[C........ As you can see, the ip cksum is 0 and tcp cksum is invalid... This problem doesn't seem to appear on rl driver (I just replace xl0: with rl0: on the code) for example and packets flow normally upwards and downwards. Any ideas ? does my code work perfectly for you or not ? Thanks Sebastien. -- spe@selectbourse.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 8:37:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from cisco.com (europe.cisco.com [144.254.52.73]) by hub.freebsd.org (Postfix) with ESMTP id 7219F37B40B for ; Fri, 14 Jun 2002 08:37:36 -0700 (PDT) Received: from www.example.org (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA01976 for ; Fri, 14 Jun 2002 17:36:50 +0200 (MET DST) Received: (qmail 14083 invoked by uid 1000); 14 Jun 2002 15:36:22 -0000 Message-ID: <20020614153622.14082.qmail@cobweb.example.org> Date: Fri, 14 Jun 2002 17:36:21 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Subject: HighSpeed TCP for Large Congestion Windows X-Mailer: Sylpheed version 0.7.6 (GTK+ 1.2.10; i386-portbld-freebsd4.6) 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 Hi, anybody interested in implementing this for FreeBSD? Marco ----- Forwarded message from Internet-Drafts@ietf.org ----- From: Internet-Drafts@ietf.org To: IETF-Announce: ; Date: Fri, 14 Jun 2002 07:30:01 -0400 Subject: I-D ACTION:draft-floyd-tcp-highspeed-00.txt,.ps A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HighSpeed TCP for Large Congestion Windows Author(s) : S. Floyd Filename : draft-floyd-tcp-highspeed-00.txt,.ps Pages : 16 Date : 13-Jun-02 This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current, Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round- trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packet (or equivalently, at most one congestion event every 1 2/3 hours). We do not consider this a realistic condition. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-floyd-tcp-highspeed-00.txt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 9:50:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 22A1037B431 for ; Fri, 14 Jun 2002 09:50:14 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5EGo7f49085; Fri, 14 Jun 2002 09:50:07 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5EGo6c12182; Fri, 14 Jun 2002 09:50:06 -0700 (PDT) (envelope-from jdp) Date: Fri, 14 Jun 2002 09:50:06 -0700 (PDT) Message-Id: <200206141650.g5EGo6c12182@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: spe@selectbourse.net Subject: Re: Problem using ng_ether In-Reply-To: <20020614150130.56E86BAE9@sbserv0.intra.selectbourse.net> References: <20020614150130.56E86BAE9@sbserv0.intra.selectbourse.net> Organization: Polstra & Co., Seattle, WA 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 article <20020614150130.56E86BAE9@sbserv0.intra.selectbourse.net>, Sebastien Petit wrote: > > I've a problem with ng_ether and xl0 driver, when I connect upper <-> lower > directly, packets have ip sum to 0 and a wrong tcp and udp cksum. I try to > use my test code on rl0 driver, and it work fine. > Julian or Archie, can you say me if I must recompute ip/tcp/udp checksum for > all packets read on upper and then writed on lower hook ? I'm not Julian or Archie, but I think I know what the problem is. The xl interface supports hardware checksum offloading, while the rl interface does not. When checksum offloading is used, the NIC itself checks the checksums of received packets, and calculates the checksums of transmitted packets. When transmitting packets the TCP/IP/UDP stacks set flags in the mbuf headers which tell the interface to calculate the checksums itself, if the interface has reported that it is capable of that. In that case, the TCP/IP/UDP layers don't bother to calculate the checksums in software. If you pass the mbufs directly from the upper hook to the lower hook inside the kernel, the relevant mbuf flags are preserved, and it all works as one would hope. But since you're doing the forwarding between hooks at the application layer, the mbuf flags are lost. The TCP/IP/UDP stacks assume the NIC will calculate the checksums of transmitted packets (because it said it could). But the flags telling the NIC to do so are lost. You can confirm this if you wish, by hacking up the xl driver to disable hardware checksumming. Search for "CSUM" in sys/pci/if_xl.c and #ifdef out the appropriate pieces of code. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 10:10:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 078A337B41C for ; Fri, 14 Jun 2002 10:10:01 -0700 (PDT) Received: from isi.edu (ifoxdyy9u84lim1o@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5EH7Qr12026; Fri, 14 Jun 2002 10:07:26 -0700 (PDT) Message-ID: <3D0A22CC.4010003@isi.edu> Date: Fri, 14 Jun 2002 10:07:24 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Julian Elischer Cc: Archie Cobbs , net@FreeBSD.ORG Subject: Re: netgraph encryption? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201040104090009040106" 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 cryptographically signed message in MIME format. --------------ms070201040104090009040106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Julian Elischer wrote: > I haven't seen a problem with multicast and netgraph but > that doesn't mean there isn't a problem. Let us see if there is a > traceback. Here's one (4.5-RELEASE + security advisory patches). I can readily reproduce this crash, so I have a good setup to test things for you while tracking this down. I set up a netgraph UDP tunnel as follows: ngctl mkpeer iface dummy inet ifconfig ng0 206.117.27.2 206.117.27.3 netmask 255.255.255.128 mtu 1400 ngctl mkpeer ng0: ksocket inet inet/dgram/udp ngctl msg ng0:inet bind inet/128.9.160.108:48286 ngctl msg ng0:inet connect inet/128.9.112.2:19071 Then I start mrouted (here in debug mode, which may help you debug things: [root@keg: /usr/src/sys/compile/KERNEL-1.37] mrouted -d debug level 0x2de (pruning,routing,peers,cache,interface,membership,igmp) 09:57:11.493 mrouted version 3.9-beta3+IOS12 starting 09:57:11.493 Getting vifs from kernel interfaces 09:57:11.493 installing xl0 (128.9.160.108 on subnet 128.9.160/20) as vif #0 - rate=0 09:57:11.494 installing ng0 (206.117.27.2 on subnet 206.117.27.0/25) as vif #1 - rate=0 09:57:11.494 Getting vifs from /etc/mrouted.conf 09:57:11.494 Installing vifs in mrouted... 09:57:11.494 vif #0, phyint 128.9.160.108 09:57:11.494 assuming querier duties on vif 0 09:57:11.494 sending query on vif 0 09:57:11.495 SENT membership query from 128.9.160.108 to 224.0.0.1 09:57:11.495 SENT neighbor probe from 128.9.160.108 to 224.0.0.4 09:57:11.495 vif #1, phyint 206.117.27.2 09:57:11.495 assuming querier duties on vif 1 09:57:11.495 sending query on vif 1 09:57:11.495 SENT membership query from 206.117.27.2 to 224.0.0.1 09:57:11.496 SENT neighbor probe from 206.117.27.2 to 224.0.0.4 vifs_with_neighbors = 0 Virtual Interface Table Vif Name Local-Address M Thr Rate Flags 0 xl0 128.9.160.108 subnet: 128.9.160/20 1 1 0 querier IGMP querier: 128.9.160.108 (this system) Nbr bitmaps: 0x0000000000000000 1 ng0 206.117.27.2 subnet: 206.117.27.0/25 1 1 0 querier rexmit_prunes IGMP querier: 206.117.27.2 (this system) Nbr bitmaps: 0x0000000000000000 Multicast Routing Table (2 entries) Origin-Subnet From-Gateway Metric Tmr Fl In-Vif Out-Vifs 206.117.27.0/25 1 0 C. 1 0* 128.9.160/20 1 0 C. 0 1* 09:57:11.498 RECV membership query from 128.9.160.108 to 224.0.0.1 09:57:11.498 ignoring query from 128.9.160.108; querier on vif 0 is still me 09:57:11.498 RECV membership query from 206.117.27.2 to 224.0.0.1 09:57:11.498 ignoring query from 206.117.27.2; querier on vif 1 is still me 09:57:11.566 RECV neighbor probe from 128.9.160.194 to 224.0.0.4 09:57:11.566 checking probe from 128.9.160.194 (3.255) on vif 0 09:57:11.566 New neighbor 128.9.160.194 on vif 0 v3.255 nf 0x0e idx 0 09:57:11.566 waiting for probe from 128.9.160.194 with my addr 09:57:14.570 RECV neighbor probe from 128.9.160.72 to 224.0.0.4 09:57:14.570 checking probe from 128.9.160.72 (3.255) on vif 0 09:57:14.570 New neighbor 128.9.160.72 on vif 0 v3.255 nf 0x0f idx 1 09:57:14.570 SENT neighbor probe from 128.9.160.108 to 224.0.0.4 09:57:14.570 SENT route report from 128.9.160.108 to 224.0.0.4 09:57:14.626 RECV neighbor probe from 128.9.160.194 to 224.0.0.4 09:57:14.626 checking probe from 128.9.160.194 (3.255) on vif 0 09:57:14.627 128.9.160.194 on vif 0 exits WAITING 09:57:14.627 SENT neighbor probe from 128.9.160.108 to 224.0.0.4 09:57:14.627 SENT route report from 128.9.160.108 to 224.0.0.4 09:57:14.650 RECV route report from 128.9.160.194 to 224.0.0.4 09:57:14.651 Updating 7 routes from 128.9.160.194 to 224.0.0.4 09:57:14.651 SENT route report from 128.9.160.108 to 224.0.0.4 09:57:14.665 RECV neighbor probe from 128.9.160.72 to 224.0.0.4 09:57:14.666 checking probe from 128.9.160.72 (3.255) on vif 0 09:57:14.676 RECV route report from 128.9.160.72 to 224.0.0.4 09:57:14.676 Updating 7 routes from 128.9.160.72 to 224.0.0.4 09:57:14.687 RECV route report from 128.9.160.194 to 224.0.0.4 09:57:14.687 Updating 1 routes from 128.9.160.194 to 224.0.0.4 09:57:14.697 RECV route report from 128.9.160.72 to 224.0.0.4 09:57:14.697 Updating 1 routes from 128.9.160.72 to 224.0.0.4 09:57:16.714 aging forwarding cache entries 09:57:16.714 sending query on vif 0 09:57:16.714 SENT membership query from 128.9.160.108 to 224.0.0.1 09:57:16.714 sending query on vif 1 09:57:16.715 SENT membership query from 206.117.27.2 to 224.0.0.1 09:57:16.715 SENT neighbor probe from 128.9.160.108 to 224.0.0.4 09:57:16.715 SENT neighbor probe from 206.117.27.2 to 224.0.0.4 09:57:16.715 RECV membership query from 128.9.160.108 to 224.0.0.1 09:57:16.715 ignoring query from 128.9.160.108; querier on vif 0 is still me 09:57:16.715 RECV membership query from 206.117.27.2 to 224.0.0.1 09:57:16.715 ignoring query from 206.117.27.2; querier on vif 1 is still me 09:57:17.230 RECV V2 member report from 128.9.160.142 to 224.0.0.2 09:57:17.231 group 224.0.0.2 joined on vif 0 09:57:18.421 RECV neighbor probe from 128.9.112.65 to 224.0.0.4 09:57:18.421 warning - ignoring probe from non-neighbor 128.9.112.65, check for misconfigured tunnel or routing on 128.9.112.65 09:57:19.424 SENT route report from 128.9.160.108 to 224.0.0.4 09:57:19.425 update 9 starting at 9 of 9 09:57:21.522 RECV neighbor probe from 128.9.160.194 to 224.0.0.4 And then it crashes. Here's the panic info: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xc1be5bfc stack pointer = 0x10:0xcdfa6e00 frame pointer = 0x10:0xcdfa6e10 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 = 511 (mrouted) interrupt mask = net kernel: type 12 trap, code=0 Stopped at ng_iface_ioctl+0x7c: testb $0x1,0x10(%edi) (kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:474 #1 0xc017bcb0 in boot (howto=260) at ../../kern/kern_shutdown.c:313 #2 0xc017c0b5 in panic (fmt=0xc02f16a4 "from debugger") at ../../kern/kern_shutdown.c:582 #3 0xc013f965 in db_panic (addr=-1044489220, have_addr=0, count=1, modif=0xcdfa6c6c "") at ../../ddb/db_command.c:435 #4 0xc013f903 in db_command (last_cmdp=0xc035c938, cmd_table=0xc035c778, aux_cmd_tablep=0xc03985b8) at ../../ddb/db_command.c:333 #5 0xc013f9ca in db_command_loop () at ../../ddb/db_command.c:457 #6 0xc0141b63 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71 #7 0xc02bc38c in kdb_trap (type=12, code=0, regs=0xcdfa6dc0) at ../../i386/i386/db_interface.c:158 #8 0xc02c98ec in trap_fatal (frame=0xcdfa6dc0, eva=16) at ../../i386/i386/trap.c:951 #9 0xc02c95ad in trap_pfault (frame=0xcdfa6dc0, usermode=0, eva=16) at ../../i386/i386/trap.c:849 #10 0xc02c913f in trap (frame={tf_fs = -840368112, tf_es = -869138416, tf_ds = 16, tf_edi = 0, tf_esi = -1044495616, tf_ebp = -839225840, tf_isp = -839225876, tf_ebx = -2145359600, tf_edx = 6686720, tf_ecx = 6686720, tf_eax = 6686720, tf_trapno = 12, tf_err = 0, tf_eip = -1044489220, tf_cs = 8, tf_eflags = 66118, tf_esp = 1, tf_ss = -1044495616}) at ../../i386/i386/trap.c:448 #11 0xc1be5bfc in ?? () #12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at ../../net/if.c:1375 #13 0xc01d61c2 in add_vif (vifcp=0xcdfa6ea4) at ../../netinet/ip_mroute.c:734 #14 0xc01d5bfd in X_ip_mrouter_set (so=0xccd2a480, sopt=0xcdfa6f24) at ../../netinet/ip_mroute.c:410 #15 0xc01da70d in rip_ctloutput (so=0xccd2a480, sopt=0xcdfa6f24) at ../../netinet/raw_ip.c:378 #16 0xc019b3ee in sosetopt (so=0xccd2a480, sopt=0xcdfa6f24) at ../../kern/uipc_socket.c:1127 #17 0xc019e83f in setsockopt (p=0xcc3246c0, uap=0xcdfa6f80) at ../../kern/uipc_syscalls.c:1113 #18 0xc02c9b26 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 1, tf_ebp = -1077938012, tf_isp = -839225388, tf_ebx = 1, tf_edx = 134609892, tf_ecx = 6, tf_eax = 105, tf_trapno = 7, tf_err = 2, tf_eip = 671831280, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938088, tf_ss = 47}) at ../../i386/i386/trap.c:1157 #19 0xc02bd165 in Xint0x80_syscall () #20 0x804e584 in ?? () #21 0x804b6e5 in ?? () #22 0x8055302 in ?? () #23 0x804b5d6 in ?? () #24 0x8048fc1 in ?? () -- Lars Eggert USC Information Sciences Institute --------------ms070201040104090009040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxNDE3MDcyNlowIwYJKoZIhvcNAQkEMRYEFGSIkCP5OCpL I5ZjvC46Wwx5JvBYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYBVaKNZyFfqEHxUZ97JUWJy6+w9yqNXTBjgkDu8OEUXQ5xW 763ethUvhb4S/jyNLZFZ8CZuiX9jjY73/Suh9BNgal9VKKCGdoAO/zZR3K/Bl2o97RWL1nk8 DOb36BpLrPRHcmHp7dr8YKNVXT+7IM4/7sEn8kxLLpZlWXzgVdOAOQAAAAAAAA== --------------ms070201040104090009040106-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 10:40:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id D066F37B407 for ; Fri, 14 Jun 2002 10:40:30 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5EHe8533727; Fri, 14 Jun 2002 12:40:08 -0500 (CDT) (envelope-from jlemon) Date: Fri, 14 Jun 2002 12:40:08 -0500 (CDT) From: Jonathan Lemon Message-Id: <200206141740.g5EHe8533727@prism.flugsvamp.com> To: silby@silby.com, net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: 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 article you write: > >(I'm redirecting this back to freebsd-net, as it doesn't seem appropriate >for bugtraq.) > >I did some quick investigation last night, and agree with Phil that this >is a bug. When the syncache was implemented, only a subset of the normal >tcp output code was copied over for the purpose of sending syn-acks. One >part of the code that was not moved over was the part that determines when >the DF and tos bits are set. Actually, this is not a bug, except possibly for the TOS bits. I just reread RFC 1191, and there isn't anything in there that requires DF to always be set on a TCP connection. In fact, RFC 1191 states: Or, the host may elect to end the discovery process by ceasing to set the DF bit in the datagram headers; it may do so, for example, because it is willing to have datagrams fragmented in some circumstances. Normally, the host continues to set DF in all datagrams, so that if the route changes and the new PMTU is lower, it will be discovered. Since the maximum size(*) of the SYN,ACK packet being sent out is: sizeof(struct ip) + sizeof(struct tcphdr) + TCP_OPTIONS 20 20 4 + 4 + 12 + 8 == 68 octets And since routers /MUST/ be able to forward this packet without fragmentation, according to RFC 791 (minimum MTU), there isn't any need to set the DF bit. In fact, if a router generates a Datagram too Big message in response to this SYN,ACK then it is in error. Also, since the syncache does not have any provision to create a smaller packet, setting the DF bit will result in a denial of service if for some reason, the SYN,ACK packet actually triggers the PMTU discovery. So there's two choices: 1) set IP_DF and deny service if we trigger PMTU (and violate RFC 1191), 2) omit IP_DF and let the router fragment things if needed. The section of the commit relating to PMTU discovery should be backed out. Finally, as far as 'fingerprinting' goes, we're not the only *BSD doing this. -- Jonathan (*) Yes, this ignores any possible IP options, but the only IP options that might come into play here are source routing, which are fairly unlikely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 11:16:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d2.as3.nwbl0.wi.voyager.net [169.207.92.130]) by hub.freebsd.org (Postfix) with ESMTP id 0388137B404 for ; Fri, 14 Jun 2002 11:16:13 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5EIHRcv003161; Fri, 14 Jun 2002 13:17:27 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5EIHP7Z003158; Fri, 14 Jun 2002 13:17:26 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 14 Jun 2002 13:17:24 -0500 (CDT) From: Mike Silbersack To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? In-Reply-To: <200206141740.g5EHe8533727@prism.flugsvamp.com> Message-ID: <20020614130811.E3117-100000@patrocles.silby.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 Fri, 14 Jun 2002, Jonathan Lemon wrote: > Actually, this is not a bug, except possibly for the TOS bits. I just > reread RFC 1191, and there isn't anything in there that requires DF to > always be set on a TCP connection. In fact, RFC 1191 states: > > Or, the host may elect to end the discovery process > by ceasing to set the DF bit in the datagram headers; it may do so, > for example, because it is willing to have datagrams fragmented in > some circumstances. Normally, the host continues to set DF in all > datagrams, so that if the route changes and the new PMTU is lower, it > will be discovered. It doesn't seem to exclude the practice either. > Also, since the syncache does not have any provision to create a > smaller packet, setting the DF bit will result in a denial of service > if for some reason, the SYN,ACK packet actually triggers the PMTU > discovery. So there's two choices: > 1) set IP_DF and deny service if we trigger PMTU (and violate RFC 1191), > 2) omit IP_DF and let the router fragment things if needed. > > The section of the commit relating to PMTU discovery should be backed out. > > Finally, as far as 'fingerprinting' goes, we're not the only *BSD doing this. > -- > Jonathan I'm not sure it's a real denial of service; anyone who was behind a router that bounced all packets with the DF bits set would have a system that would be virtually useless. I can't see anyone making such a modification just for the purpose of a DoS; it would be easier to just synflood. In cases where DF packets were being bounced for whatever reason, the syn cache should recover in exactly the same method as normal packets from tcp_output would. Whether or not the recovery method works or not is unknown to me; however, I don't see why starting the discovery with the syn-ack packet (as would have been done before the syn cache) would make the situation any worse. One reason I somewhat like the DF bit present relates to the the ip_id field. I noticed that linux has moved to setting 0 in the ip_id field for all packets with DF set. This sounds like a good way to go for me, as it's a lot cheaper than some randomization scheme. However, if we don't set DF on syn-ack packets but do on others, we'd be basically making a public counter of how many connections / second the server is trying to accept. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 11:20:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by hub.freebsd.org (Postfix) with ESMTP id 7FDEE37B41E for ; Fri, 14 Jun 2002 11:20:13 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020614182012.IZRZ1547.sccrmhc02.attbi.com@InterJet.elischer.org>; Fri, 14 Jun 2002 18:20:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA00478; Fri, 14 Jun 2002 11:19:03 -0700 (PDT) Date: Fri, 14 Jun 2002 11:19:02 -0700 (PDT) From: Julian Elischer To: John Polstra Cc: net@freebsd.org, spe@selectbourse.net Subject: Re: Problem using ng_ether In-Reply-To: <200206141650.g5EGo6c12182@vashon.polstra.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 Fri, 14 Jun 2002, John Polstra wrote: > > I'm not Julian or Archie, but I think I know what the problem is. > The xl interface supports hardware checksum offloading, while the rl > interface does not. When checksum offloading is used, the NIC itself > checks the checksums of received packets, and calculates the checksums > of transmitted packets. > > When transmitting packets the TCP/IP/UDP stacks set flags in the mbuf > headers which tell the interface to calculate the checksums itself, > if the interface has reported that it is capable of that. In that > case, the TCP/IP/UDP layers don't bother to calculate the checksums > in software. If you pass the mbufs directly from the upper hook > to the lower hook inside the kernel, the relevant mbuf flags are > preserved, and it all works as one would hope. But since you're doing > the forwarding between hooks at the application layer, the mbuf flags > are lost. The TCP/IP/UDP stacks assume the NIC will calculate the > checksums of transmitted packets (because it said it could). But the > flags telling the NIC to do so are lost. I think you are 'spot on' I guess we need to figure out a way make the activation of the netgraph hooks automatically disable H/W checksumming by default. (or at least on how to codify metadata such as that so it can be passed through user space successfully) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 12:18:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by hub.freebsd.org (Postfix) with ESMTP id 01BCF37B431 for ; Fri, 14 Jun 2002 12:18:15 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g5EJHoF36825; Fri, 14 Jun 2002 14:17:50 -0500 (CDT) (envelope-from jlemon) Date: Fri, 14 Jun 2002 14:17:50 -0500 From: Jonathan Lemon To: Mike Silbersack Cc: Jonathan Lemon , net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614141750.E37376@prism.flugsvamp.com> References: <200206141740.g5EHe8533727@prism.flugsvamp.com> <20020614130811.E3117-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20020614130811.E3117-100000@patrocles.silby.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 On Fri, Jun 14, 2002 at 01:17:24PM -0500, Mike Silbersack wrote: > > On Fri, 14 Jun 2002, Jonathan Lemon wrote: > > > Actually, this is not a bug, except possibly for the TOS bits. I just > > reread RFC 1191, and there isn't anything in there that requires DF to > > always be set on a TCP connection. In fact, RFC 1191 states: > > > > Or, the host may elect to end the discovery process > > by ceasing to set the DF bit in the datagram headers; it may do so, > > for example, because it is willing to have datagrams fragmented in > > some circumstances. Normally, the host continues to set DF in all > > datagrams, so that if the route changes and the new PMTU is lower, it > > will be discovered. > > It doesn't seem to exclude the practice either. Correct. Either approach is acceptable from the RFC standpoint. However, if you set IP_DF, you /MUST/ be able to handle a PMTU response, which is not true of the current code. > > Also, since the syncache does not have any provision to create a > > smaller packet, setting the DF bit will result in a denial of service > > if for some reason, the SYN,ACK packet actually triggers the PMTU > > discovery. So there's two choices: > > 1) set IP_DF and deny service if we trigger PMTU (and violate RFC 1191), > > 2) omit IP_DF and let the router fragment things if needed. > > > > The section of the commit relating to PMTU discovery should be backed out. > > > > Finally, as far as 'fingerprinting' goes, we're not the only *BSD doing this. > > -- > > Jonathan > > I'm not sure it's a real denial of service; anyone who was behind a router > that bounced all packets with the DF bits set would have a system that > would be virtually useless. I can't see anyone making such a modification > just for the purpose of a DoS; it would be easier to just synflood. It is a DoS. Suppose that for some reason, we send out a SYN,ACK of 80 octets, which hits a router with the minimum MTU of 68 octets. Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped, and a ICMP PMTU response is sent back, but the syncache will still resend the 80 octet datagram. If IP_DF is clear, the datagram will get through. > In cases where DF packets were being bounced for whatever reason, the syn > cache should recover in exactly the same method as normal packets from > tcp_output would. Whether or not the recovery method works or not is > unknown to me; however, I don't see why starting the discovery with the > syn-ack packet (as would have been done before the syn cache) would make > the situation any worse. Because the syncache does not go through tcp_output, so the normal TCP packet sizing mechanism does not apply here. > One reason I somewhat like the DF bit present relates to the the ip_id > field. I noticed that linux has moved to setting 0 in the ip_id field for > all packets with DF set. This sounds like a good way to go for me, as > it's a lot cheaper than some randomization scheme. However, if we don't > set DF on syn-ack packets but do on others, we'd be basically making a > public counter of how many connections / second the server is trying to > accept. If we do that, the determination of whether IP_DF should be set or not would depend on the total packet size, so we'd have to calculate the ipoptlen in a similar way that tcp_output does now, which does seem decidedly overkill. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 12:32:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id F3EBE37B42B for ; Fri, 14 Jun 2002 12:32:23 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5EJWLf49849; Fri, 14 Jun 2002 12:32:21 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5EJWKZ12333; Fri, 14 Jun 2002 12:32:20 -0700 (PDT) (envelope-from jdp) Date: Fri, 14 Jun 2002 12:32:20 -0700 (PDT) Message-Id: <200206141932.g5EJWKZ12333@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: julian@elischer.org Subject: Re: Problem using ng_ether In-Reply-To: References: Organization: Polstra & Co., Seattle, WA 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 article , Julian Elischer wrote: > I guess we need to figure out a way make the activation of > the netgraph hooks automatically disable H/W checksumming by default. Hmm, it looks like Archie already did that in February, in ng_ether.c revisions 1.22 (-current) and 1.2.2.11 (-stable). Maybe the person who started this thread is using an older kernel than that. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 12:40:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d2.as3.nwbl0.wi.voyager.net [169.207.92.130]) by hub.freebsd.org (Postfix) with ESMTP id 80BB137B439 for ; Fri, 14 Jun 2002 12:39:54 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5EJfAcv003481; Fri, 14 Jun 2002 14:41:10 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5EJf8Ko003478; Fri, 14 Jun 2002 14:41:09 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 14 Jun 2002 14:41:08 -0500 (CDT) From: Mike Silbersack To: Jonathan Lemon Cc: net@freebsd.org Subject: Re: Broken PMTUD in FreeBSD? In-Reply-To: <20020614141750.E37376@prism.flugsvamp.com> Message-ID: <20020614143731.K3117-100000@patrocles.silby.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 Fri, 14 Jun 2002, Jonathan Lemon wrote: > It is a DoS. Suppose that for some reason, we send out a SYN,ACK of > 80 octets, which hits a router with the minimum MTU of 68 octets. > Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped, > and a ICMP PMTU response is sent back, but the syncache will still resend > the 80 octet datagram. If IP_DF is clear, the datagram will get through. In theory, I guess that could happen. Give me a few days to examine the PMTU code to see if there's an easy way to handle that case. If the DF bit is removed on the resend, would that be acceptable? /me has this bad feeling that he just roped himself into auditing the PTMU code. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 12:45:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id AB20B37B42C for ; Fri, 14 Jun 2002 12:45:44 -0700 (PDT) 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 MAA65840; Fri, 14 Jun 2002 12:36:52 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5EJaUS24202; Fri, 14 Jun 2002 12:36:30 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206141936.g5EJaUS24202@arch20m.dellroad.org> Subject: Re: netgraph encryption? In-Reply-To: <3D0A22CC.4010003@isi.edu> "from Lars Eggert at Jun 14, 2002 10:07:24 am" To: Lars Eggert Date: Fri, 14 Jun 2002 12:36:30 -0700 (PDT) Cc: julian@elischer.org, 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 Lars Eggert writes: > #11 0xc1be5bfc in ?? () > #12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at > ../../net/if.c:1375 Well, this is obvious by looking at it. ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument to point to a struct ifreq, yet if_allmulti() is passing NULL. It seems that ng_iface is not the only interface code that makes this assumption, e.g., see if_vlan.c, if_ppp.c, etc. What is the deal with if_allmulti() passing NULL? -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 Fri Jun 14 12:59:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 8125B37B41F for ; Fri, 14 Jun 2002 12:59:30 -0700 (PDT) Received: from isi.edu (9pc2t2trlc42pzyi@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g5EJwdr12566; Fri, 14 Jun 2002 12:58:39 -0700 (PDT) Message-ID: <3D0A4AED.4090001@isi.edu> Date: Fri, 14 Jun 2002 12:58:37 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: julian@elischer.org, freebsd-net@freebsd.org Subject: Re: netgraph encryption? References: <200206141936.g5EJaUS24202@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050609060702030403000104" 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 cryptographically signed message in MIME format. --------------ms050609060702030403000104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie Cobbs wrote: > Lars Eggert writes: > >>#11 0xc1be5bfc in ?? () >>#12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at >>../../net/if.c:1375 > > > Well, this is obvious by looking at it. > > ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument > to point to a struct ifreq, yet if_allmulti() is passing NULL. > > It seems that ng_iface is not the only interface code that makes > this assumption, e.g., see if_vlan.c, if_ppp.c, etc. > > What is the deal with if_allmulti() passing NULL? No idea, but I poked around with cvsweb, and Revision 1.85.2.17 along the RELENG_4 branch fixes this for -STABLE. I'll just add that patch locally then. Good to know this'll be fixed with 4.6! Lars -- Lars Eggert USC Information Sciences Institute --------------ms050609060702030403000104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDYxNDE5NTgzOVowIwYJKoZIhvcNAQkEMRYEFLe7iciMIN9f zdgVjCuG1rKYYsKBMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYCP0dyv1wGLqjs9Gd9EbysM0i0QPbMHIA4DkoyZCErbGMXf E1ce+fCEZPX+92VaP5/rXsoq8UA/1w6WOeknbRggIHfzYAt9XRFYxWF9zi7MuhSmrmglQnr0 n/4egVoe79JJ+Jd5p/sK359fFyAnJF4H5HTop54RzleWcZOZsB6FywAAAAAAAA== --------------ms050609060702030403000104-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 14 13:15: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 232A737B42A for ; Fri, 14 Jun 2002 13:15:04 -0700 (PDT) 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 NAA66044; Fri, 14 Jun 2002 13:08:38 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g5EK8Go24525; Fri, 14 Jun 2002 13:08:16 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200206142008.g5EK8Go24525@arch20m.dellroad.org> Subject: Re: netgraph encryption? In-Reply-To: <3D0A4AED.4090001@isi.edu> "from Lars Eggert at Jun 14, 2002 12:58:37 pm" To: Lars Eggert Date: Fri, 14 Jun 2002 13:08:16 -0700 (PDT) Cc: julian@elischer.org, 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 Lars Eggert writes: > >>#11 0xc1be5bfc in ?? () > >>#12 0xc01b622c in if_allmulti (ifp=0xc1be4300, onswitch=1) at > >>../../net/if.c:1375 > > > > ng_iface_ioctl() expects (in the case of SIOCSIFFLAGS) the third argument > > to point to a struct ifreq, yet if_allmulti() is passing NULL. > > No idea, but I poked around with cvsweb, and Revision 1.85.2.17 along > the RELENG_4 branch fixes this for -STABLE. I'll just add that patch > locally then. Good to know this'll be fixed with 4.6! The best kind of bug - one that's already been fixed :-) -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 Fri Jun 14 13:26:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id DDEE537B40C for ; Fri, 14 Jun 2002 13:26:14 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.3/8.12.3) with ESMTP id g5EKQDZa001283; Fri, 14 Jun 2002 16:26:13 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.3/8.12.3/Submit) id g5EKQDlR001282; Fri, 14 Jun 2002 16:26:13 -0400 (EDT) Date: Fri, 14 Jun 2002 16:26:12 -0400 From: Barney Wolff To: Mike Silbersack Cc: Jonathan Lemon , net@FreeBSD.ORG Subject: Re: Broken PMTUD in FreeBSD? Message-ID: <20020614162612.A1139@tp.databus.com> References: <20020614141750.E37376@prism.flugsvamp.com> <20020614143731.K3117-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020614143731.K3117-100000@patrocles.silby.com>; from silby@silby.com on Fri, Jun 14, 2002 at 02:41:08PM -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 There may be an issue with T/TCP, but otherwise I see no reason to set DF on syn-ack, even when PMTUD is on. There is simply no point to avoiding fragmentation of a single packet per connection, and it's highly unlikely anyway in today's Internet. The current behavior is perfectly acceptable to any reasonable person. On Fri, Jun 14, 2002 at 02:41:08PM -0500, Mike Silbersack wrote: > > On Fri, 14 Jun 2002, Jonathan Lemon wrote: > > > It is a DoS. Suppose that for some reason, we send out a SYN,ACK of > > 80 octets, which hits a router with the minimum MTU of 68 octets. > > Unlikely, yes, but still legal. If IP_DF is set, the packet gets dropped, > > and a ICMP PMTU response is sent back, but the syncache will still resend > > the 80 octet datagram. If IP_DF is clear, the datagram will get through. > > In theory, I guess that could happen. Give me a few days to examine the > PMTU code to see if there's an easy way to handle that case. If the DF > bit is removed on the resend, would that be acceptable? > > /me has this bad feeling that he just roped himself into auditing the PTMU > code. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 15 3:19: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mel-rto1.wanadoo.fr (smtp-out-1.wanadoo.fr [193.252.19.188]) by hub.freebsd.org (Postfix) with ESMTP id AA40D37B415 for ; Sat, 15 Jun 2002 03:18:59 -0700 (PDT) Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto1.wanadoo.fr (6.5.007) id 3D0A0BEA000468C1; Sat, 15 Jun 2002 12:18:46 +0200 Received: from SPEWIN (80.13.173.197) by mel-rta7.wanadoo.fr (6.5.007) id 3CFB1EED00779356; Sat, 15 Jun 2002 12:18:46 +0200 Message-ID: <001901c21456$3e08c3e0$010110ac@SPEWIN> From: "Sebastien Petit" To: "John Polstra" Cc: References: <200206141932.g5EJWKZ12333@vashon.polstra.com> Subject: Re: Problem using ng_ether Date: Sat, 15 Jun 2002 12:20:15 +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.2600.0000 Disposition-Notification-To: "Sebastien Petit" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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 I'm using actually FreeBSD-4.5-RELEASE-p5, This kernel doesn't have the patch ? Sebastien. -- spe@selectbourse.net > In article , > Julian Elischer wrote: > > I guess we need to figure out a way make the activation of > > the netgraph hooks automatically disable H/W checksumming by default. > > Hmm, it looks like Archie already did that in February, in ng_ether.c > revisions 1.22 (-current) and 1.2.2.11 (-stable). Maybe the person > who started this thread is using an older kernel than that. > > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > 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 Sat Jun 15 10: 9:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 91F7837B416 for ; Sat, 15 Jun 2002 10:09:51 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g5FH9ef57331; Sat, 15 Jun 2002 10:09:40 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g5FH9dN16092; Sat, 15 Jun 2002 10:09:39 -0700 (PDT) (envelope-from jdp) Date: Sat, 15 Jun 2002 10:09:39 -0700 (PDT) Message-Id: <200206151709.g5FH9dN16092@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: spe@selectbourse.net Subject: Re: Problem using ng_ether In-Reply-To: <001901c21456$3e08c3e0$010110ac@SPEWIN> References: <200206141932.g5EJWKZ12333@vashon.polstra.com> <001901c21456$3e08c3e0$010110ac@SPEWIN> Organization: Polstra & Co., Seattle, WA 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 article <001901c21456$3e08c3e0$010110ac@SPEWIN>, Sebastien Petit wrote: > I'm using actually FreeBSD-4.5-RELEASE-p5, This kernel doesn't have the > patch ? I don't know, but you can find out pretty easily. Run this command: grep if_hwassist /sys/netgraph/ng_ether.c If it produces any output, then the file contains the fix already. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 15 10:38:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from mel-rto1.wanadoo.fr (smtp-out-1.wanadoo.fr [193.252.19.188]) by hub.freebsd.org (Postfix) with ESMTP id 9B51D37B410 for ; Sat, 15 Jun 2002 10:38:38 -0700 (PDT) Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto1.wanadoo.fr (6.5.007) id 3D0A0BEA000684F7 for freebsd-net@freebsd.org; Sat, 15 Jun 2002 19:38:37 +0200 Received: from SPEWIN (80.13.173.197) by mel-rta9.wanadoo.fr (6.5.007) id 3CFB286C007C96BE for freebsd-net@freebsd.org; Sat, 15 Jun 2002 19:38:37 +0200 Message-ID: <001f01c21493$b0612620$010110ac@SPEWIN> From: "Sebastien Petit" To: Subject: Re: Problem using ng_ether Date: Sat, 15 Jun 2002 19:40:06 +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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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 Apparently, my kernel contains the fix already: [spe@artik /usr/src/sys/netgraph]$ grep "if_hwassist" ng_ether.c priv->hwassist = ifp->if_hwassist; priv->ifp->if_hwassist = 0; priv->ifp->if_hwassist = priv->hwassist; /* restore h/w csum */ So, Why I've problem with checksums ? I remember that in January, Only IP checksum was affected but now I've a problem with IP, TCP and UDP checksum. What is wrong ? Regards, Sebastien. -- spe@selectbourse.net > > I'm using actually FreeBSD-4.5-RELEASE-p5, This kernel doesn't have the > > patch ? > > I don't know, but you can find out pretty easily. Run this command: > > grep if_hwassist /sys/netgraph/ng_ether.c > > If it produces any output, then the file contains the fix already. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 15 11:56: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from excite.com (200-171-107-22.dsl.telesp.net.br [200.171.107.22]) by hub.freebsd.org (Postfix) with SMTP id E024F37B41D; Sat, 15 Jun 2002 11:55:35 -0700 (PDT) Received: from 193.82.40.218 ([193.82.40.218]) by smtp4.cyberecschange.com with esmtp; 16 Jun 0102 00:55:44 -0100 Received: from [4.208.41.118] by pet.vosni.net with NNFMP; Sat, 15 Jun 0102 23:53:04 +0800 Received: from mx.loxsystems.net ([197.134.28.166]) by mta85.snfc21.pibi.net with SMTP; 16 Jun 0102 07:50:24 -0500 Received: from unknown (60.242.216.79) by smtp013.mail.yahou.com with SMTP; Sun, 16 Jun 0102 02:47:44 -0800 Reply-To: Message-ID: <036c10c80a3a$7225b7b7$4bc60ec5@ktqqgo> From: To: Tom@aol.com Subject: I saw your email Date: Sat, 15 Jun 0102 11:46:14 +0700 MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: AOL 7.0 for Windows US sub 118 Importance: Normal 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 saw your email on a website I visited yesterday, and thought you might be interested in this. A few months back I joined a program and then...promptly forgot about it. You may have done this yourself sometime...you intend to work the program but then get caught in your day-to-day activities and it's soon forgotten. The program was free to join so maybe I just didn't take it very seriously. Anyway, near the end of March I received a letter from my sponsor (Leslynne Perry) informing me that I had more than 2000 PAID members in my downline! As you can imagine, I was very skeptical. After all, how could I have more than 2000 paid members under me in a program that I had never promoted? I took the time to check out the site...then wrote to Leslynne asking for confirmation that these were paid members and not just free sign-ups...like me :) Well, it was true...I had 2865 paid members in my downline. This in a program that I had never worked! All I had to do was upgrade to a paid membership before the end of the month and I would have my position locked in and a downline of 2865 people. You can bet I wasted no time in getting my membership upgraded! I can tell you, if I had known what was happening with this program, I would have become an active paid member months ago! With this program, you will get a HUGE downline of PAID MEMBERS. My sponsor's check, which is a minimum of $5,000, arrives every month...on time. How would you like to lock your position in FREE while you check out this opportunity and watch your downline grow? You can join FREE: To sign up simply reply to: rdecos@excite.com Type in Subject: Send My FREE Membership (required) Type in Letter: Your First and Last Name (required) Your Email Address (if different from above) We will confirm your position and send you a special report as soon as possible, and also Your Free Member Number. I'll get you entered and let you know how you can keep track of your growing downline. That's all there's to it. I'll then send you info, and you can make up your own mind. Warm regards, Dennis DeCos P.S. After having several negative experiences with network marketing companies I had pretty much given up on them. This company is different--it offers value, integrity, and a REAL opportunity to have your own home-based business... and finally make real money on the internet. Don't pass this up..you can sign up and test-drive the program for FREE. All you need to do is get your free membership. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This is a one time Email to you. You WILL NOT get another email. 0758kMwk8-776lyVl15 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 15 19:53:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from daemon.kr.FreeBSD.org (daemon.kr.freebsd.org [211.176.62.31]) by hub.freebsd.org (Postfix) with ESMTP id 45C8A37B403 for ; Sat, 15 Jun 2002 19:53:47 -0700 (PDT) Received: from gradius.wdb.co.kr (daemon [211.176.62.31]) by daemon.kr.FreeBSD.org (Postfix) with ESMTP id 45A518F625 for ; Sun, 16 Jun 2002 11:53:45 +0900 (KST) Received: from localhost (localhost [127.0.0.1]) by gradius.wdb.co.kr (8.12.3/8.12.3) with ESMTP id g5G2rgii015998 for ; Sun, 16 Jun 2002 11:53:43 +0900 (KST) (envelope-from cjh@kr.FreeBSD.org) Date: Sun, 16 Jun 2002 11:53:42 +0900 (KST) Message-Id: <20020616.115342.74737454.cjh@kr.FreeBSD.org> To: freebsd-net@freebsd.org Subject: em0 watchdog timeout in 4.6R From: CHOI Junho Organization: Korea FreeBSD Users Gruop X-URL: http://www.kr.FreeBSD.org/~cjh X-Mailer: Mew version 3.0.55 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 Hi, I am maintaining a large-volume HTTP server. It is with one em0 gigabit NIC, and running apache(or thttpd) for users to download relatively big(>200k) files. I started this service using 4.5R. It shows about 500Mbit/sec performance(the server is Pentium III 1G, 1G RAM, 36G SCSI HDD). Server load was very high(>200) but I heard it's characteristic of apache server and I decided to upgrade to recent system and use thttpd instead of apache. 2 days ago I updated the system to 4.6-RELEASE. Whether or not using apache or thttpd, under some traffic(about >150Mbit/sec), it shows "watchdog timeout" repeatedly: Jun 16 11:36:18 gigatest /kernel: em0: Link is Down Jun 16 11:36:18 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:40:49 gigatest /kernel: em0: watchdog timeout -- resetting Jun 16 11:40:51 gigatest /kernel: em0: Link is Down Jun 16 11:40:51 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:40:51 gigatest /kernel: em0: Link is Down Jun 16 11:40:51 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:44:23 gigatest /kernel: em0: watchdog timeout -- resetting Jun 16 11:44:24 gigatest /kernel: em0: Link is Down Jun 16 11:44:24 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:50:28 gigatest /kernel: em0: watchdog timeout -- resetting Jun 16 11:50:29 gigatest /kernel: em0: Link is Down Jun 16 11:50:29 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:50:30 gigatest /kernel: em0: Link is Down Jun 16 11:50:30 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex Jun 16 11:50:30 gigatest /kernel: em0: Link is Down Jun 16 11:50:30 gigatest /kernel: em0: Link is up 1000 Mbps FullDuplex Jun 16 11:50:30 gigatest /kernel: em0: Link is Down Jun 16 11:50:30 gigatest /kernel: em0: Link is up 1000 Mbps Full Duplex I updated em0 driver to 1.3.8 from Intel webpage, but it no helps. Can you suggest some advice? If not, I have to back to 4.5R-p5. -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [sleeping now] [while sleeping] Korea FreeBSD Users Group Web Data Bank To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message