From owner-freebsd-net Sun Feb 28 16:18:37 1999 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (unknown [194.77.0.18]) by hub.freebsd.org (Postfix) with ESMTP id A3C891537A for ; Sun, 28 Feb 1999 16:18:24 -0800 (PST) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.8.6/8.8.6) with ESMTP id BAA22564 for ; Mon, 1 Mar 1999 01:18:05 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.9.2/8.9.2) id BAA26727 for freebsd-net@FreeBSD.ORG; Mon, 1 Mar 1999 01:17:53 +0100 (CET) (envelope-from andreas) Date: Mon, 1 Mar 1999 01:17:53 +0100 From: Andreas Klemm To: freebsd-net@FreeBSD.ORG Subject: kame, wfq and i4b Message-ID: <19990301011753.A26474@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.1-STABLE SMP Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! I'd like to have something like wfq for my dialup to internet using i4b. Do you think weighted fair queuing would work also for i4b ? Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 28 18: 0:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 67921150D2 for ; Sun, 28 Feb 1999 18:00:42 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA27160; Sat, 27 Feb 1999 10:16:23 +0100 From: Luigi Rizzo Message-Id: <199902270916.KAA27160@labinfo.iet.unipi.it> Subject: bug with "de" driver and multicast routing in 3.x and above To: net@FreeBSD.org Date: Sat, 27 Feb 1999 10:16:22 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2202 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think i found a subtle problems in running multicast routers on 3.0 and above with the "de" driver. After a few hints from Bill Fenner, it took me a few hours to track this problem, so i think it is good to tell people what is happening. The thing is, multicast routers request interface to receive all multicast pkts. In 3.x this is done calling the chain add_vif() --> if_allmulti() --> ioctl( ... SIOCSIFFLAGS ...) which results in IFF_ALLMULTI being set and a call to the driver to do the right thing. The "de" driver fails to handle this properly in two places: * in the ioctl handler for SIOCSIFFLAGS, because it does not update the internal flag TULIP_ALLMULTI. I think a way to achieve this is adding a call to tulip_addr_filter() * in tulip_addr_filter(), because the first thing it does is to reset IFF_ALLMULTI (ouch!) thus losing the info it needs. The bug seems to be present also in the latest version of the de driver from Matt Thomas (v981011) in our tree. A fix (attached) is very short. I will commit it as soon as we have IP connectivity again (which should hopefully happen by the time you can read this email). Surprises with the de driver are not over. I still see (on 3.1) that frequently the interface goes down and never comes up by itself, requesting manual ifconfig down/ifconfig up... Have not had the time to investigate this behaviour though. cheers luigi su-2.02# diff -ubwr /tmp/if_de.c /sys/pci/if_de.c --- /tmp/if_de.c Sat Feb 27 12:17:01 1999 +++ /sys/pci/if_de.c Sat Feb 27 12:17:43 1999 @@ -3086,7 +3086,8 @@ sc->tulip_cmdmode &= ~TULIP_CMD_RXRUN; sc->tulip_intrmask &= ~TULIP_STS_RXSTOPPED; #if defined(IFF_ALLMULTI) - sc->tulip_if.if_flags &= ~IFF_ALLMULTI; + if (sc->tulip_if.if_flags & IFF_ALLMULTI) + sc->tulip_flags |= TULIP_ALLMULTI ; #endif #if defined(__FreeBSD__) && __FreeBSD_version >= 300000 @@ -4755,6 +4756,7 @@ printf(TULIP_PRINTF_FMT ": ignored invalid media request\n", TULIP_PRINTF_ARGS); } #endif + tulip_addr_filter(sc); /* XXX lr reset multicast filtering */ tulip_init(sc); break; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 1 1: 2:37 1999 Delivered-To: freebsd-net@freebsd.org Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by hub.freebsd.org (Postfix) with ESMTP id B1FE21529E for ; Mon, 1 Mar 1999 01:01:48 -0800 (PST) (envelope-from graeme.brown@bt-sys.bt.co.uk) Received: from rambo (actually rambo.futures.bt.co.uk) by arthur (local) with SMTP; Mon, 1 Mar 1999 09:01:10 +0000 Received: from maczebedee (actually macsmtp) by rambo with SMTP (PP); Mon, 1 Mar 1999 09:05:27 +0000 Message-ID: Date: 1 Mar 1999 09:05:29 +0100 From: Graeme Brown Subject: FW: Troubles with BSDATM and PVCs To: "FreeBSD-Net (FreeBSD.Org) List" X-Mailer: Mail*Link SMTP for Quarterdeck Mail; Version 4.0.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks I know that some of us have had troubles with Efficient Networks Inc ATM cards appearing to fail under FreeBSD and the ALTQ package. This has plagued myself, Gordana and Antonio to my knowledge. I have learnt (see below) that there is a bug in the atm card driver. I recently returned eight atm cards (failures suspected by myself, Gordana and Antonio) to ENI in the States and they tested them and found them all to be OK ! The patch to fix this is given by Panos Gevros of UCL below. However Panos claimed it is fixed in altq-1.1.3 but Kenjiro Cho (ALTQ author) admitted that the bug has crept into altq-1.1.3. Anyway to use the patch i) save it in a file say /midway.patch where is a directory of your choice. ii) go through the step to apply the sys-altq.patch in the procedure of building the ALTQ kernel as given in ALTQ install instructions. iii) next cd /usr/src/sys-altq/dev/en patch -p < /midway.patch iv) compile the ALTQ kernel as per usual. Hope this helps Graeme _______________________________________________________________________________ To: Graeme Brown Cc: P.Gevros@cs.ucl.ac.uk From: Panos GEVROS on Thu, Feb 25, 1999 4:42 pm Subject: Re: Troubles with BSDATM and PVCs Graeme, there is a bug in the ATM driver which causes interfaces to freeze occasionally we used to have this problem and talked to Kenjiro, it is fixed in altq-1.1.3 Panos ---------------------------------------------------------------------- --- midway.c- Wed Oct 7 20:54:18 1998 +++ midway.c Thu Oct 8 12:24:34 1998 @@ -2237,7 +2237,11 @@ goto dequeue_drop; } - if (launch.need > sc->txslot[chan].bfree) { + /* + * note: don't use the entire buffer space. if WRTX becomes equal + * to RDTX, the transmitter stops assuming the buffer is empty! --kjc + */ + if (launch.need >= sc->txslot[chan].bfree) { EN_COUNT(sc->txoutspace); #ifdef EN_DEBUG printf("%s: tx%d: out of transmit space\n", sc->sc_dev.dv_xname, chan); ---------------------------------------------------------------------- | |Over a time (say a few days) I find that typicaly one of the pvcsif |becomes unserviceable, I cannot ping A->B or B->A from either |end of the pvc. ping reports 100 % packet loss. | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 1 9:42: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from picalon.gun.de (picalon.gun.de [194.77.0.18]) by hub.freebsd.org (Postfix) with ESMTP id E8102153BF for ; Mon, 1 Mar 1999 09:41:59 -0800 (PST) (envelope-from andreas@klemm.gtn.com) Received: from klemm.gtn.com (pppak04.gtn.com [194.231.123.169]) by picalon.gun.de (8.8.6/8.8.6) with ESMTP id SAA01980; Mon, 1 Mar 1999 18:36:39 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.9.2/8.9.2) id SAA08635; Mon, 1 Mar 1999 18:36:27 +0100 (CET) (envelope-from andreas) Date: Mon, 1 Mar 1999 18:36:27 +0100 From: Andreas Klemm To: freebsd-net@FreeBSD.ORG Cc: Ustimenko Semen Subject: 2.2.8-STABLE: tx driver and HP Kayak XA.... Message-ID: <19990301183627.A8329@titan.klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.1-STABLE SMP Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi ! At work on my HP Kayak XA Workstation (450 MHz PII) all PCI cards share the same interrupt, this causes slowness, only 46 KByte/sec. throughput, although being configured as 100 MBit full duplex on a Cisco Catalyst 5509 switch with IOS 4.4(1). The BIOS lets me enable PnP capable operating system and I can manually enable the bus master dma bit for every PCI slot. When I do both (enabling PnP OS and the DMA bit) the AHA2940 and the ELSA PCI Graphic cards get different interrupts (hurray) only the network card now doesn't get any irq :-( I read in the sources, that the tx driver doesn't have DMA support. Might it be the case (the only idea I got over the weekend), that I have to disable the busmaster DMA bit in the BIOS for the PCI slot where the SMC network card is installed into ?! Is there perhaps something other wrong with the tx driver or is it the BIOS of the HP Kayak from which I already heard bad things. What do you think. Andreas /// -- Andreas Klemm http://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 1 16:56:38 1999 Delivered-To: freebsd-net@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 5B64314BFD; Mon, 1 Mar 1999 16:56:35 -0800 (PST) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id SAA07580; Mon, 1 Mar 1999 18:56:18 -0600 (CST) Message-ID: <19990301185618.A7558@Denninger.Net> Date: Mon, 1 Mar 1999 18:56:18 -0600 From: Karl Denninger To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: NAT and related stuff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks, Well, its my first forey into NAT and the fun that comes with it. Some questions.... I want to do the following: 1. Have a small "external" network connected via ISDN to the world - say, two usable addresses (the router and the FreeBSD box). 2. Have an unlimited number of internal machines connected to the "inside network", with their addresses served (most of them anyway) by DHCP. 3. Have a couple of internal machines that have "exposed" things - that is, for example, 192.168.1.1:80 really shows up as 205.164.6.10:2222. 4. Anyone on an internal machine can browse the net, etc - transparently. I can run DNS on the local FreeBSD machine (and do currently), so that part is not a problem. What do I need to set up in order to do this? -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 2 5: 2:19 1999 Delivered-To: freebsd-net@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id B6A5814C36 for ; Tue, 2 Mar 1999 04:57:16 -0800 (PST) (envelope-from semen@iclub.nsu.ru) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.9.2/8.8.5) with ESMTP id SAA47585; Tue, 2 Mar 1999 18:55:19 +0600 (NS) Date: Tue, 2 Mar 1999 18:55:17 +0600 (NS) From: Ustimenko Semen To: Andreas Klemm Cc: freebsd-net@FreeBSD.ORG Subject: Re: 2.2.8-STABLE: tx driver and HP Kayak XA.... In-Reply-To: <19990301183627.A8329@titan.klemm.gtn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! On Mon, 1 Mar 1999, Andreas Klemm wrote: > Hi ! > > At work on my HP Kayak XA Workstation (450 MHz PII) all PCI cards > share the same interrupt, this causes slowness, only 46 KByte/sec. > throughput, although being configured as 100 MBit full duplex on a > Cisco Catalyst 5509 switch with IOS 4.4(1). > > The BIOS lets me enable PnP capable operating system and I can manually > enable the bus master dma bit for every PCI slot. > > When I do both (enabling PnP OS and the DMA bit) the AHA2940 and the > ELSA PCI Graphic cards get different interrupts (hurray) only the > network card now doesn't get any irq :-( > > I read in the sources, that the tx driver doesn't have DMA support. > Might it be the case (the only idea I got over the weekend), that I > have to disable the busmaster DMA bit in the BIOS for the PCI slot > where the SMC network card is installed into ?! > It use DMA a lot. I meant that there are troubles to make card busmaster. (I don't know much about this, but AFAIK they need to turn some bit in EEPROM and hard reset card to enable it use busmaster. [Some where from EPIC's pdf]) I don't know what is defaults :-( > Is there perhaps something other wrong with the tx driver or > is it the BIOS of the HP Kayak from which I already heard > bad things. What do you think. > Possibly we can softly reconfigure card to use another IRQ level... But doen't are IRQs given during PCI bus initialization. All deal with interrupts in driver is to call pci intr map function; all other drivers do the same. So i think this is question to some PCI guru. Good luck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 1:38: 8 1999 Delivered-To: freebsd-net@freebsd.org Received: from ns11.nokia.com (ns11.nokia.com [131.228.6.230]) by hub.freebsd.org (Postfix) with ESMTP id 093F214BE7 for ; Wed, 3 Mar 1999 01:38:05 -0800 (PST) (envelope-from yu.shi@research.nokia.com) Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns11.nokia.com (8.8.8/8.6.9) with ESMTP id LAA17170; Wed, 3 Mar 1999 11:34:25 +0200 (EET) Received: from pupu.research.nokia.com (pupu.research.nokia.com [131.228.13.130]) by pepper.research.nokia.com (8.9.1a/8.9.1) with ESMTP id LAA20341; Wed, 3 Mar 1999 11:34:23 +0200 (EET) Received: from research.nokia.com ([172.28.31.90]) by pupu.research.nokia.com (8.9.1a/8.9.1) with ESMTP id LAA07455; Wed, 3 Mar 1999 11:31:48 +0200 (EET) Message-ID: <36DD0289.7B2BC067@research.nokia.com> Date: Wed, 03 Mar 1999 17:36:09 +0800 From: Shi Yu Reply-To: yu.shi@research.nokia.com Organization: Nokia China X-Mailer: Mozilla 4.02 [en] (Win95; I) MIME-Version: 1.0 To: EXT Chris Williams Cc: freebsd-net@FreeBSD.ORG Subject: Re: TCP packet sizes and window w/X through SSH References: <36CDC4E7.CC332C19@geekspace.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For question1, I think it is up to the application to increase the receive and send buffer size by using function 'setsockopt'. For question2, small packets may be generated by writing a small mount of bytes to socket and disabling Nagle algorithm. EXT Chris Williams wrote: > 1) During peak data transmission between the two unix boxes, both sides > frequently hit the maximum window size before getting an ACK, and then > have to wait for the ACK to send more. Since there are no > retransmissions occuring (woo!), it would seem that an increase in > window size should boost performance. Is there any reasonable way to do > this in FreeBSD? I looked through sysctl -a and didn't see anything, > 'man tcp' isn't helpful...Is it an option I have to set before compling > the kernel? Or what? > > 2) The SSH packets going from the BSD box to the proxy server are almost > always less than ~800 bytes. This seems strange since the Ethernet MTU > is 1500, and most of the packets coming from the Sun box to the BSD box > to be relayed through SSH are in fact ~1500 bytes. Why is SSH chopping > the packets up like this? Is there a good reason for it, and if not, how > can it be fixed/changed? > Although this doesn't appear to be slowing things down as much as (1), > it does put extra load on our proxy (from watching perfmon against the > proxy while I do varios things, it is very clear that cpu/io load is > much more closely coupled with packets/sec than bytes/sec -- which isn't > at all surprising). > > Any suggestions on either point would be much appreciated.. > > 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 Mar 3 3:48:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from widefw.csl.sony.co.jp (widefw.csl.sony.co.jp [133.138.1.1]) by hub.freebsd.org (Postfix) with ESMTP id 1BAF315096 for ; Wed, 3 Mar 1999 03:48:25 -0800 (PST) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (root@hotaka.csl.sony.co.jp [43.27.98.57]) by widefw.csl.sony.co.jp (8.8.8/3.6W) with ESMTP id UAA20347 for ; Wed, 3 Mar 1999 20:48:08 +0900 (JST) Received: from localhost (kjc@[127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.8/3.6W/hotaka/98122515) with ESMTP id UAA09478 for ; Wed, 3 Mar 1999 20:48:07 +0900 (JST) Message-Id: <199903031148.UAA09478@hotaka.csl.sony.co.jp> To: freebsd-net@FreeBSD.org Subject: ALTQ for FreeBSD-3.1 Date: Wed, 03 Mar 1999 20:48:06 +0900 From: Kenjiro Cho Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For those who are interested in ALTQ for FreeBSD-3.1, the kernel patch is available from http://www.csl.sony.co.jp/person/kjc/software.html (it is just a kernel part patch to use altq-1.1.3 on FreeBSD-3.1) It is supposed to be used in place of FreeBSD-3.0.diff in update-kit-1.1.3. --Kenjiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 3:55:24 1999 Delivered-To: freebsd-net@freebsd.org Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (Postfix) with ESMTP id 67B5214E0E for ; Wed, 3 Mar 1999 03:54:43 -0800 (PST) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.12 #1) id 10IAEX-000EmB-00 for freebsd-net@freebsd.org; Wed, 3 Mar 1999 17:54:37 +0600 Date: Wed, 3 Mar 1999 17:54:37 +0600 (ALMT) From: Boris Popov To: freebsd-net@freebsd.org Subject: NetWare client 1.3beta3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Well, a next beta, here is citate from HISTORY: ---------- 03.03.1999 1.3beta3: Fixed mbuf's leak caused by slow server/networks, Code for BIO layer finally merged, paged IO should work much more correctly. Install directory for mount_nwfs program changed from /usr/local/bin to /sbin. Library and .h files not installed by default. New config file keywords added. See examples/dot.nwfsrc for details. Since I'm upgrade all machines to ELF kernels, LKMs are not longer thoroughly tested. --------- This version is much more stable than previous. Please, do not ask me about problems with 1.2betaX, just upgrade. URL: ftp://ftp.butya.kz/pub/nwlib/ncplib-1.3b3.tar.gz P.S. If someone have ability to do heavy testing on -current, please tell me about any troubles. P.P.S. Does anybody run it with NetWare 5 ? -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 4: 2: 9 1999 Delivered-To: freebsd-net@freebsd.org Received: from pelican.sms.fi (pelican.sms.fi [192.58.51.9]) by hub.freebsd.org (Postfix) with ESMTP id 11C3914F09 for ; Wed, 3 Mar 1999 04:00:45 -0800 (PST) (envelope-from pete@sms.fi) Received: from sms.fi (thrush.sms.fi [192.58.51.24]) by pelican.sms.fi (8.9.2/8.9.2) with ESMTP id OAA23508 for ; Wed, 3 Mar 1999 14:00:28 +0200 (EET) (envelope-from pete@sms.fi) Message-ID: <36DD243B.AFE9935B@sms.fi> Date: Wed, 03 Mar 1999 13:59:55 +0200 From: Petri Helenius X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a planned schedule for IPv6 and IPsec integration for 4.0-CURRENT? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 5:14:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id E3EB614F52 for ; Wed, 3 Mar 1999 05:13:28 -0800 (PST) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id KAA15975 for ; Wed, 3 Mar 1999 10:13:10 -0300 (EST) Date: Wed, 3 Mar 1999 10:13:10 -0300 (EST) From: Paulo Fragoso To: freebsd-net@freebsd.org Subject: Problems with Trumpet Winsock Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm having problems with my dialin server, after upgrade from 2.2.6-STABLE to 3.1-RELEASE. My users with Win95, Apple, Linux, FBSD are ok, but with 3.xx using trumpet don't work. With trumpet winsock I receive this mesage: ppp17: missing UI (0x3), got 0x21 in /usr/include/net/ppp_defs.h there are: #define PPP_UI 0x03 /* Unnumbered Information */ Why trumpet winsock missing UI? (got 0x21 instead 0x3) Are there any solution to do work trumpet conection? Please Help me!!!!!!!! Paulo Fragoso. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 13: 3:17 1999 Delivered-To: freebsd-net@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 4912614E70 for ; Wed, 3 Mar 1999 13:02:35 -0800 (PST) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id SAA01725 for ; Wed, 3 Mar 1999 18:02:13 -0300 (EST) Date: Wed, 3 Mar 1999 18:02:13 -0300 (EST) From: Paulo Fragoso To: freebsd-net@freebsd.org Subject: Problems with Trumpet Winsock Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excuse-me, I forgot talking about using: Dial-in server with 3.1-RELEASE I'm using pppd: #!/bin/sh /usr/bin/mesg n exec /usr/sbin/pppd idle 1200 -detach debug modem crtscts netmask 255.255.255.192 exit And some users are using Trumpet 2.0B. Are there any changes in ppp protocol (used by pppd) form FreeBSD-2.2.6 to FreeBSD-3.1-RELEASE? Why with Win95 dial-up it works fine but with Win3.XX and Trumpet it doesn't work? Can anyone help me? Paulo Fragoso. >I'm having problems with my dialin server, after upgrade from >2.2.6-STABLE to 3.1-RELEASE. My users with Win95, Apple, Linux, FBSD are >ok, but with 3.xx using trumpet don't work. > >With trumpet winsock I receive this mesage: > >ppp17: missing UI (0x3), got 0x21 > >in /usr/include/net/ppp_defs.h there are: > >#define PPP_UI 0x03 /* Unnumbered Information */ > >Why trumpet winsock missing UI? (got 0x21 instead 0x3) Are there any >solution to do work trumpet conection? > >Please Help me!!!!!!!! >Paulo Fragoso. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 19: 8:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id A09EE15065 for ; Wed, 3 Mar 1999 19:08:18 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id EAA23286 for freebsd-net@FreeBSD.ORG; Thu, 4 Mar 1999 04:07:56 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id C2C0D883B; Thu, 4 Mar 1999 00:45:12 +0100 (CET) Date: Thu, 4 Mar 1999 00:45:12 +0100 From: Ollivier Robert To: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 Message-ID: <19990304004512.B13523@keltia.freenix.fr> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <36DD243B.AFE9935B@sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <36DD243B.AFE9935B@sms.fi>; from Petri Helenius on Wed, Mar 03, 1999 at 01:59:55PM +0200 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5098 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Petri Helenius: > Is there a planned schedule for IPv6 and IPsec integration for > 4.0-CURRENT? Not much can't be done till the Unified IPv6 Stack is released. Last time I saw Jun Ishiro & Francis Dupont, they were discussing about which part of their respective stacks (and NRL) to incorporate. Don't expect anything before June/July according to Jun Ishiro. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 3 23:22:33 1999 Delivered-To: freebsd-net@freebsd.org Received: from SIMULTAN.CH (eunet-gw.simultan.ch [194.191.191.82]) by hub.freebsd.org (Postfix) with ESMTP id 48ECF14D16 for ; Wed, 3 Mar 1999 23:22:30 -0800 (PST) (envelope-from tseidmann@simultan.ch) Received: from simultan.ch (wsaltis-053.SIMULTAN.CH [192.92.128.53]) by SIMULTAN.CH (8.9.2/8.9.1) with ESMTP id IAA34176; Thu, 4 Mar 1999 08:22:06 +0100 (CET) Message-ID: <36DE346A.1457377A@simultan.ch> Date: Thu, 04 Mar 1999 08:21:14 +0100 From: Thomas Seidmann X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Karl Denninger Cc: freebsd-net@freebsd.org Subject: Re: NAT and related stuff References: <19990301185618.A7558@Denninger.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Karl, Karl Denninger wrote: > 1. Have a small "external" network connected via ISDN to the world - > say, two usable addresses (the router and the FreeBSD box). If your question is whether the use of NAT is appropriate for this situation, then the answer is yes. > 2. Have an unlimited number of internal machines connected to > the "inside network", with their addresses served (most of them > anyway) by DHCP. Same as above. > 3. Have a couple of internal machines that have "exposed" things - that > is, for example, 192.168.1.1:80 really shows up as > 205.164.6.10:2222. The "redirect_address"-feature, aka static NAT is suitable for this. More in natd(8). > 4. Anyone on an internal machine can browse the net, etc - > transparently. I can run DNS on the local FreeBSD machine (and do > currently), so that part is not a problem. Ditto. I don't quite understand your question, i.e. what do you want to know. Let me know if I can help you further. Regards, Thomas -- ========================================================== Thomas Seidmann Senior IT systems architect Simultan AG, CH-6246 Altishofen, Switzerland mailto:tseidmann@simultan.ch tel +41.62.7489000 http://www.simultan.ch/~thomas fax +41.62.7489010 ========================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 4 6: 2: 2 1999 Delivered-To: freebsd-net@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 641D214F0F for ; Thu, 4 Mar 1999 06:01:50 -0800 (PST) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id LAA24781 for ; Thu, 4 Mar 1999 11:01:32 -0300 (EST) Date: Thu, 4 Mar 1999 11:01:31 -0300 (EST) From: Paulo Fragoso To: freebsd-net@freebsd.org Subject: PPPD problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, What does PPP_UI in /usr/include/net/ppp_defs.h mean? Its value is 0x03. Can I modify this? I'm having problems with ppp connections by trumpet. It's always receiving 0x21 instead 0x03. ppp_defs.h is the same in 2.2.6-Stable and 3.1-RELEASE. Why in 2.2.6-Stable trumpet connections works fine but 3.1-RELEASE it doesn't work? Thanks, Paulo. ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 4 6:17:15 1999 Delivered-To: freebsd-net@freebsd.org Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.249.195.3]) by hub.freebsd.org (Postfix) with ESMTP id 9659D14CFE for ; Thu, 4 Mar 1999 06:17:10 -0800 (PST) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.9.3/8.9.1) with SMTP id LAA25469 for ; Thu, 4 Mar 1999 11:16:48 -0300 (EST) Date: Thu, 4 Mar 1999 11:16:48 -0300 (EST) From: Paulo Fragoso To: freebsd-net@FreeBSD.ORG Subject: Re: PPPD problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm was really using ppp-2.2 not ppp-2.3.5 under 2.2.6-STABLE. The question is: What chanched in ppp-2.3.5 that affects trumpet connection? Paulo. On Thu, 4 Mar 1999, Paulo Fragoso wrote: > Hi, > > What does PPP_UI in /usr/include/net/ppp_defs.h mean? Its value is 0x03. > Can I modify this? I'm having problems with ppp connections by trumpet. > It's always receiving 0x21 instead 0x03. > > ppp_defs.h is the same in 2.2.6-Stable and 3.1-RELEASE. Why in > 2.2.6-Stable trumpet connections works fine but 3.1-RELEASE it doesn't > work? > > Thanks, > Paulo. > > ------ > " ... Overall we've found FreeBSD to excel in performace, stability, > technical support, and of course price. Two years after discovering > FreeBSD, we have yet to find a reason why we switch to anything else" > -David Filo, Yahoo! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ------ " ... Overall we've found FreeBSD to excel in performace, stability, technical support, and of course price. Two years after discovering FreeBSD, we have yet to find a reason why we switch to anything else" -David Filo, Yahoo! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 4 6:50: 6 1999 Delivered-To: freebsd-net@freebsd.org Received: from bayer2.bayer-ag.de (bayer2.bayer-ag.de [194.120.191.2]) by hub.freebsd.org (Postfix) with SMTP id E19B214CFE for ; Thu, 4 Mar 1999 06:49:59 -0800 (PST) (envelope-from ANDREAS.KLEMM.AK@bayer-ag.de) Received: by bayer2.bayer-ag.de id PAA19202 (SMTP Gateway 3.0 for freebsd-net@freebsd.org); Thu, 4 Mar 1999 15:49:41 +0100 Received: by bayer2.bayer-ag.de (Internal Mail Agent-2); Thu, 4 Mar 1999 15:49:41 +0100 Received: by bayer2.bayer-ag.de (Internal Mail Agent-1); Thu, 4 Mar 1999 15:49:41 +0100 From: ANDREAS.KLEMM.AK@bayer-ag.de To: " - (052)Semen(a)iclub.nsu.ru" Cc: " - (052)freebsd-net(a)FreeBSD.ORG" Subject: fbsd 228: my problems with tx driver (Rx error status) Message-Id: <0006800009224752000002L022*@MHS> Date: Thu, 4 Mar 1999 15:49:28 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org =0AHi ! After enabling debugging, I thought I get a slow, but stable connectivi= ty, but actually we still have sessions terminating .... My collegue lost 2 hou= rs of script programming, well, we know "shit happens" ;-) Here the two boot messages, look, when I enable debugging in the driver= , PHY will be recognized, otherwise not. But although PHY has been detected, we have tons of CRC errors and such= . Mar 4 12:04:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 12:04:59 byz959 /kernel: tx0: CRC/Alignment error This occurs if we have a high network traffic (when making sessions up = to about 300 router in parallel)..... Solutions / ideas ?!?! Andreas /// Mar 3 17:42:13 byz959 /kernel.old: FreeBSD 2.2.8-STABLE #0: Wed Mar 3= 16:02:24 CET 1999 Mar 3 17:42:13 byz959 /kernel.old: root@byz959.bayer-ag.com:/usr/src/sys/compile/BAYER Mar 3 17:42:13 byz959 /kernel.old: CPU: Pentium II (quarter-micron) (448.88-MHz 686-class CPU) Mar 3 17:42:13 byz959 /kernel.old: Origin =3D "GenuineIntel" Id =3D 0= x652 Stepping=3D2 Mar 3 17:42:13 byz959 /kernel.old: Features=3D0x183f9ff,,MMX,> Mar 3 17:42:13 byz959 /kernel.old: real memory =3D 134217728 (131072K= bytes) Mar 3 17:42:13 byz959 /kernel.old: avail memory =3D 129433600 (126400K= bytes) Mar 3 17:42:13 byz959 /kernel.old: Probing for devices on PCI bus 0: Mar 3 17:42:13 byz959 /kernel.old: chip0 rev 2 on pci0:0:0 Mar 3 17:42:13 byz959 /kernel.old: chip1 rev 2 on pci0:1:0 Mar 3 17:42:13 byz959 /kernel.old: chip2 rev 2 on pci0:7:0 Mar 3 17:42:13 byz959 /kernel.old: chip3 = rev 1 on pci0:7:1 Mar 3 17:42:13 byz959 /kernel.old: chip4 = rev 1 int d irq 11 on pci0:7:2 Mar 3 17:42:13 byz959 /kernel.old: chip5 rev 2 on pci0:7:3 Mar 3 17:42:13 byz959 /kernel.old: tx0 rev 6 int a Mar 3 17:42:13 byz959 /kernel.old: irq 10 on pci0:16:0 Mar 3 17:42:13 byz959 /kernel.old: tx0: WARNING! PHY unknown (0xc00): = address 00:e0:29:25:57:9d, type SMC9432TX, 10Mbps ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This happens when debugging in the drivers is not enabled...... PHY isn*%t recognized .... ?! Mar 3 17:42:13 byz959 /kernel.old: ahc0 rev 0 int a irq 7 on pci0:19:0 Mar 3 17:42:13 byz959 /kernel.old: ahc0: aic7880 Wide Channel, SCSI Id= =3D7, 16/255 SCBs Mar 3 17:42:13 byz959 /kernel.old: ahc0 waiting for scsi devices to se= ttle Mar 3 17:42:13 byz959 /kernel.old: (ahc0:0:0): "SEAGATE ST39140W 1444"= type 0 fixed SCSI 2 Mar 3 17:42:13 byz959 /kernel.old: sd0(ahc0:0:0): Direct-Access 8683MB= (17783240 512 byte sectors) Mar 3 17:42:13 byz959 /kernel.old: sd0(ahc0:0:0): with 9006 cyls, 8 he= ads, and an average 246 sectors/track Mar 3 17:42:13 byz959 /kernel.old: (ahc0:1:0): "IBM DDRS-39130W S97B" = type 0 fixed SCSI 2 Mar 3 17:42:13 byz959 /kernel.old: sd1(ahc0:1:0): Direct-Access 8715MB= (17850000 512 byte sectors) Mar 3 17:42:13 byz959 /kernel.old: sd1(ahc0:1:0): with 8387 cyls, 10 h= eads, and an average 212 sectors/track Mar 3 17:42:13 byz959 /kernel.old: (ahc0:3:0): "HP C1537A L708" type 1= removable SCSI 2 Mar 3 17:42:14 byz959 /kernel.old: st0(ahc0:3:0): Sequential-Access de= nsity code 0x25, drive empty Mar 3 17:42:14 byz959 /kernel.old: Probing for devices on PCI bus 1: Mar 3 17:42:14 byz959 /kernel.old: vga0 rev 17 int a irq 9 on pci1:0:0 Mar 3 17:42:14 byz959 /kernel.old: Probing for devices on the ISA bus:= Mar 3 17:42:14 byz959 /kernel.old: sc0 at 0x60-0x6f irq 1 on motherboa= rd Mar 3 17:42:14 byz959 /kernel.old: sc0: VGA color <4 virtual consoles,= flags=3D0x0> Mar 3 17:42:14 byz959 /kernel.old: sio0 at 0x3f8-0x3ff irq Mar 3 17:42:14 byz959 /kernel.old: 4 on isa Mar 3 17:42:14 byz959 /kernel.old: sio0: type 16550A Mar 3 17:42:14 byz959 /kernel.old: sio1 at 0x2f8-0x2ff irq 3 on isa Mar 3 17:42:14 byz959 /kernel.old: sio1: type 16550A Mar 3 17:42:14 byz959 /kernel.old: psm0 at 0x60-0x64 irq 12 on motherb= oard Mar 3 17:42:14 byz959 /kernel.old: psm0: model MouseMan+, device ID 0 Mar 3 17:42:14 byz959 /kernel.old: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on = isa Mar 3 17:42:14 byz959 /kernel.old: fdc0: FIFO enabled, 8 bytes thresho= ld Mar 3 17:42:14 byz959 /kernel.old: fd0: 1.44MB 3.5in Mar 3 17:42:14 byz959 /kernel.old: wdc1 at 0x170-0x177 irq 15 on isa Mar 3 17:42:14 byz959 /kernel.old: wdc1: unit 0 (atapi): , removable, accel, ovlap, dma, iordis Mar 3 17:42:14 byz959 /kernel.old: wcd0: 5512KB/sec, 128KB cache, audi= o play, 16 volume levels, ejectable tray Mar 3 17:42:14 byz959 /kernel.old: wcd0: 120mm data disc loaded, unloc= ked Mar 3 17:42:14 byz959 /kernel.old: npx0 flags 0x1 on motherboard Mar 3 17:42:14 byz959 /kernel.old: npx0: INT 16 interface Mar 3 17:42:14 byz959 /kernel.old: IP packet filtering initialized, di= vert disabled, logging limited to 100 packets/entry Mar 3 17:42:14 byz959 /kernel.old: WARNING: / was not properly dismoun= ted. Mar 3 17:42:14 byz959 /kernel.old: tx0: WARNING! cannot reset PHY Mar 3 18:26:30 byz959 /kernel: Copyright (c) 1992-1998 FreeBSD Inc. Mar 3 18:26:30 byz959 /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1= 993 Mar 3 18:26:30 byz959 /kernel: The Regents of the University of Califo= rnia. All rights reserved. Mar 3 18:26:30 byz959 /kernel: Mar 3 18:26:30 byz959 /kernel: FreeBSD 2.2.8-STABLE #0: Wed Mar 3 18:= 23:54 CET 1999 Mar 3 18:26:30 byz959 /kernel: root@byz959.bayer-ag.com:/usr/src/sys/compile/BAYER Mar 3 18:26:30 byz959 /kernel: CPU: Pentium II (quarter-micron) (448.8= 8-MHz 686-class CPU) Mar 3 18:26:30 byz959 /kernel: Origin =3D "GenuineIntel" Id =3D 0x652= Stepping=3D2 Mar 3 18:26:30 byz959 /kernel: Features=3D0x183f9ff,,MMX,> Mar 3 18:26:30 byz959 /kernel: real memory =3D 134217728 (131072K byt= es) Mar 3 18:26:30 byz959 /kernel: avail memory =3D 129490944 (126456K byt= es) Mar 3 18:26:30 byz959 /kernel: Probing for devices on PCI bus 0: Mar 3 18:26:30 byz959 /kernel: chip0 rev 2 on pci0:0:0 Mar 3 18:26:30 byz959 /kernel: chip1 rev 2 on pci0:1:0 Mar 3 18:26:30 byz959 /kernel: chip2 re= v 2 on pci0:7:0 Mar 3 18:26:30 byz959 /kernel: chip3 rev= 1 on pci0:7:1 Mar 3 18:26:30 byz959 /kernel: chip4 rev= 1 int d irq 11 on pci0:7:2 Mar 3 18:26:30 byz959 /kernel: chip5 rev 2 on pci0:7:3 Mar 3 18:26:30 byz959 /kernel: tx0 rev 6 int a Mar 3 18:26:30 byz959 /kernel: irq 10 on pci0:16:0 Mar 3 18:26:31 byz959 /kernel: tx0: address 00:e0:29:25:57:9d, type SM= C9432TX, Auto-Neg 100Mbps ^^^^^^ ^^^^^^^^^^^^^^^^ Here PHY has been recognized correctly... Mar 3 18:26:31 byz959 /kernel: ahc0 rev 0 int a irq 7 on pci0:19:0 Mar 3 18:26:31 byz959 /kernel: ahc0: aic7880 Wide Channel, SCSI Id=3D7= , 16/255 SCBs Mar 3 18:26:31 byz959 /kernel: ahc0 waiting for scsi devices to settle= Mar 3 18:26:31 byz959 /kernel: (ahc0:0:0): "SEAGATE ST39140W 1444" typ= e 0 fixed SCSI 2 Mar 3 18:26:31 byz959 /kernel: sd0(ahc0:0:0): Direct-Access 8683MB (17= 783240 512 byte sectors) Mar 3 18:26:31 byz959 /kernel: sd0(ahc0:0:0): with 9006 cyls, 8 heads,= and an average 246 sectors/track Mar 3 18:26:31 byz959 /kernel: (ahc0:1:0): "IBM DDRS-39130W S97B" type= 0 fixed SCSI 2 Mar 3 18:26:31 byz959 /kernel: sd1(ahc0:1:0): Direct-Access 8715MB (17= 850000 512 byte sectors) Mar 3 18:26:31 byz959 /kernel: sd1(ahc0:1:0): with 8387 cyls, 10 heads= , and an average 212 sectors/track Mar 3 18:26:31 byz959 /kernel: (ahc0:3:0): "HP C1537A L708" type 1 rem= ovable SCSI 2 Mar 3 18:26:31 byz959 /kernel: st0(ahc0:3:0): Sequential-Access densit= y code 0x25, drive empty Mar 3 18:26:31 byz959 /kernel: Probing for devices on PCI bus 1: Mar 3 18:26:31 byz959 /kernel: vga0 re= v 17 int a irq 9 on pci1:0:0 Mar 3 18:26:31 byz959 /kernel: Probing for devices on the ISA bus: Mar 3 18:26:31 byz959 /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Mar 3 18:26:31 byz959 /kernel: sc0: VGA color <4 virtual consoles, fla= gs=3D0x0> Mar 3 18:26:31 byz959 /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Mar 3 18:26:31 byz959 /kernel: sio0: type Mar 3 18:26:31 byz959 /kernel: 16550A Mar 3 18:26:31 byz959 /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Mar 3 18:26:31 byz959 /kernel: sio1: type 16550A Mar 3 18:26:31 byz959 /kernel: psm0 at 0x60-0x64 irq 12 on motherboard= Mar 3 18:26:31 byz959 /kernel: psm0: model MouseMan+, device ID 0 Mar 3 18:26:31 byz959 /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Mar 3 18:26:31 byz959 /kernel: fdc0: FIFO enabled, 8 bytes threshold Mar 3 18:26:31 byz959 /kernel: fd0: 1.44MB 3.5in Mar 3 18:26:31 byz959 /kernel: wdc1 at 0x170-0x177 irq 15 on isa Mar 3 18:26:31 byz959 /kernel: wdc1: unit 0 (atapi): ,= removable, accel, ovlap, dma, iordis Mar 3 18:26:31 byz959 /kernel: wcd0: 5512KB/sec, 128KB cache, audio pl= ay, 16 volume levels, ejectable tray Mar 3 18:26:32 byz959 /kernel: wcd0: 120mm data disc loaded, unlocked Mar 3 18:26:32 byz959 /kernel: npx0 flags 0x1 on motherboard Mar 3 18:26:32 byz959 /kernel: npx0: INT 16 interface Mar 3 18:26:32 byz959 /kernel: IP packet filtering initialized, divert= disabled, logging limited to 100 packets/entry Mar 3 18:26:32 byz959 /kernel: tx0: WARNING! link down Mar 3 18:26:32 byz959 /kernel: tx0: link up Mar 3 18:26:36 byz959 xntpd[115]: xntpd version=3D3.4e (beta multicast= ); Wed Feb 17 17:19:55 CET 1999 (1) Mar 3 18:26:36 byz959 xntpd[115]: tickadj =3D 5, tick =3D 10000, tvu_m= axslew =3D 495 Mar 3 18:26:38 byz959 lpd[147]: restarted Mar 3 18:26:45 byz959 login: ROOT LOGIN (root) ON ttyv0 Mar 3 18:27:53 byz959 login: ROOT LOGIN (root) ON ttyv1 Mar 3 18:30:45 byz959 /kernel: tx0: WARNING! link down Mar 3 18:30:47 byz959 /kernel: tx0: link up Mar 3 18:35:49 byz959 login: ROOT LOGIN (root) ON ttyv0 Mar 3 19:11:50 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 3 19:11:50 byz959 /kernel: tx0: CRC/Alignment error Mar 3 20:40:59 byz959 /kernel: tx0: CRC/Alignment error Mar 3 20:40:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 3 20:41:02 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 3 20:41:02 byz959 /kernel: tx0: CRC/Alignment error Mar 3 23:40:28 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 3 23:40:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 03:41:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 03:41:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 07:04:22 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 07:04:22 byz959 /kernel: tx0: CRC/Alignment error Mar 4 07:04:24 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 07:04:24 byz959 /kernel: tx0: CRC/Alignment error Mar 4 07:04:44 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 07:04:45 byz959 /kernel: tx0: CRC/Alignment error Mar 4 08:04:07 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 08:04:07 byz959 /kernel: tx0: CRC/Alignment error Mar 4 08:04:10 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 08:04:10 byz959 /kernel: tx0: CRC/Alignment error Mar 4 08:04:14 byz959 xntpd[115]: Previous time adjustment didn't comp= lete Mar 4 08:04:41 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 08:04:41 byz959 /kernel: tx0: CRC/Alignment error Mar 4 08:04:44 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 08:04:44 byz959 /kernel: tx0: CRC/Alignment error Mar 4 08:21:38 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 08:21:38 byz959 /kernel: tx0: CRC/Alignment error Mar 4 09:04:19 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 09:04:19 byz959 /kernel: tx0: CRC/Alignment error Mar 4 09:12:35 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 09:12:35 byz959 /kernel: tx0: CRC/Alignment error Mar 4 10:04:09 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 10:04:10 byz959 /kernel: tx0: CRC/Alignment error Mar 4 10:04:19 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 10:04:20 byz959 /kernel: tx0: CRC/Alignment error Mar 4 10:38:41 byz959 /kernel: ipfw: 600 Deny TCP 10.128.1.30:1554 10.250.16.201:80 in via tx0 Mar 4 10:38:54 byz959 last message repeated 2 times Mar 4 11:04:56 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 11:04:57 byz959 /kernel: tx0: CRC/Alignment error Mar 4 11:05:07 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 11:05:07 byz959 /kernel: tx0: CRC/Alignment error Mar 4 12:04:21 byz959 xntpd[115]: Previous time adjustment didn't comp= lete Mar 4 12:04:33 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 12:04:33 byz959 /kernel: tx0: CRC/Alignment error Mar 4 12:04:46 byz959 xntpd[115]: Previous time adjustment didn't comp= lete Mar 4 12:04:54 byz959 xntpd[115]: Previous time adjustment didn't comp= lete Mar 4 12:04:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 12:04:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 12:05:27 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 12:05:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:03:49 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:03:49 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:03:53 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:03:53 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:05:27 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:05:27 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:05:39 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:05:39 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:05:58 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:06:00 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:06:19 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:06:22 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:06:24 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:06:24 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:06:37 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:06:37 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:00 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:07:01 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:08 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:07:08 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:15 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:07:15 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:18 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:07:18 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:32 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:07:38 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:38 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:07:38 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:58 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:07:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:07:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:07:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:01 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:04 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:05 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:08:06 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:09 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:08:09 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:14 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:15 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:17 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:17 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:28 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:28 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:08:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:31 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:31 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:33 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:33 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:44 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:08:45 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:51 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:08:52 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:08:58 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:08:58 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:02 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:03 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:04 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:09:04 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:06 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:06 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:10 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:10 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:14 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:09:15 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:16 byz959 /kernel: tx0: Rx error status: 0x1014 Mar 4 13:09:16 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:18 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:09:18 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:34 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:34 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:36 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:09:36 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:43 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:44 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:44 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:44 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:45 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:45 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:53 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:53 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:09:53 byz959 xntpd[115]: Previous time adjustment didn't comp= lete Mar 4 13:09:55 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:09:56 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:04 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:10:04 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:11 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:10:12 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:20 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:10:20 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:40 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:10:41 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:47 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:10:50 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:10:53 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 13:10:53 byz959 /kernel: tx0: CRC/Alignment error Mar 4 13:21:04 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 13:21:04 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:07:01 byz959 login: ROOT LOGIN (root) ON ttyv0 Mar 4 14:15:37 byz959 login: ROOT LOGIN (root) ON ttyv0 Mar 4 14:58:21 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:58:21 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:58:41 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:58:41 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:58:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:58:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:06 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:08 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:11 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:11 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:12 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:12 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:13 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:13 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:24 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:28 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:34 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:59:34 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:42 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:43 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:46 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:46 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:48 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:59:48 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:48 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 14:59:48 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:56 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:59:57 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:57 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:59:57 byz959 /kernel: tx0: CRC/Alignment error Mar 4 14:59:59 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 14:59:59 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:00 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:00 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:05 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:05 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:09 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:09 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:13 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:13 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:16 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:18 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:23 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:23 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:30 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:30 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:33 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:33 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:38 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:00:38 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:48 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:49 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:50 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:51 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:51 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:53 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:54 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:00:55 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:00:56 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:02 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:02 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:02 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:02 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:02 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:03 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:03 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:05 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:05 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:09 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:09 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:11 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:12 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:13 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:01:13 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:15 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:15 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:17 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:17 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:20 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:20 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:20 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:20 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:26 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:27 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:28 byz959 /kernel: tx0: Rx error status: 0x1014 Mar 4 15:01:28 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:29 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:01:34 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:34 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:35 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:35 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:35 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:35 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:35 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:36 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:36 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:41 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:01:41 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:50 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:01:50 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:01:54 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:01:55 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:02:00 byz959 /kernel: tx0: Rx error status: 0x1016 Mar 4 15:02:00 byz959 /kernel: tx0: CRC/Alignment error Mar 4 15:02:07 byz959 /kernel: tx0: Rx error status: 0x1096 Mar 4 15:02:11 byz959 /kernel: tx0: CRC/Alignment error= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 4 16:21:38 1999 Delivered-To: freebsd-net@freebsd.org Received: from redbox.venux.net (redbox.venux.net [216.47.238.10]) by hub.freebsd.org (Postfix) with ESMTP id 473CF15051 for ; Thu, 4 Mar 1999 16:21:35 -0800 (PST) (envelope-from matthew@venux.net) Received: from thunder (net177138.hcv.com [209.153.177.138]) by redbox.venux.net (Postfix) with SMTP for id 2B7482E20A; Thu, 4 Mar 1999 19:22:33 -0500 (EST) Message-Id: <4.1.19990304190512.00a08900@mail.venux.net> X-Sender: mhagerty@mail.venux.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Mar 1999 19:20:45 -0500 To: freebsd-net@FreeBSD.ORG From: Matthew Hagerty Subject: NATd and computer to computer via Internet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings, If this is the wrong place to post this, please excuse me, but it seems on topic :) I have a cable modem and I'm running NATd on my FreeBSD box to provide Internet access for my home network. I also run ICQ on several machines. The problem I am having is if someone tries to initiate a file transfer or chat session via ICQ, it never goes through. But, if I initiate the file transfer/chat session it works. Also, I have a friend that I helped get set up on FreeBSD with the same set-up as me, but he is using a regular modem instead of a cable modem. Now neither he or I can send ICQ messages to each other, we have to always send them through the ICQ server. From what I understand ICQ communicates directly between the two computers. But if both ends of the link are running NATd, how does NATd know which internal machine to send the packets to? Am I s.o.l on this? I can however communicate fine with anyone else who is dialed-up/directly connected, I just have to always initiate the file transfers and chat session though. Thanks, Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 4 22:53:59 1999 Delivered-To: freebsd-net@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id A1AF01507C; Thu, 4 Mar 1999 22:53:54 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id WAA70054; Thu, 4 Mar 1999 22:53:37 -0800 (PST) From: Archie Cobbs Message-Id: <199903050653.WAA70054@bubba.whistle.com> Subject: PPP over synchronous lines To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Date: Thu, 4 Mar 1999 22:53:37 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To folks doing PPP over a synchronous line of any type.. If you're interesting in trying something new, I'd love to hear any comments/feedback from using mpd (net/mpd in ports) over netgraph (ftp://ftp.whistle.com/pub/archie/netgraph/index.html). With this combination you can do PPP over raw synchronous, frame relay, Ethernet, etc. If your synchronous driver is not supported, we can add support for it. Currently the ar and sr drivers are netgraph-enabled. Right now the performance will be somewhat slower due to the use of the tunnel interface; this will be fixed in the future. Feedback regarding non-PPP connections using netgraph also appreciated. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 0:30:29 1999 Delivered-To: freebsd-net@freebsd.org Received: from SIMULTAN.CH (eunet-gw.simultan.ch [194.191.191.82]) by hub.freebsd.org (Postfix) with ESMTP id B50D115135 for ; Fri, 5 Mar 1999 00:30:25 -0800 (PST) (envelope-from tseidmann@simultan.ch) Received: from simultan.ch (wsaltis-053.SIMULTAN.CH [192.92.128.53]) by SIMULTAN.CH (8.9.2/8.9.1) with ESMTP id JAA44253; Fri, 5 Mar 1999 09:29:58 +0100 (CET) Message-ID: <36DF95D1.E1ADB3BD@simultan.ch> Date: Fri, 05 Mar 1999 09:29:05 +0100 From: Thomas Seidmann X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Hagerty Cc: freebsd-net@FreeBSD.ORG Subject: Re: NATd and computer to computer via Internet References: <4.1.19990304190512.00a08900@mail.venux.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Hagerty wrote: > The problem I am having is if someone tries to initiate a file transfer or > chat session via ICQ, it never goes through. But, if I initiate the file > transfer/chat session it works. What you need is redirect _incoming_ ICQ traffic - what I mean is traffic initiated from outside of your network - on the NAT host to a particular machine on your internal net, i.e. your ICQ host. For this you need to know the port(s) ICQ is using, I don't know them. Once you know them, you should be able to use the "redirect_port" directive (see natd(8), contains an example for telnet) to redirect the traffic to an internal machine. > Also, I have a friend that I helped get set up on FreeBSD with the same > set-up as me, but he is using a regular modem instead of a cable modem. > Now neither he or I can send ICQ messages to each other, we have to always > send them through the ICQ server. The cure is the same as above for both sides. > Matthew Regards, Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 5:38:11 1999 Delivered-To: freebsd-net@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 5D33015181 for ; Fri, 5 Mar 1999 05:37:49 -0800 (PST) (envelope-from semen@iclub.nsu.ru) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.9.2/8.8.5) with ESMTP id TAA63895; Fri, 5 Mar 1999 19:36:11 +0600 (NS) Date: Fri, 5 Mar 1999 19:36:11 +0600 (NS) From: Ustimenko Semen To: ANDREAS.KLEMM.AK@bayer-ag.de Cc: " - (052)freebsd-net(a)FreeBSD.ORG" Subject: Re: fbsd 228: my problems with tx driver (Rx error status) In-Reply-To: <0006800009224752000002L022*@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I have no SMC9432 under hands, i'll got it this week-end. But i'll never get such quick machine as you :-) Anyway i'll look througth the driver again. Really, it was me, who wrote driver, other commits was cosmetic. From here i can propse following: undefine EARLY_RX in if_tx.c. As against PHY errors: epic_read_phy_register wait for not more then 0x1000 cycles passed until data is available, it's bad, i know. Try 0x100000 :-> (I don't like infinite loop, so i've limited it to 0x1000.) (epic_write_phy_register do the same:-) i hope this is the answer. P.S. smc83c17x chips works only at PCI bus speed of 33Mhz, what is speed of your one? P.P.S: sorry for late answer, as i understood, this is urgent. P.P.P.S: Here is decode of errors: 0x1000 Status is valid :-) 0x0F00 Reserved. 0x0080 Reserved???? 0x0040 Receiver is disabled. (While in monitor mode) 0x0020 Broadcast address recognised. 0x0010 Multicast address recognized. 0x0008 Missed packet. (While in monitor mode) 0x0004 CRC error 0x0002 Alignment error. 0x0001 Received without error. Bit 7 is mentioned as reserved, but happens often in your case. Good luck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 8: 4:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from mrdata.com (phydeaux.mrdata.com [207.170.64.2]) by hub.freebsd.org (Postfix) with ESMTP id B410215094 for ; Fri, 5 Mar 1999 08:04:23 -0800 (PST) (envelope-from blakef@mrdata.com) Received: (from blakef@localhost) by mrdata.com (8.8.8/8.8.5) id KAA04651 for freebsd-net@freebsd.org; Fri, 5 Mar 1999 10:04:06 -0600 (CST) From: Blake Freeburg Message-Id: <199903051604.KAA04651@mrdata.com> Subject: 3.1 machine as a router? To: freebsd-net@freebsd.org Date: Fri, 5 Mar 1999 10:04:06 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, What am I missing? This is not working, and from the handbook/FAQ, I am not sure what is wrong... Setup -------------------------------------------------------------------- Internal Machines Gateway Gateway WAN internal.net.b internal.net.a outnet.b internal.net.c outnet.a On Gateway, I have a default route to default -> outnet.b in the rc.conf GATEWAY_ENABLE="YES" DEFAULTROUTE="outnet.b" 'routed' is running, with /etc/gateways having something like net internal.net.0/27 gateway outnet.a metric 0 active on all other internal machines, they are told to route to default -> internal.net.a Problem -------------------------------------------------------------------- From 'gateway', I can get to/from anywhere. No problems From any other internal machine, I can get to gateway (internal.net.a, outnet.b), but nowhere else From outside machines, you can get to gateway, but no internal machines Other attempts ---------------------------------------------------------------------- Tried to do many variations on the /etc/gateways files, pointing the gateways to 'internal.net.a', 'outnet.b' Tried changing the default route to internal.net.a, outnet.a Added a route from outnet.a -> outnet.b Blake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 8:47:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from mrdata.com (phydeaux.mrdata.com [207.170.64.2]) by hub.freebsd.org (Postfix) with ESMTP id C519C15039 for ; Fri, 5 Mar 1999 08:47:54 -0800 (PST) (envelope-from blakef@mrdata.com) Received: (from blakef@localhost) by mrdata.com (8.8.8/8.8.5) id KAA05018; Fri, 5 Mar 1999 10:47:28 -0600 (CST) From: Blake Freeburg Message-Id: <199903051647.KAA05018@mrdata.com> Subject: Re: 3.1 machine as a router? In-Reply-To: <36E009F0.74AFBE3B@dpt-info.u-strasbg.fr> from Abdelghani ALLOUI at "Mar 5, 99 05:44:32 pm" To: alloui@dpt-info.u-strasbg.fr (Abdelghani ALLOUI) Date: Fri, 5 Mar 1999 10:47:28 -0600 (CST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Blake Freeburg wrote: > > > > Hi, > > > > What am I missing? This is not working, and from the handbook/FAQ, I am not sure what is wrong... > > > > Setup > > -------------------------------------------------------------------- > > Internal Machines Gateway Gateway WAN > > internal.net.b internal.net.a outnet.b > > internal.net.c outnet.a > > > > On Gateway, I have a default route to > > > > default -> outnet.b > > > > in the rc.conf > > > > GATEWAY_ENABLE="YES" > > DEFAULTROUTE="outnet.b" > > > > 'routed' is running, with /etc/gateways having something like > > > > net internal.net.0/27 gateway outnet.a metric 0 active > > > > on all other internal machines, they are told to route to > > > > default -> internal.net.a > > > > Problem > > -------------------------------------------------------------------- > > From 'gateway', I can get to/from anywhere. No problems > > From any other internal machine, I can get to gateway (internal.net.a, outnet.b), but nowhere else > > From outside machines, you can get to gateway, but no internal machines > > Can you get to the inetrnal.net.a interface from outside? > if no, i guess that the Gateway WAN has no route to the inetnal.net > network !! > even if routed is running on Gateway, Gateway WAN is perhaps configured > to not learn routes > on his interface leading to the Gateway... => packets from outside reach > Gateway WAN and don't go further... Yes, it should be from outside machines, you can get to either gateway interface (internal.net.a, outnet.b) For the moment I am just running 'routed' with the single line above - do I need to add more definitions? > > > > > Other attempts > > ---------------------------------------------------------------------- > > Tried to do many variations on the /etc/gateways files, pointing the gateways to 'internal.net.a', 'outnet.b' > > Tried changing the default route to internal.net.a, outnet.a > > Added a route from outnet.a -> outnet.b > > > > Blake > > > > > hope that can help > > Abdelghani > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 13:23:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from poboxer.pobox.com (unknown [208.149.16.42]) by hub.freebsd.org (Postfix) with ESMTP id 7A0401517F for ; Fri, 5 Mar 1999 13:23:05 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.2/8.9.1) id PAA28283; Fri, 5 Mar 1999 15:21:51 -0600 (CST) (envelope-from alk) From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 5 Mar 1999 15:21:50 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: freebsd-net@freebsd.org Subject: ipfw module loggin X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14048.19116.381195.398455@avalon.east> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As -current builds from the box, ipfw does not support the 'log' rule option. Any reason why not? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 13:39:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id 4025B14D38 for ; Fri, 5 Mar 1999 13:39:26 -0800 (PST) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.2/8.9.1) id NAA45937; Fri, 5 Mar 1999 13:39:04 -0800 (PST) (envelope-from mph) Date: Fri, 5 Mar 1999 13:39:04 -0800 From: Matthew Hunt To: Tony Kimball Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw module loggin Message-ID: <19990305133904.A45912@wopr.caltech.edu> References: <14048.19116.381195.398455@avalon.east> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <14048.19116.381195.398455@avalon.east>; from Tony Kimball on Fri, Mar 05, 1999 at 03:21:50PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 05, 1999 at 03:21:50PM -0600, Tony Kimball wrote: > As -current builds from the box, ipfw does not support the 'log' rule > option. Any reason why not? It is a kernel issue, not an ipfw issue. options IPFIREWALL options IPFIREWALL_VERBOSE options "IPFIREWALL_VERBOSE_LIMIT=100" IPFIREWALL_VERBOSE allows logging, and the LIMIT indicates how many times one rule can be logged, to keep your disk from filling up. -- Matthew Hunt * Stay close to the Vorlon. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 13:44:39 1999 Delivered-To: freebsd-net@freebsd.org Received: from poboxer.pobox.com (unknown [208.149.16.42]) by hub.freebsd.org (Postfix) with ESMTP id 3FCC315265 for ; Fri, 5 Mar 1999 13:44:28 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.2/8.9.1) id PAA28413; Fri, 5 Mar 1999 15:43:00 -0600 (CST) (envelope-from alk) From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 5 Mar 1999 15:42:56 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: mph@astro.caltech.edu Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw module loggin References: <14048.19116.381195.398455@avalon.east> <19990305133904.A45912@wopr.caltech.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14048.20340.436798.174118@avalon.east> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Matthew Hunt on Fri, 5 March: : On Fri, Mar 05, 1999 at 03:21:50PM -0600, Tony Kimball wrote: : : > As -current builds from the box, ipfw does not support the 'log' rule : > option. Any reason why not? : : It is a kernel issue, not an ipfw issue. ... : options IPFIREWALL_VERBOSE Yes, this much I understand. Allow me to clarify the query: Using ipfw.ko, the logging option is NOT supported. Is there a reason for this behaviour? If not, I would certainly prefer that the option to log should be permitted by default. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 15:50:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 6188A15280 for ; Fri, 5 Mar 1999 15:50:39 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA17823 for freebsd-net@FreeBSD.ORG; Sat, 6 Mar 1999 00:50:21 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 09C00883B; Sat, 6 Mar 1999 00:10:43 +0100 (CET) Date: Sat, 6 Mar 1999 00:10:43 +0100 From: Ollivier Robert To: freebsd-net@FreeBSD.ORG Subject: Re: ipfw module loggin Message-ID: <19990306001043.A26178@keltia.freenix.fr> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <14048.19116.381195.398455@avalon.east> <19990305133904.A45912@wopr.caltech.edu> <14048.20340.436798.174118@avalon.east> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <14048.20340.436798.174118@avalon.east>; from Tony Kimball on Fri, Mar 05, 1999 at 03:42:56PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5098 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Tony Kimball: > Yes, this much I understand. Allow me to clarify the query: > Using ipfw.ko, the logging option is NOT supported. Is there a > reason for this behaviour? If not, I would certainly prefer Recompile the ipfw.ko module with a "-DIPFIREWALL_VERBOSE" in CFLAGS should fix that I think. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 16:52:54 1999 Delivered-To: freebsd-net@freebsd.org Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by hub.freebsd.org (Postfix) with ESMTP id 698EE14CF9 for ; Fri, 5 Mar 1999 16:52:51 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (exchange.maxwell.syr.edu [128.230.129.241]) by maxwell.syr.edu (8.9.1a/8.9.1) with ESMTP id TAA03652 for ; Fri, 5 Mar 1999 19:42:03 GMT Received: by exchange.maxwell.syr.edu with Internet Mail Service (5.5.1960.3) id ; Fri, 5 Mar 1999 19:52:34 -0500 Message-ID: <262C3DA9BE0CD211971700A0C9B413A1CBC7@exchange.maxwell.syr.edu> From: Christopher Sedore To: "'freebsd-net@freebsd.org'" Subject: IP source address based load balancing Date: Fri, 5 Mar 1999 19:52:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At Jordan's suggestion, I'm posting this on this list. I just subscribed, but have not yet received confirmation on my subscription, so please be sure to CC: me on anything I should see. I've implemented a basic form of load balancing for IP based services. It works by assigning the same IP address to multiple machines, having all the machines receive the IP packets for that address but only pass the ones from specific sources up to the stack. The notion is that you can split the IP address space up (I use a mask and a comparison value) to distribute load across servers. My experiments have been in using the least significant bit in the 4th octet in an IP address (ie whether the 4th octet is odd or even). I don't have many high-load things here, so my testing doesn't say too much about performance. You can use any bit or bits that make sense to distribute load. I hope to go further and add redundancy through this methodology by writing a daemon to monitor the cluster and reconfigure to achieve failover. This was done with some relatively simple mods to the IP input, ARP, and ioctl routines; as well as some modification to the in_aliasreq and ifaliasreq structures. My testing has been limited thus far, but I'd be interested in learning whether or not there is interest in the code, and if so, finding someone else to look over the code, as well as try it out for themselves. The kernel code is pretty clean, but the userland interface is fairly simplistic. The kernel code might need some stylistic adjustment and some optimization, and could be extended quite a bit to include a better selection algorithm, port based service distribution, etc. Ideally, ifconfig would be extended to deal with some of the options, but I almost fainted when I examined the ifconfig source--I wrote a simple 20 line C program to do the config instead. The code mods are against 3.1-Release, but I'd guess that the patches would apply fairly easily to any 3.0 or later system. I believe that I've located an odd behavior and a bug (I don't think that the de driver supports if_allmulti correctly--I've tried fixing it without much success as yet). In any case, the code does appear to work fine with fxp and ep drivers (the only other two I have here). You can try telneting to 128.230.143.88 from an odd-4th-octet address and an even-4th-octet address and see what you get. Notice the host banners. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 22: 7:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from poboxer.pobox.com (unknown [208.149.16.42]) by hub.freebsd.org (Postfix) with ESMTP id 17946150CC for ; Fri, 5 Mar 1999 22:07:50 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.2/8.9.1) id AAA30257; Sat, 6 Mar 1999 00:06:21 -0600 (CST) (envelope-from alk) From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Mar 1999 00:06:20 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@sun.com To: roberto@keltia.freenix.fr Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw module loggin References: <14048.19116.381195.398455@avalon.east> <19990305133904.A45912@wopr.caltech.edu> <14048.20340.436798.174118@avalon.east> <19990306001043.A26178@keltia.freenix.fr> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14048.49772.978497.162673@avalon.east> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Ollivier Robert on Sat, 6 March: : : Recompile the ipfw.ko module with a "-DIPFIREWALL_VERBOSE" in CFLAGS should : fix that I think. Acknowledged and agreed. What I'm trying (perhaps failing!) to get across is that there should *instead* be a *negative* option, perhaps IPFIREWALL_DISALLOW_LOG. Luigi in particular (I think he is the author and current principal maintaner) might comment on whether there is a reason why this is a bad idea. I suspect it is just because it was most direct, while first writing the code, to #ifdef the logging part with positive logic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 5 23: 9:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 7D59014FB6 for ; Fri, 5 Mar 1999 23:09:45 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA13150; Sat, 6 Mar 1999 06:02:33 +0100 From: Luigi Rizzo Message-Id: <199903060502.GAA13150@labinfo.iet.unipi.it> Subject: Re: IP source address based load balancing To: cmsedore@maxwell.syr.edu (Christopher Sedore) Date: Sat, 6 Mar 1999 06:02:33 +0100 (MET) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <262C3DA9BE0CD211971700A0C9B413A1CBC7@exchange.maxwell.syr.edu> from "Christopher Sedore" at Mar 5, 99 07:52:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1684 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I've implemented a basic form of load balancing for IP based services. > It works by assigning the same IP address to multiple machines, having > all the machines receive the IP packets for that address but only pass > the ones from specific sources up to the stack. The notion is that you ... nice work, but as you probably note later, a true balancing mechanism should be able to handle failures and addition of more servers in a more flexible way. alsowith your setting i see a difficulty in accessing the various machines for management purposes (unless you set up an additional, different IP address for each one). a suggestion: apart from ARP handling (which is somewhat complex) why don't you use the ipfw rules to decide what addresses each machine should respond to ? This way you could use more sophisticated allocations, etc. and especially have most things outside the kernel. As for ARP handling, could you tell a bit more on how you solved the problem ? e.g. in the case of connections coming from the outside, your router will only have one entry for the IP address you use for your cluster, so it will not be able to talk to the individual machines unless you set all of them to use the same ethernet address (which is also a reasonable thing to do, probably). cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: 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) -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 6 4:56:12 1999 Delivered-To: freebsd-net@freebsd.org Received: from 30.maxwell.syr.edu (tfeed.maxwell.syr.edu [128.230.143.55]) by hub.freebsd.org (Postfix) with ESMTP id D149D1506D for ; Sat, 6 Mar 1999 04:56:08 -0800 (PST) (envelope-from cmsedore@maxwell.syr.edu) Received: from localhost (cmsedore@localhost) by 30.maxwell.syr.edu (8.9.1/8.9.1) with ESMTP id HAA08370; Sat, 6 Mar 1999 07:58:54 -0500 (EST) (envelope-from cmsedore@maxwell.syr.edu) X-Authentication-Warning: 30.maxwell.syr.edu: cmsedore owned process doing -bs Date: Sat, 6 Mar 1999 07:58:52 -0500 (EST) From: Christopher M Sedore To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: IP source address based load balancing In-Reply-To: <199903060502.GAA13150@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 6 Mar 1999, Luigi Rizzo wrote: > > I've implemented a basic form of load balancing for IP based services. > > It works by assigning the same IP address to multiple machines, having > > all the machines receive the IP packets for that address but only pass > > the ones from specific sources up to the stack. The notion is that you > ... > > nice work, but as you probably note later, a true balancing mechanism > should be able to handle failures and addition of more servers in > a more flexible way. Yes. I'm hoping that I'll be able to write a "cluster" daemon that will monitor the machines and reconfigure on failure or addition. A broadcast heartbeat would allow failure detection. This is somewhat more complex that I had originally hoped, since the operations would ideally not need a "master" machine, and would be all distributed. This means that all machines in a cluster need to somehow negotiate a mutually agreed upon configuration through broadcasting to each other. I have some not-too-developed ideas on how to do this, but there are a number of failure modes, etc that have to be considered. > alsowith your setting i see a difficulty in accessing the various > machines for management purposes (unless you set up an additional, > different IP address for each one). At present, I use an alias address on the interface for the "virtual" address. You can use the normal address for maint, etc and services would be accessed through the virtual. This is handy because a machine could be a member of multiple clusters (for apache virtual hosts, or smtp or whatever). > a suggestion: apart from ARP handling (which is somewhat complex) why > don't you use the ipfw rules to decide what addresses each machine > should respond to ? This way you could use more sophisticated > allocations, etc. and especially have most things outside the kernel. I thought about doing it this way and didn't mostly because most of the modifications required the requires modifications in all the same places. ipfw may be the way to do it, I just haven't looked that far in. One concern would be performance since a direct modification of ip_input only adds 2 comparisons and an AND per packet destined for the virtual interface, where ipfw needs more. That said, I use ipfw on my router which pushes 2000 pps on 2 interfaces and has quite a number of ipfw rules, so it may not matter too much. The allocation piece would be nice, because that way you could have certain ports distributed and certain ones not. > As for ARP handling, could you tell a bit more on how you solved the > problem ? e.g. in the case of connections coming from the outside, your > router will only have one entry for the IP address you use for your > cluster, so it will not be able to talk to the individual machines > unless you set all of them to use the same ethernet address (which is > also a reasonable thing to do, probably). Well I basically fixed the ARP code two ways. First, I changed the check that looks for others using our IP--if IP that was being ARPed belongs to the "virtual" IP, it bypasses that check. Second, when responding, I had it lookup in the arp table instead of using the local interface it found. So you just add an arp entry to your table (with the pub directive) and it uses that to answer queries: arp fxp0 128.230.143.88 01:00:5e:10:00:00 pub for example. Note that is a multicast address, which leads me to how I solved the MAC problem. When you set a filter for an alias address it calls if_allmulti for the associated interface so it hears all multicasts. This seems to work fine with everything I tried, except NT5 beta 2, which won't accept a multicast address in an ARP response. ip_input had to be modified to drop the M_MCAST flag of the packets so that upper layers would accept them. One could use promiscuous mode instead of multicast, which would solve some of the problems, and not have too much performance impact if the net was dedicated to the cluster and routed. When all is said and done, this is probably less than 20 lines of code in kernel space, across 5 or 6 files. I am thinking that ipfw is the way to do it, but its not going to eliminate much of the code already, only add flexibility. It'd be cool to distribute some services but not others, or distribute some services across 2 machines, some across those 2 plus one, etc etc. -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 6 9:31:30 1999 Delivered-To: freebsd-net@freebsd.org Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (Postfix) with ESMTP id 161E815285 for ; Sat, 6 Mar 1999 09:31:27 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.56.111]) by smtp03.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA1150; Sat, 6 Mar 1999 18:31:08 +0100 Received: from daemon.ninth-circle.org (abaddon@daemon.ninth-circle.org [192.168.0.1]) by daemon.ninth-circle.org (8.9.3/8.9.3) with ESMTP id SAA24409; Sat, 6 Mar 1999 18:32:03 +0100 (CET) (envelope-from asmodai@wxs.nl) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 06 Mar 1999 18:32:03 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Christopher M Sedore Subject: Re: IP source address based load balancing Cc: freebsd-net@FreeBSD.ORG, Luigi Rizzo Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 06-Mar-99 Christopher M Sedore wrote: > Yes. I'm hoping that I'll be able to write a "cluster" daemon that will > monitor the machines and reconfigure on failure or addition. A broadcast > heartbeat would allow failure detection. This is somewhat more complex > that I had originally hoped, since the operations would ideally not need > a "master" machine, and would be all distributed. This means that all > machines in a cluster need to somehow negotiate a mutually agreed upon > configuration through broadcasting to each other. I have some > not-too-developed ideas on how to do this, but there are a number of > failure modes, etc that have to be considered. Shouldn't a multicast heartbeat suffice? If one could avoid broadcasting wherever possible, avoid it. --- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The idea does not replace the work... Network/Security Specialist *BSD: Powered by Knowledge & Know-how To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 6 9:58:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 2BA3C15287 for ; Sat, 6 Mar 1999 09:58:03 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA00361; Sat, 6 Mar 1999 16:37:51 +0100 From: Luigi Rizzo Message-Id: <199903061537.QAA00361@labinfo.iet.unipi.it> Subject: Re: IP source address based load balancing To: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai) Date: Sat, 6 Mar 1999 16:37:51 +0100 (MET) Cc: cmsedore@maxwell.syr.edu, freebsd-net@FreeBSD.ORG, luigi@labinfo.iet.unipi.it (Luigi Rizzo) In-Reply-To: from "Jeroen Ruigrok/Asmodai" at Mar 6, 99 06:31:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3834 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On 06-Mar-99 Christopher M Sedore wrote: > > > Yes. I'm hoping that I'll be able to write a "cluster" daemon that will > > monitor the machines and reconfigure on failure or addition. A broadcast > > heartbeat would allow failure detection. This is somewhat more complex > > that I had originally hoped, since the operations would ideally not need > > a "master" machine, and would be all distributed. This means that all > > machines in a cluster need to somehow negotiate a mutually agreed upon > > configuration through broadcasting to each other. I have some > > not-too-developed ideas on how to do this, but there are a number of > > failure modes, etc that have to be considered. > > Shouldn't a multicast heartbeat suffice? If one could avoid broadcasting > wherever possible, avoid it. the issue is not broadcast vs. multicast (it's one pkt per second or so), it's guaranteeing consistent behaviour on reconfiguration -- e.g. no dropping of active connections, no double responses to a single SYN, no RST sent just because one of the server receives a pkt destined to another one... i think there is no easy way to implement a fully distributed solution without using a centralized machine as a dispatcher/NAT device. The reason is, you generally need to reconfigure things (either for adding/removing servers, or for doing some real load balancing) without breaking existing connections. This poses problems because, especially when you add new servers, you can't move already active connections and so changing filters on the fly won't work. You need your filters to work mainly on connection setup (packets with a SYN, basically) but then you have to make TCP not send a RST for pkts not matching any incoming connection... All in all i think a centralized solution (e.g. in the form of a PicoBSD machine with an in-kernel NAT for performance reasons) is much more flexible. Most pieces are already there (including a user-space natd which can be useful to test allocation policies etc.). By using a picobsd approach (or in general, a readonly filesystem since it does not have to use persistent storage), your natd switch would be not less reliable than your average router. Basically i think one could do things as follows: * define a new ipfw command, call it "natd" or so, where you define a list of servers for a given server. * let the in-kernel natd allocate connections using round robin or choose the less-loaded machine. The natd switch could even try to determine the load on each server using one of the following heuristics: * count each open connection as a unit of load (this is ok as long as all connections give approx. the same load on the server); * only count as 'loaded' connections for which there is no unacked data from either the client or the server. This should match situations where presumably the connection is idle because (presumably) the server is processing a request. Because the natd switch has an entry per connection, and has to do a connection-matching on each packet, updating the state should be reasonably cheap. You can monitor servers for being down by simply checking that the connections they serve make progress. Removing a server just requires to update the list of servers on the natd, and wait for all of its connection to terminate. Adding a new server is even easier, as it just requires to update the list of servers. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: 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) -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 6 13:29: 2 1999 Delivered-To: freebsd-net@freebsd.org Received: from grizzly.fas.com (cc69528-a.mtpls1.sc.home.com [24.6.61.166]) by hub.freebsd.org (Postfix) with ESMTP id E7DA7151BF for ; Sat, 6 Mar 1999 13:28:03 -0800 (PST) (envelope-from stanb@awod.com) Received: by grizzly.fas.com ($Revision: 1.37.109.23 $/16.2) id AA231595664; Sat, 6 Mar 1999 16:27:44 -0500 Subject: SOCKS To: freebsd-net@FreeBSD.ORG (FreBSD networking list) Date: Sat, 6 Mar 1999 16:27:44 -0500 (EST) From: "Stan Brown" X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 705 Message-Id: <19990306212804.E7DA7151BF@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I find myself behind a corporate firewall. It is a SOCKS based proxy server. So far all I have been able to make work is Netscape! How can I make ftp, telnet and ping work from behind this firewall? Pointers to info greatly appreciated. -- Stan Brown stanb@netcom.com 843-745-3154 Westvaco Charleston SC. -- Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. - (c) 1999 Stan Brown. Redistribution via the Microsoft Network is prohibited. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message