From owner-freebsd-mobile Fri Feb 6 08:50:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA10603 for freebsd-mobile-outgoing; Fri, 6 Feb 1998 08:50:42 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from cargpc5.atmos.washington.edu (cargpc5.atmos.washington.edu [128.95.176.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA10597 for ; Fri, 6 Feb 1998 08:50:40 -0800 (PST) (envelope-from dbx@atmos.washington.edu) Received: from localhost (dbx@localhost) by cargpc5.atmos.washington.edu (8.8.7/8.8.8) with SMTP id IAA27007 for ; Fri, 6 Feb 1998 08:53:46 -0800 (PST) Date: Fri, 6 Feb 1998 08:53:46 -0800 (PST) From: Doug Burks To: freebsd-mobile@FreeBSD.ORG Subject: Re: 3com 3C589D and zp0 vs. ep0 In-Reply-To: <19980205193131.11507@panix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe freebsd-mobile" Larry et al, I have struggled with a problem very similar to what you have had. I am trying to connect a local private LAN to the Internet via a laptop. Right now, I have the basics working, so I can forward my experiences, and I think Larry will find some useful stuff in there. However, given my recent experiences, I suspect I may bump into something else :) , so this is all preliminary until the setup proves itself in real life use. Like Larry, I had tried using straight FreeBSD-2.2.5 with zp0, and the result worked fine, except that the networking often hung, usually, but not always, under heavy load. So I decided to try PAO. My setup: NEC Versa 5060X PCIC -- TI PCI-1311X [running in i8-whatever emulation] 2 3Com 3C589D network cards one connected to a private LAN, one connected to the Internet Vanilla FreeBSD 2.2.5-RELEASE with the PAO-19971211 patches I ended up making three changes (so far) First, I had to add options "PCIC_TI113X_FUNC" to my kernel configuration file (likely not a problem for Larry). Second, I had to add muck around with the networking "rc" scripts. I added a "sleep 20" to the end of /etc/rc.pccard, since the routing was starting before "pccardd" had loaded the network cards, causing a long hang. I removed the routing from /etc/pccard_ether, since it only has to be set once, and /etc/rc.network's pass1 is fine. (This latter change could cause problems for setups where network cards are added and removed, but a gateway machine likely will not suffer this fate). Third, I editted /usr/src/sys/i386/isa/if_ep.c and removed the multi- casting capability, by deleting IFF_MULTICAST in the statement ini- tializing ifp->if_flags in the function "ep_attach". (There may be a way to turn off multi-casting via "ifconfig", but I could not find it). I did this because, I read in the -mobile archives that the promiscuous mode was wonky in the "ep" driver, and noticed that multi-casting turns on the promiscous mode. Like Larry, I also noticed that the "zp" driver did not set multi-casting. Unlike Larry, my wonky promiscuous mode caused serious problems, actually crashing on main Sun NFS server (admit- tedly, just an old Sun SparcStation 1). You can imagine how much fun my testing caused my users. :) All's well, that ends well. With these changes, my setup has worked under the very short and light testing I have been able to do so far. As for Larry's setup in particular, I suggest a few changes. In rc.conf, replace network_interfaces="lo0 ep0 zp0" ifconfig_ep0="inet 192.168.1.2 netmask 255.255.255.0" pccard_ether="" with network_interfaces="lo0" ifconfig_ep0="inet 192.168.1.2 netmask 255.255.255.0 link2" pccard_ether="ep0" The source code indicates that "link2" is the best way to turn on the 10baseT mode. (Yes, I have used that). And in /etc/pccard.conf, replace insert /etc/pccard_ether ep0 link0 -link1 with insert /etc/pccard_ether ep0 (I also use config any "ep0" any but I don't think that should make any difference for you). I think that's everything I had on this subject. If anyone has any questions, feel free to ask -- publicly or privately. I'm happy to help! Finally, thanks to the PAO powers-that-be for putting this together! Doug Burks dbx@atmos.washington.edu