From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 10:28:02 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F044016A420 for ; Sun, 26 Feb 2006 10:28:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30AC843D45 for ; Sun, 26 Feb 2006 10:28:01 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1QARvG9086841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2006 13:27:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1QARv3u086840; Sun, 26 Feb 2006 13:27:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 26 Feb 2006 13:27:56 +0300 From: Gleb Smirnoff To: Josef Karthauser Message-ID: <20060226102756.GE55275@FreeBSD.org> References: <20060219151435.GE15477@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060219151435.GE15477@genius.tao.org.uk> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: Default gateway - wrong interface. ! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 10:28:03 -0000 On Sun, Feb 19, 2006 at 03:14:35PM +0000, Josef Karthauser wrote: J> I'm guessing that this is a bug (or feature!). This is not a bug, nor a feature. This is a feature, that hasn't been implemented to the end. Historically, the routes in kernel were static. And they are static now. Historically, BSD won't permit you to install same IP addresses, or even addresses in the same subnet, on different interfaces. Now, FreeBSD permits addresses in the same subnet. But route entries are still static, and aren't reconfigring when an interface changes its flags. J> I've got a machine with a wlan interface (iwi0), with an ipv4 network J> address and a default gateway. I also have an ethernet card in the same J> machine (em0) with the same IP address. The idea is that I can bring J> the wireless down, and the wired interface up to get fast transfers when J> approriate, and be wireless the rest of the time. J> J> That works fine, apart from the default gateway: J> J> # ifconfig iwi0 down J> # ifconfig em0 up J> # arp -ad J> # netstat -rn J> Internet: J> Destination Gateway Flags Refs Use Netif J> Expire J> default 87.74.4.33 UGS 0 123 iwi0 J> 87.74.4.32/27 link#3 UC 0 0 em0 J> 87.74.4.33 00:90:d0:02:3f:16 UHLW 2 1 em0 J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW 1 1191414 em0 J> 127.0.0.1 127.0.0.1 UH 0 2 lo0 J> J> Notice, the local subnet is off the em0, but the default route is still J> wired off the iwi0. J> J> # route delete default J> # route add default 87.74.4.33 J> # netstat -rn J> Internet: J> Destination Gateway Flags Refs Use Netif J> Expire J> default 87.74.4.33 UGS 0 123 iwi0 J> 87.74.4.32/27 link#3 UC 0 0 em0 J> 87.74.4.33 00:90:d0:02:3f:16 UHLW 2 1 em0 J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW 1 1191414 em0 J> 127.0.0.1 127.0.0.1 UH 0 2 lo0 J> J> The default route is _still_ off iwi0; but should be off em0. J> J> There's obviously something dumb doing on here. Why does the default J> route have to be nailed to an interface? It's clear that 87.74.4.33 is J> available from em0 as far as the routing table is concerned. J> J> Joe -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 10:32:56 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE90A16A420 for ; Sun, 26 Feb 2006 10:32:56 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A861443D75 for ; Sun, 26 Feb 2006 10:32:51 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k1QAWoqE086920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2006 13:32:50 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k1QAWikk086919; Sun, 26 Feb 2006 13:32:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 26 Feb 2006 13:32:44 +0300 From: Gleb Smirnoff To: Chris Howells Message-ID: <20060226103244.GF55275@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Chris Howells , Jack Vogel , freebsd-net@freebsd.org References: <63472.192.168.0.1.1140456976.squirrel@webmail.devrandom.org.uk> <2a41acea0602201104v1c160788rf9db6bb5c96e7b34@mail.gmail.com> <51496.192.168.0.1.1140464280.squirrel@webmail.devrandom.org.uk> <2a41acea0602201749t48930ec1pbb90fb9656aa6297@mail.gmail.com> <54431.192.168.0.1.1140488488.squirrel@webmail.devrandom.org.uk> <2a41acea0602202023q1688f135ld364e907c7a6b04@mail.gmail.com> <57314.192.168.0.1.1140522671.squirrel@webmail.devrandom.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <57314.192.168.0.1.1140522671.squirrel@webmail.devrandom.org.uk> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, Jack Vogel Subject: Re: Which motherboards work well with em(4)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 10:32:56 -0000 On Tue, Feb 21, 2006 at 11:51:11AM -0000, Chris Howells wrote: C> Oh yes sorry, should have clarified that. Correct, it hangs on receive, C> consistently -- never ever on transmit. Though the conditions to cause it C> to hang on rx are sadly somewhat unpredictable. I haven't seen the problem C> really since before Christmas until recently when I've seen it quite a C> lot. But then again I am transferring more data around at the moment due C> to trying to recover from a hard disk failure in the 6.1-pre machine. Can you please try the following, when the card wedges again: sysctl dev.dev.em.0.stats=1 Then show us the last part of the dmesg output. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 12:19:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9604116A420 for ; Sun, 26 Feb 2006 12:19:21 +0000 (GMT) (envelope-from newsletter@lattka.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1373143D45 for ; Sun, 26 Feb 2006 12:19:20 +0000 (GMT) (envelope-from newsletter@lattka.de) Received: from [84.189.183.109] (helo=viggo.lattka.de) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FDKrv2YaT-0007ho; Sun, 26 Feb 2006 13:19:20 +0100 From: Andreas Lattka To: FreeBSD Mailing Liste In-Reply-To: <1140469974.1008.23.camel@viggo.lattka.de> References: <1140469974.1008.23.camel@viggo.lattka.de> Content-Type: text/plain Date: Sun, 26 Feb 2006 13:19:18 +0100 Message-Id: <1140956358.90767.2.camel@viggo.lattka.de> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:c4c1729c3dae779f9f6a5bcbffc2a78d Subject: Re: Cannot unload if_ath kernel module / machine does not shut down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 12:19:21 -0000 Hi there, I changed from WEP to WPA encryption, now the laptop is shutting down correctly. Strange, why it is not working with WEP encryption? Anyway, I am happy now! Andreas Am Montag, den 20.02.2006, 22:12 +0100 schrieb Andreas Lattka: > Hello All there, > > I have got a shiny new Sony Vaio VGN-FS415E, installed FBSD6, (FreeBSD > 6.0-RELEASE-p4). For wireless connection there is built in an Atheros > 5212 chip. I configured the kernel conf file to include all the atheros > modules according to the man ath: > > device ath > device ath_hal > device ath_rate_onoe, > > all works well until the machine is to be shutdown. When I enter halt > -p, or reboot, the machine starts to shut down, but stops, after the > uptime message is displayed. Nothing more happens, I have to manually > switch off the machine. The next time I switch on the machine, the oss > sound will crash the machine. > > I did remember, that I had no problem to shut down the machine when the > ath modules were not used, so I cleared the ath modules from the kernel > conf file and did include if_ath into the loader.conf. Again, all is > going well until shutdown. Same bad behaviour. Then I tried to manually > unload the ath modules, only ath_rate module can be unloaded, ath_hal > gives device busy, and trying to unload the if_ath will freeze the > machine. I confirmed that the Atheros 5211 is working well, 5212 give > those problems. > Does anybody have any idea how to unload the if_ath module? > > Thank you! > > Andreas > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 12:34:20 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C217F16A420; Sun, 26 Feb 2006 12:34:20 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B6343D46; Sun, 26 Feb 2006 12:34:19 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.tao.org.uk [87.74.4.41]) by mailhost.tao.org.uk (Postfix) with ESMTP id 7118C5C20; Sun, 26 Feb 2006 12:34:18 +0000 (GMT) Received: by genius.tao.org.uk (Postfix, from userid 100) id 917424073; Sun, 26 Feb 2006 12:34:16 +0000 (GMT) Date: Sun, 26 Feb 2006 12:34:16 +0000 From: Josef Karthauser To: Gleb Smirnoff Message-ID: <20060226123416.GF39469@genius.tao.org.uk> References: <20060219151435.GE15477@genius.tao.org.uk> <20060226102756.GE55275@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HCdXmnRlPgeNBad2" Content-Disposition: inline In-Reply-To: <20060226102756.GE55275@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: net@FreeBSD.org Subject: Re: Default gateway - wrong interface. ! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 12:34:20 -0000 --HCdXmnRlPgeNBad2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 26, 2006 at 01:27:56PM +0300, Gleb Smirnoff wrote: > On Sun, Feb 19, 2006 at 03:14:35PM +0000, Josef Karthauser wrote: > J> I'm guessing that this is a bug (or feature!). >=20 > This is not a bug, nor a feature. This is a feature, that hasn't > been implemented to the end. >=20 > Historically, the routes in kernel were static. And they are static > now. Historically, BSD won't permit you to install same IP addresses, > or even addresses in the same subnet, on different interfaces. Now, > FreeBSD permits addresses in the same subnet. But route entries are > still static, and aren't reconfigring when an interface changes its > flags. I expected it was something like that, but I thought I'd still make a little noise about it in case someone was right on the verge of having it fixed :). Joe p.s. have you seen kern/93305? It looks like my em0 still has a few problems. Would you mind taking a look? --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --HCdXmnRlPgeNBad2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iEYEARECAAYFAkQBoEcACgkQXVIcjOaxUBYLxwCfVS2poWqAnxFJDhgW3D3U/i1A lN0An3V79illWy964YlCppSPBn+B6rTU =RQqs -----END PGP SIGNATURE----- --HCdXmnRlPgeNBad2-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 18:17:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA07716A420 for ; Sun, 26 Feb 2006 18:17:11 +0000 (GMT) (envelope-from moray@oltrelinux.com) Received: from joey.wired.org (ip-114-46.sn1.eutelia.it [62.94.114.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8DA043D49 for ; Sun, 26 Feb 2006 18:17:06 +0000 (GMT) (envelope-from moray@oltrelinux.com) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by joey.wired.org (Postfix) with ESMTP id 511DCAFEEA for ; Sun, 26 Feb 2006 19:17:07 +0100 (CET) Message-ID: <4401F0A2.5080605@oltrelinux.com> Date: Sun, 26 Feb 2006 19:17:06 +0100 From: Ciro Scognamiglio User-Agent: Mozilla Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=E89AA045 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: NIS client in a Jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 18:17:11 -0000 Hullo, I have a small server in my lan with FreeBSD 5.4-RELEASE-p11 that, among others, is running a NIS server correctly configured. I then configured a jail (as a virtual server) where I intend to run Apache and where I would like to use NIS to let (some) of the host users in instead of creating users also in the jail. Googling around and reading various jail-howto I noticed that the rcpbind daemon should not be run in the jail, but of course I need it to run in the jail to have ypbind running. Anyway, the client does not work, it tries to connect to the NIS server but it times out and, at this point, I am not really sure if it is possible to run it in a jail. I actually managed to get it run once...but, with the same identical configuration, once stopped the jail and rebooted the machine it didn't work anymore. The jail can resolve names and network works, here is its rc.conf: hostname="shelob.wired.org" network_interfaces="" clear_tmp_enable="YES" sendmail_enable="NO" sshd_enable="YES" rpcbind_enable="NO" nisdomainname="linc-domain" nis_client_enable="YES" nis_client_flags="-S linc-domain,linc" Is there anything wrong? (linc is of course the host machine) The hosted machine NIS server and Jail configuration in rc.conf: # NIS/YP nisdomainname="linc-domain" nis_server_enable="YES" #nis_server_flags="" nis_yppasswdd_enable="YES" #nis_yppasswdd_flags="" nis_client_enable="YES" nis_client_flags="-S linc-domain,192.168.0.4" # # JAIL # jail_enable="YES" # Set to NO to disable starting of any jails jail_list="shelob" # Space separated list of names of jails jail_shelob_rootdir="/usr/jail/shelob" jail_shelob_hostname="shelob.wired.org" jail_shelob_ip="192.168.0.5" jail_shelob_exec="/bin/sh /etc/rc" jail_shelob_devfs_enable="YES" jail_shelob_devfs_ruleset="devfsrules_jail" jail_shelob_fdescfs_enable="YES" jail_shelob_procfs_enable="YES" jail_shelob_mount_enable="YES" thnx in advance for your help. Ciro. P.S. On the host machine I managed to get almost all running services listening on the phisical interface IP address, I couldn't manage to get mountd, nmdb, rcpbind and the yp* services to listen only on that IP. P.P.S. Inside the jail I got the following messages in /var/log/messages: Feb 26 18:43:59 shelob /usr/sbin/ypbind[38440]: could not read from child: Interrupted system call Investigating ypbind.c it turned out to be an error caused by a read or write from a pipe... I stopped ypbind on the host machine and the error (in the jail) disappeared...I guess ypbind is not really ready for jail isn't it? From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 19:22:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5BA516A420 for ; Sun, 26 Feb 2006 19:22:02 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7538C43D5A for ; Sun, 26 Feb 2006 19:21:59 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 51D9999; Sun, 26 Feb 2006 14:22:20 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 0AFF310CFF; Sun, 26 Feb 2006 14:22:18 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FDRSt-000HXC-KO; Sun, 26 Feb 2006 19:21:55 +0000 Date: Sun, 26 Feb 2006 19:21:55 +0000 From: Brian Candler To: Palle Girgensohn Message-ID: <20060226192155.GA40152@uk.tiscali.com> References: <9E9665D692686C04B3505EBC@rambutan.pingpong.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9E9665D692686C04B3505EBC@rambutan.pingpong.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: nfs locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 19:22:02 -0000 On Fri, Feb 24, 2006 at 03:58:09PM +0100, Palle Girgensohn wrote: > It seems that NFS locking is broken for the combo of 4.11 or 5.4 server and > 6.x client. Apps like eclipse and firefox fail to start with my home dir on > a 4.11 server and a 6.x client. This in interesting to me - I'll explain why in a moment. But firstly, do you have any evidence that this is an NFS locking issue? I thought (maybe incorrectly) that FreeBSD did not implement NFS locking on the server side at all, only as a client. My issue is this. I used to use a noisy but fast 2.4GHz machine as my general-purpose workstation - browsing, compiling etc. I have now moved this onto a low-power passively-cooled machine (Mappit A4F) which is fantastic; I can leave it on 24x7 and it doesn't make a whisper. However to have fast compiling when needed, I decided to export /home from this box to the old fast machine. I thought that I should just be able to compile software as before, but some makefiles just don't seem to work. The clocks on the two boxes are synchronised, to within a second anyway. I haven't yet taken the time to nail down what the problem exactly is though. Maybe it *is* relying on locking somehow, directly or indirectly. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 20:48:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6FCE16A420 for ; Sun, 26 Feb 2006 20:48:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 297DC43D75 for ; Sun, 26 Feb 2006 20:48:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 04DE41A4DEE; Sun, 26 Feb 2006 12:48:44 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1BD6F53485; Sun, 26 Feb 2006 15:48:43 -0500 (EST) Date: Sun, 26 Feb 2006 15:48:42 -0500 From: Kris Kennaway To: Brian Candler Message-ID: <20060226204842.GA40059@xor.obsecurity.org> References: <9E9665D692686C04B3505EBC@rambutan.pingpong.net> <20060226192155.GA40152@uk.tiscali.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20060226192155.GA40152@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Palle Girgensohn Subject: Re: nfs locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 20:48:47 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 26, 2006 at 07:21:55PM +0000, Brian Candler wrote: > On Fri, Feb 24, 2006 at 03:58:09PM +0100, Palle Girgensohn wrote: > > It seems that NFS locking is broken for the combo of 4.11 or 5.4 server= and=20 > > 6.x client. Apps like eclipse and firefox fail to start with my home di= r on=20 > > a 4.11 server and a 6.x client. >=20 > This in interesting to me - I'll explain why in a moment. But firstly, do > you have any evidence that this is an NFS locking issue? I thought (maybe > incorrectly) that FreeBSD did not implement NFS locking on the server side > at all, only as a client. It's supported it since the early 5.x days. However, evidence is that it was broken in some situations in 6.0-RELEASE. Kris --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFEAhQqWry0BWjoQKURArSoAJ94opG85ar8pITEoSPiwkrF1ibt7gCfW0bR xlX9MYlU9VZfm02BApt3UJY= =rStp -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 26 21:06:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6786A16A420 for ; Sun, 26 Feb 2006 21:06:45 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E7143D46 for ; Sun, 26 Feb 2006 21:06:43 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k1QL6go7086995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2006 13:06:43 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <44021923.2040606@errno.com> Date: Sun, 26 Feb 2006 13:09:55 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: Andreas Lattka References: <1140469974.1008.23.camel@viggo.lattka.de> <1140956358.90767.2.camel@viggo.lattka.de> In-Reply-To: <1140956358.90767.2.camel@viggo.lattka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Mailing Liste Subject: Re: Cannot unload if_ath kernel module / machine does not shut down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2006 21:06:45 -0000 Andreas Lattka wrote: > Hi there, > > I changed from WEP to WPA encryption, now the laptop is shutting down > correctly. Strange, why it is not working with WEP encryption? The cipher modules fail to unload if there are outstanding references to keys. When you use wpa the supplicant clears all keys before it terminates so it may be that when you were using WEP keys they were still present and somehow caused the shutdown to hang. Please send me the exact steps you use to cause the problem. There should also be console messages printed by the wlan_wep module (or other crypto module) in the event you try to unload the module while there are still references; please check for those. Sam > > Anyway, I am happy now! > > Andreas > > Am Montag, den 20.02.2006, 22:12 +0100 schrieb Andreas Lattka: >> Hello All there, >> >> I have got a shiny new Sony Vaio VGN-FS415E, installed FBSD6, (FreeBSD >> 6.0-RELEASE-p4). For wireless connection there is built in an Atheros >> 5212 chip. I configured the kernel conf file to include all the atheros >> modules according to the man ath: >> >> device ath >> device ath_hal >> device ath_rate_onoe, >> >> all works well until the machine is to be shutdown. When I enter halt >> -p, or reboot, the machine starts to shut down, but stops, after the >> uptime message is displayed. Nothing more happens, I have to manually >> switch off the machine. The next time I switch on the machine, the oss >> sound will crash the machine. >> >> I did remember, that I had no problem to shut down the machine when the >> ath modules were not used, so I cleared the ath modules from the kernel >> conf file and did include if_ath into the loader.conf. Again, all is >> going well until shutdown. Same bad behaviour. Then I tried to manually >> unload the ath modules, only ath_rate module can be unloaded, ath_hal >> gives device busy, and trying to unload the if_ath will freeze the >> machine. I confirmed that the Atheros 5211 is working well, 5212 give >> those problems. >> Does anybody have any idea how to unload the if_ath module? >> >> Thank you! >> >> Andreas >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 07:52:32 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C49C816A420; Mon, 27 Feb 2006 07:52:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC15B43D4C; Mon, 27 Feb 2006 07:52:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (glebius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1R7qU0V034494; Mon, 27 Feb 2006 07:52:30 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1R7qUF1034490; Mon, 27 Feb 2006 07:52:30 GMT (envelope-from glebius) Date: Mon, 27 Feb 2006 07:52:30 GMT From: Gleb Smirnoff Message-Id: <200602270752.k1R7qUF1034490@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-rc@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: bin/93727: [ifconfig] polling parameter in ifconfig statement of rc.conf not handled correctly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 07:52:32 -0000 Old Synopsis: polling parameter in ifconfig statement of rc.conf not handled correctly New Synopsis: [ifconfig] polling parameter in ifconfig statement of rc.conf not handled correctly Responsible-Changed-From-To: freebsd-rc->freebsd-net Responsible-Changed-By: glebius Responsible-Changed-When: Mon Feb 27 07:51:59 UTC 2006 Responsible-Changed-Why: Bug in ifconfig(8), not in rc. http://www.freebsd.org/cgi/query-pr.cgi?pr=93727 From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 09:49:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1062F16A420 for ; Mon, 27 Feb 2006 09:49:20 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D0F943D46 for ; Mon, 27 Feb 2006 09:49:18 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-121-243.51-151.net24.it [151.51.243.121]) (authenticated bits=128) by parrot.aev.net (8.13.5/8.13.5) with ESMTP id k1RA0oxI020217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 27 Feb 2006 11:00:57 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.13.5/8.13.3) with ESMTP id k1R9mXfY035947; Mon, 27 Feb 2006 10:48:33 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <4402CB15.3010404@netfence.it> Date: Mon, 27 Feb 2006 10:49:09 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.53 on 212.31.247.179 Cc: spe@phear.org Subject: freevrrpd and em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 09:49:20 -0000 Hello. I'm trying to get freevrrpd working on an AMD64 6.0p4 box with an xl0 and em0 machine. Here is the config file: > [VRID] > serverid = 1 > interface = xl0 > priority = 254 > addr = 192.168.0.4/32 > password = xxxxx > vridsdep = 3 > [VRID] > serverid = 2 > interface = xl0 > priority = 255 > addr = 192.168.0.5/32 > password = xxxxx > [VRID] > serverid = 3 > interface = em0 > priority = 254 > addr = 192.168.101.5/32 > password = xxxxx > vridsdep=1 > monitoredcircuits=no > [VRID] > serverid=4 > interface=em0 > priority=255 > addr=192.168.101.6/32 > password=xxxxx > monitoredcircuits=no This used to work until this box replaced the old machine which had fxp0 instead of em0; the other machine has fxp0 and fxp1. I had to add monitoredcirtuits=no, otherwise em0 would connect and disconnect (no carrier) at 2 secs intervals (I read this on a post somewhere). However this only solves part of the problems, since both boxes will grab 192.168.101.5 and 192.168.101.6 at the same time. The same post reports this is fixed in CVS, so I went to the master web site and followed instructions to do so. However my connection is refused and I suspect that's a problem with the CVS server side. The other side (xl0) works perfectly. I cannot switch to carp, since the other machine is running 4.11. Any hint? Has someone been able to download the CVS sources? If so, would it be too much trouble sending them to me? Any magic switch to put in conf? Remove .diespammer to answer to me directly, please. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 10:04:51 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF4D716A420; Mon, 27 Feb 2006 10:04:51 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A4FF43D4C; Mon, 27 Feb 2006 10:04:51 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (glebius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1RA4pMB042563; Mon, 27 Feb 2006 10:04:51 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1RA4pwx042559; Mon, 27 Feb 2006 10:04:51 GMT (envelope-from glebius) Date: Mon, 27 Feb 2006 10:04:51 GMT From: Gleb Smirnoff Message-Id: <200602271004.k1RA4pwx042559@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, ambrisko@FreeBSD.org Cc: Subject: Re: bin/93727: [ifconfig] polling parameter in ifconfig statement of rc.conf not handled correctly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 10:04:52 -0000 Synopsis: [ifconfig] polling parameter in ifconfig statement of rc.conf not handled correctly Responsible-Changed-From-To: freebsd-net->ambrisko Responsible-Changed-By: glebius Responsible-Changed-When: Mon Feb 27 10:04:06 UTC 2006 Responsible-Changed-Why: Doug has already fixed this problem in HEAD. Assign to him, to remind that MFC is required. http://www.freebsd.org/cgi/query-pr.cgi?pr=93727 From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 11:02:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD3D16A420 for ; Mon, 27 Feb 2006 11:02:37 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315A143D8F for ; Mon, 27 Feb 2006 11:02:37 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k1RB2a7T047088 for ; Mon, 27 Feb 2006 11:02:36 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k1RB2ZSV047082 for freebsd-net@freebsd.org; Mon, 27 Feb 2006 11:02:35 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Feb 2006 11:02:35 GMT Message-Id: <200602271102.k1RB2ZSV047082@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 11:02:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 16:29:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1610C16A420; Mon, 27 Feb 2006 16:29:36 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 554C543D68; Mon, 27 Feb 2006 16:29:34 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 17:29:33 +0100 Date: Mon, 27 Feb 2006 17:29:37 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Hartmut Brandt In-Reply-To: <200602271616.k1RGGITa018564@repoman.freebsd.org> Message-ID: <20060227172622.G5633@beagle.kn.op.dlr.de> References: <200602271616.k1RGGITa018564@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Feb 2006 16:29:33.0717 (UTC) FILETIME=[FDF33C50:01C63BBA] Cc: current@FreeBSD.org, net@freebsd.org Subject: 64-bit SNMP interface counters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 16:29:36 -0000 This new version has the 64-bit HC counters in the ifXTable really 64-bit on all our platforms. If anybody has interfaces > 1GBit/sec I would be interested how this works. harti On Mon, 27 Feb 2006, Hartmut Brandt wrote: HB>harti 2006-02-27 16:16:18 UTC HB> HB> FreeBSD src repository HB> HB> src/contrib/bsnmp - Imported sources HB> Update of /home/ncvs/src/contrib/bsnmp HB> In directory repoman.freebsd.org:/tmp/cvs-serv18547 HB> HB> Log Message: HB> Virgin import of bsnmpd 1.12 HB> HB> Status: HB> HB> Vendor Tag: BEGEMOT HB> Release Tags: BSNMP_1_12 HB> HB> U src/contrib/bsnmp/oid-list HB> U src/contrib/bsnmp/VERSION HB> U src/contrib/bsnmp/TODO HB> U src/contrib/bsnmp/README HB> U src/contrib/bsnmp/NEWS HB> U src/contrib/bsnmp/snmp_mibII/mibII.c HB> U src/contrib/bsnmp/snmp_mibII/mibII.h HB> U src/contrib/bsnmp/snmp_mibII/mibII_ifmib.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ifstack.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_interfaces.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ip.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ipaddr.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_nettomedia.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_rcvaddr.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_route.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_tcp.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_tree.def HB> U src/contrib/bsnmp/snmp_mibII/mibII_udp.c HB> U src/contrib/bsnmp/snmp_mibII/snmp_mibII.3 HB> U src/contrib/bsnmp/snmp_mibII/snmp_mibII.h HB> N src/contrib/bsnmp/snmp_mibII/mibII_begemot.c HB> N src/contrib/bsnmp/snmp_mibII/BEGEMOT-MIB2-MIB.txt HB> N src/contrib/bsnmp/snmp_mibII/BEGEMOT-IP-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/BEGEMOT-NTP-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/NTP-PROXY-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/ntp_tree.def HB> U src/contrib/bsnmp/snmp_ntp/snmp_ntp.c HB> U src/contrib/bsnmp/snmp_ntp/NTP-MIB.txt HB> U src/contrib/bsnmp/lib/asn1.3 HB> U src/contrib/bsnmp/lib/asn1.c HB> U src/contrib/bsnmp/lib/asn1.h HB> U src/contrib/bsnmp/lib/bsnmpagent.3 HB> U src/contrib/bsnmp/lib/bsnmpclient.3 HB> U src/contrib/bsnmp/lib/bsnmplib.3 HB> U src/contrib/bsnmp/lib/snmp.c HB> U src/contrib/bsnmp/lib/snmp.h HB> U src/contrib/bsnmp/lib/snmpagent.c HB> U src/contrib/bsnmp/lib/snmpagent.h HB> U src/contrib/bsnmp/lib/snmpclient.c HB> U src/contrib/bsnmp/lib/snmpclient.h HB> U src/contrib/bsnmp/lib/snmppriv.h HB> U src/contrib/bsnmp/lib/support.c HB> U src/contrib/bsnmp/lib/support.h HB> U src/contrib/bsnmp/gensnmptree/gensnmptree.1 HB> U src/contrib/bsnmp/gensnmptree/gensnmptree.c HB> U src/contrib/bsnmp/gensnmpdef/gensnmpdef.1 HB> U src/contrib/bsnmp/gensnmpdef/gensnmpdef.c HB> U src/contrib/bsnmp/snmpd/BEGEMOT-MIB.txt HB> U src/contrib/bsnmp/snmpd/BEGEMOT-SNMPD.txt HB> U src/contrib/bsnmp/snmpd/FOKUS-MIB.txt HB> U src/contrib/bsnmp/snmpd/action.c HB> U src/contrib/bsnmp/snmpd/bsnmpd.1 HB> U src/contrib/bsnmp/snmpd/config.c HB> U src/contrib/bsnmp/snmpd/export.c HB> U src/contrib/bsnmp/snmpd/main.c HB> U src/contrib/bsnmp/snmpd/snmpd.config HB> U src/contrib/bsnmp/snmpd/snmpd.h HB> U src/contrib/bsnmp/snmpd/snmpd.sh HB> U src/contrib/bsnmp/snmpd/snmpmod.3 HB> U src/contrib/bsnmp/snmpd/snmpmod.h HB> U src/contrib/bsnmp/snmpd/trans_lsock.c HB> U src/contrib/bsnmp/snmpd/trans_lsock.h HB> U src/contrib/bsnmp/snmpd/trans_udp.c HB> U src/contrib/bsnmp/snmpd/trans_udp.h HB> U src/contrib/bsnmp/snmpd/trap.c HB> U src/contrib/bsnmp/snmpd/tree.def HB> HB> No conflicts created by this import HB> HB> HB> HB> From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 18:50:37 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D3D116A420; Mon, 27 Feb 2006 18:50:37 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8731043D58; Mon, 27 Feb 2006 18:50:33 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 27 Feb 2006 10:50:33 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id k1RIoXYi080533; Mon, 27 Feb 2006 10:50:33 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k1RIoWMg080532; Mon, 27 Feb 2006 10:50:32 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200602271850.k1RIoWMg080532@ambrisko.com> In-Reply-To: <20060226102756.GE55275@FreeBSD.org> To: Gleb Smirnoff Date: Mon, 27 Feb 2006 10:50:32 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: Josef Karthauser , net@freebsd.org Subject: Re: Default gateway - wrong interface. ! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 18:50:37 -0000 Gleb Smirnoff writes: | On Sun, Feb 19, 2006 at 03:14:35PM +0000, Josef Karthauser wrote: | J> I'm guessing that this is a bug (or feature!). | | This is not a bug, nor a feature. This is a feature, that hasn't | been implemented to the end. | | Historically, the routes in kernel were static. And they are static | now. Historically, BSD won't permit you to install same IP addresses, | or even addresses in the same subnet, on different interfaces. Now, | FreeBSD permits addresses in the same subnet. But route entries are | still static, and aren't reconfigring when an interface changes its | flags. | | J> I've got a machine with a wlan interface (iwi0), with an ipv4 network | J> address and a default gateway. I also have an ethernet card in the same | J> machine (em0) with the same IP address. The idea is that I can bring | J> the wireless down, and the wired interface up to get fast transfers when | J> approriate, and be wireless the rest of the time. | J> | J> That works fine, apart from the default gateway: | J> | J> # ifconfig iwi0 down | J> # ifconfig em0 up | J> # arp -ad | J> # netstat -rn | J> Internet: | J> Destination Gateway Flags Refs Use Netif | J> Expire | J> default 87.74.4.33 UGS 0 123 iwi0 | J> 87.74.4.32/27 link#3 UC 0 0 em0 | J> 87.74.4.33 00:90:d0:02:3f:16 UHLW 2 1 em0 | J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW 1 1191414 em0 | J> 127.0.0.1 127.0.0.1 UH 0 2 lo0 | J> | J> Notice, the local subnet is off the em0, but the default route is still | J> wired off the iwi0. | J> | J> # route delete default | J> # route add default 87.74.4.33 | J> # netstat -rn | J> Internet: | J> Destination Gateway Flags Refs Use Netif | J> Expire | J> default 87.74.4.33 UGS 0 123 iwi0 | J> 87.74.4.32/27 link#3 UC 0 0 em0 | J> 87.74.4.33 00:90:d0:02:3f:16 UHLW 2 1 em0 | J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW 1 1191414 em0 | J> 127.0.0.1 127.0.0.1 UH 0 2 lo0 | J> | J> The default route is _still_ off iwi0; but should be off em0. | J> | J> There's obviously something dumb doing on here. Why does the default | J> route have to be nailed to an interface? It's clear that 87.74.4.33 is | J> available from em0 as far as the routing table is concerned. FWIW, we have a patch here for 4.X that deals with this: Index: sys/net/if.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if.c,v retrieving revision 1.85.2.25 diff -u -p -r1.85.2.25 if.c --- sys/net/if.c 28 Nov 2003 15:09:03 -0000 1.85.2.25 +++ sys/net/if.c 14 Oct 2004 03:49:08 -0000 @@ -553,6 +553,7 @@ ifa_ifwithaddr(addr) #define equal(a1, a2) \ (bcmp((caddr_t)(a1), (caddr_t)(a2), ((struct sockaddr *)(a1))->sa_len) == 0) TAILQ_FOREACH(ifp, &ifnet, if_link) + if (ifp->if_flags & IFF_UP) TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) continue; @@ -578,7 +579,7 @@ ifa_ifwithdstaddr(addr) register struct ifaddr *ifa; TAILQ_FOREACH(ifp, &ifnet, if_link) - if (ifp->if_flags & IFF_POINTOPOINT) + if (ifp->if_flags & IFF_POINTOPOINT && ifp->if_flags & IFF_UP) TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { if (ifa->ifa_addr->sa_family != addr->sa_family) continue; @@ -617,6 +618,7 @@ ifa_ifwithnet(addr) * addresses in this address family. */ TAILQ_FOREACH(ifp, &ifnet, if_link) { + if (ifp->if_flags & IFF_UP) TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { register char *cp, *cp2, *cp3; I had to fix a couple of these since we up/down NIC's like you say. We also have a local patch to make some NIC to just turn off/on the RX & TX stuff during a down/up so that the NIC doesn't re-initialize. I'm not sure how well it fits in with -current and that future network changes. If the network guys would like this added I could do it. Doug A. From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 20:03:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE6E16A420 for ; Mon, 27 Feb 2006 20:03:09 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [64.81.113.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C57F243D48 for ; Mon, 27 Feb 2006 20:03:06 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id E1C317CD; Mon, 27 Feb 2006 14:03:02 -0600 (CST) Date: Mon, 27 Feb 2006 14:03:01 -0600 From: Craig Boston To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20060227200301.GB247@nowhere> References: <20060125152032.GA40581@nowhere> <20060127020528.GA18728@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Race condition in ip6_getpmtu (actually gif)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 20:03:09 -0000 On Mon, Feb 20, 2006 at 08:15:57PM +0900, JINMEI Tatuya wrote: > > Attached is a quick hack to protect the cached route with a mutex. A > > better fix with less overhead would be to allocate the route in a local > > variable on the stack, and only copy it to the softc if route caching is > > enabled. I'll run for a couple weeks with the patch and file a PR if > > that fixes it. > > I guess this problem was fixed with the following changes: > > http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_gif.c.diff?r1=1.57&r2=1.58 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_gif.c.diff?r1=1.23&r2=1.24 Yes, it was. I saw the changes in those files when I attempted to re-merge my patch after a cvsup. I've currently been running with no panics for 12 days with rev 1.52.2.4 of if_gif.c and rev 1.22.2.2 of in6_gif.c. Craig From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 20:27:18 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D145A16A422 for ; Mon, 27 Feb 2006 20:27:18 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 113BD43D53 for ; Mon, 27 Feb 2006 20:27:17 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A5147.dip.t-dialin.net [84.154.81.71]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k1RKRCMT095878; Mon, 27 Feb 2006 21:27:13 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k1RKRBs9006532; Mon, 27 Feb 2006 21:27:11 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k1RKU5HL083862; Mon, 27 Feb 2006 21:30:05 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200602272030.k1RKU5HL083862@fire.jhs.private> To: net@freebsd.org From: "Julian Stacey" Organization: http://berklix.com Munich Unix, BSD, Internet Consultancy User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com/~jhs/cv/ Date: Mon, 27 Feb 2006 21:30:05 +0100 Sender: jhs@flat.berklix.net Cc: Bernd Kopriva Subject: TCP_COMPAT_42 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 20:27:19 -0000 Anyone know if modern FreeBSD still supports TCP_COMPAT_42 ? I'm trying to connect to my Symmetric 375 ( An NSC 32016 running BSD 4.2 ), hardware by Bill Jollitz, 2M of main RAM, rather small kernel http://berklix.com/~jhs/symmetric/ & of course I dont have full sources, & the reconfig kernel kit has problems so I live with manufacturers old kernel. Symmetric 375 used to work with all my FreeBSD hosts, ref TCP_COMPAT_42 in my http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/sys/i386/conf/HOLZ But maybe Ive compiled newer kernel on all FreeBSd hosts by now. PS I guess more laptops running FreeBSD will in a month or 2 at http://www.vcfe.org be trying to connect to various other old BSD4.2 type vaxen & such.) Would be nice if we have support still, anyone know if it was thrown away ? Only TCP_COMPAT_42 I see in src/ is: release/doc/fr_FR.ISO8859-1/relnotes/common/new.sgml: usr.sbin/config/SMM.doc/e.t: PS If anyone knows that eg FreeBSD chucked it, but Net Or Open BSD still supports it please give a shout. I suppose I could install NET as a bridge. BTW I posted a similar question on symmetric @ berklix .... but that's a mighty small list these days, just 6 of us ! Subscriptions via majordomo@berklix.org -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 22:18:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88CF116A420 for ; Mon, 27 Feb 2006 22:18:46 +0000 (GMT) (envelope-from asegu_fbsdnet@borgtech.ca) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 240D043D49 for ; Mon, 27 Feb 2006 22:18:45 +0000 (GMT) (envelope-from asegu_fbsdnet@borgtech.ca) Received: from localhost (localhost.borgtech.ca [127.0.0.1]) by borgtech.ca (Postfix) with ESMTP id 1D0AC54BC for ; Mon, 27 Feb 2006 22:18:44 +0000 (GMT) Received: from borgtech.ca ([127.0.0.1]) by localhost (borg.internal.borgtech.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63951-03 for ; Mon, 27 Feb 2006 22:18:36 +0000 (GMT) Received: from [161.53.212.252] (unknown [161.53.212.252]) by borgtech.ca (Postfix) with ESMTP id 7E93354B7 for ; Mon, 27 Feb 2006 22:18:35 +0000 (GMT) Message-ID: <44037A94.3030903@borgtech.ca> Date: Mon, 27 Feb 2006 23:17:56 +0100 From: Andrew Seguin User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at borgtech.ca Subject: Network card selection / recommendations ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 22:18:47 -0000 Sorry for distracting with such a question as to recommendations as to network cards, but since I'm planning on upgrading a freebsd firewall (currently running 5.4-STABLE), I'll check with those who know the best! At the moment I have a firewall/router based on three fxp intel nics (a cheap sis card serves for management purposes). I'd like to upgrade to gigabit network cards (because our internet connection will be getting an upgrade from an SDSL link to a 100mbit connection in the near future). I've liked Intel to date for their 100mbit cards... but a few questions come to my mind before I chose a gigabit card, questions which I hope the community here can answer for me or help guide me into a solution. First off, several gigabit network cards advertise various kinds of network cable diagnostics (Intel "Advanced Cable Diagnostics", D-Link "Cable Diagnostic",for example). We have in one building here old wiring that wasn't professionaly installed and in most places only 10mbps works although the wires are certified cat5. We don't have the money for a good network tester with TDR to find out what kind of problem exists (although a simple pin-out tester says there are no crossed wires). So question number is really this: does anybody have any experience with this kind of functionality on a network card? is it worth anything? Second... is there any advantage to dual port cards in term of performance? I always imagined there could be a solution which could be a big performance boost if a packet came in one port, the headers only went over the PCI bus for processing by the OS, and then the firewall/gateway for example either tells the NIC to delete the packet or forward it off the second port (all without copying the entire packet into system memory). Is that just my imagination of a perfect world or...? Thank you all for sharing your wisdom! Andrew From owner-freebsd-net@FreeBSD.ORG Mon Feb 27 23:20:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F70316A420 for ; Mon, 27 Feb 2006 23:20:04 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B857843D55 for ; Mon, 27 Feb 2006 23:20:00 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from mail.your.org (server3-a.your.org [64.202.112.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id 167652AD597C; Mon, 27 Feb 2006 23:19:58 +0000 (UTC) Received: from [69.31.99.38] (pool038.dhcp.your.org [69.31.99.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTP id 60BC2A0A44B; Mon, 27 Feb 2006 23:19:57 +0000 (UTC) In-Reply-To: <44037A94.3030903@borgtech.ca> References: <44037A94.3030903@borgtech.ca> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevin Day Date: Mon, 27 Feb 2006 17:19:50 -0600 To: Andrew Seguin X-Mailer: Apple Mail (2.746.2) Cc: freebsd-net@freebsd.org Subject: Re: Network card selection / recommendations ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2006 23:20:04 -0000 On Feb 27, 2006, at 4:17 PM, Andrew Seguin wrote: > First off, several gigabit network cards advertise various kinds of > network cable diagnostics (Intel "Advanced Cable Diagnostics", D- > Link "Cable Diagnostic",for example). We have in one building here > old wiring that wasn't professionaly installed and in most places > only 10mbps works although the wires are certified cat5. We don't > have the money for a good network tester with TDR to find out what > kind of problem exists (although a simple pin-out tester says there > are no crossed wires). So question number is really this: does > anybody have any experience with this kind of functionality on a > network card? is it worth anything? > Are you trying to run 100 or 1000mbps? If the latter, keep in mind two things. 1) 1000BaseTX requires all 4 pairs(8 conductors), not the 2 pairs that 10/100 requires. It's possible the remaining 2 pairs aren't wired correctly for gigabit speeds. 2) Technically GigE requires Cat5e or Cat6, but lots of people get away with Cat 5. 3) In a perfect world, GigE over copper can only go 100 meters. Less if you're not using the right cables, not using good connectors, etc. What are your lengths like? The built in cable tester thing is basically a pass/fail that isn't too accurate. Even if it did though, what information are you looking for? If it's not working... It's not working. :) There's either a cable/connector problem, or something wrong at the switch/NIC. > Second... is there any advantage to dual port cards in term of > performance? I always imagined there could be a solution which > could be a big performance boost if a packet came in one port, the > headers only went over the PCI bus for processing by the OS, and > then the firewall/gateway for example either tells the NIC to > delete the packet or forward it off the second port (all without > copying the entire packet into system memory). Is that just my > imagination of a perfect world or...? Nope. Every dual/quad/etc port I'm aware of is treated like two totally independent cards. Even the high performance Intel boards can't share packet data between ports. Would be nice though. :) From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 00:02:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48C0116A420 for ; Tue, 28 Feb 2006 00:02:46 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from mx.netvision.com.br (mx7.netvision.com.br [200.215.94.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3FE943D45 for ; Tue, 28 Feb 2006 00:02:41 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from localhost (localhost [127.0.0.1]) by mailer.netvision.com.br (Postfix) with ESMTP id 9F65E20D91B for ; Mon, 27 Feb 2006 21:02:38 -0300 (BRT) Received: from devel.netvision.com.br (unknown [201.14.160.71]) by mx.netvision.com.br (Postfix) with ESMTP id CD5A61F80A1 for ; Mon, 27 Feb 2006 21:02:37 -0300 (BRT) From: Andre Luiz dos Santos To: freebsd-net@freebsd.org Date: Mon, 20 Feb 2006 10:09:34 -0300 User-Agent: KMail/1.8.2 X-ReadMe: What are you doing reading the headers? :-) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602201009.35208.andre@netvision.com.br> X-Virus-Scanned: amavisd-new at netvision.com.br Subject: pppoed patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 00:02:46 -0000 I've written a patch for pppoed.c 1.24 that adds the following options: -c Maximum number of processes pppoed can run simultaneously. -m Same as -c but per MAC address. -f Format is []\n. defaults to 1. Overrides -m. -t A pppoed child must start ppp in this many seconds or die. For -m and -f: -1 means no limit, 0 means forbidden. http://thiago.joi.com.br/andre/pppoed.patch.gz Feedback is welcome. What I wanted to do was "-m 0 -f macs -t 10": only allow connections from MAC addresses listed in the file "macs" and never run more than one process simultaneously for a single MAC address. And pppoed processes that don't start ppp in 10 seconds should die. Is there some way to do the same thing without this patch? Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 03:03:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2436316A420 for ; Tue, 28 Feb 2006 03:03:07 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F3D43D48 for ; Tue, 28 Feb 2006 03:03:06 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from impact.jinmei.org (unknown [2001:200:0:8002:fc4c:87b0:3965:cfb3]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2F7BD15228; Tue, 28 Feb 2006 12:03:05 +0900 (JST) Date: Tue, 28 Feb 2006 12:03:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Craig Boston In-Reply-To: <20060227200301.GB247@nowhere> References: <20060125152032.GA40581@nowhere> <20060127020528.GA18728@nowhere> <20060227200301.GB247@nowhere> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Race condition in ip6_getpmtu (actually gif)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 03:03:07 -0000 >>>>> On Mon, 27 Feb 2006 14:03:01 -0600, >>>>> Craig Boston said: >> > Attached is a quick hack to protect the cached route with a mutex. A >> > better fix with less overhead would be to allocate the route in a local >> > variable on the stack, and only copy it to the softc if route caching is >> > enabled. I'll run for a couple weeks with the patch and file a PR if >> > that fixes it. >> >> I guess this problem was fixed with the following changes: >> >> http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_gif.c.diff?r1=1.57&r2=1.58 >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_gif.c.diff?r1=1.23&r2=1.24 > Yes, it was. I saw the changes in those files when I attempted to > re-merge my patch after a cvsup. I've currently been running with no > panics for 12 days with rev 1.52.2.4 of if_gif.c and rev 1.22.2.2 of > in6_gif.c. Okay, thanks for the confirmation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 04:27:56 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EBA416A420 for ; Tue, 28 Feb 2006 04:27:56 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 48CF243D6D for ; Tue, 28 Feb 2006 04:27:56 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 23515 invoked from network); 28 Feb 2006 04:27:55 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Feb 2006 04:27:55 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 27 Feb 2006 22:27:52 -0600 (CST) From: Mike Silbersack To: Julian Stacey In-Reply-To: <200602272030.k1RKU5HL083862@fire.jhs.private> Message-ID: <20060227222544.F11734@odysseus.silby.com> References: <200602272030.k1RKU5HL083862@fire.jhs.private> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Bernd Kopriva , net@freebsd.org Subject: Re: TCP_COMPAT_42 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 04:27:56 -0000 On Mon, 27 Feb 2006, Julian Stacey wrote: > Anyone know if modern FreeBSD still supports TCP_COMPAT_42 ? TCP_COMPAT_42 just tweaked how we generated TCP initial sequence numbers. The lack of it should not be impacting your ability to connect to machines of any vintage. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 08:53:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A247316A42C for ; Tue, 28 Feb 2006 08:53:31 +0000 (GMT) (envelope-from service_ist@abwesend.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 04EEB43D68 for ; Tue, 28 Feb 2006 08:53:30 +0000 (GMT) (envelope-from service_ist@abwesend.de) Received: (qmail 9725 invoked by uid 0); 28 Feb 2006 08:53:29 -0000 Received: from 84.160.18.162 by www024.gmx.net with HTTP; Tue, 28 Feb 2006 09:53:30 +0100 (MET) Date: Tue, 28 Feb 2006 09:53:30 +0100 (MET) From: service_ist@abwesend.de To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated: #442816 Message-ID: <29981.1141116810@www024.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Only one concurrent connection in jail possible (5.4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 08:53:31 -0000 Hi, I've setup a server with 16 jails using 5.4. Right after bringing it up I wondered about its bad performance. CPU load does not increase 30% - and these are pikes when I'm running Spamassassin. The usual sytem load is 0.00 The problem must be something different. When I installed squid, I noticed the client take hours to get a webpage. At first, I thougt this might be a DNS-problem and defined an address for outgoing UDP-connections in squid. But this didn't help. For testing, I installed tinyproxy - same problem! I realized, that I couldn't make any input via the ssh-Connection as long as the client tried to get a page via the proxy. It seems as if the jail handels only one concurrent network connection. Getting a webpage via proxy takes up to 30 or more seconds, the log shows each file being fetched seperatly with up to 1 second delay between - just as long as it takes to download one of the files using wget. Usually, the proxy fetches the files in parallel. The ssh-connection I'm logged in with stays up - but nothing is transmitted: The connection freezes and is available again as soon as the proxy-transfer is completed. Transfer with other ssh-connections to other jails on that machine or the host system aren't affected at this time: One can use the ssh-connection without interference. But I think that they (the jails) are affected by the same problem when one of their processes opens a network connection - this would explain the bad performance of the services run in the other jails (postfix and mailman for example). The host does not run a paketfilter, DNS resolution in the jails is working. I'd appreciate help very much since I don't have any idea what this might come from. Peter -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 09:06:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB6B616A420 for ; Tue, 28 Feb 2006 09:06:07 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 098D843D58 for ; Tue, 28 Feb 2006 09:06:02 +0000 (GMT) (envelope-from regnauld@catpipe.net) Received: from localhost (localhost [127.0.0.1]) by localhost.catpipe.net (Postfix) with ESMTP id 0E1E51B383; Tue, 28 Feb 2006 10:06:01 +0100 (CET) Received: from moof.catpipe.net ([127.0.0.1]) by localhost (moof.catpipe.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06531-04; Tue, 28 Feb 2006 10:05:59 +0100 (CET) Received: from vinyl.catpipe.net (vinyl.catpipe.net [195.249.214.189]) by moof.catpipe.net (Postfix) with ESMTP id AF5BA1B38C; Tue, 28 Feb 2006 10:05:59 +0100 (CET) Received: by vinyl.catpipe.net (Postfix, from userid 1006) id 196F778C5D; Tue, 28 Feb 2006 10:05:24 +0100 (CET) Date: Tue, 28 Feb 2006 10:05:24 +0100 From: Phil Regnauld To: service_ist@abwesend.de Message-ID: <20060228090523.GI67387@catpipe.net> References: <29981.1141116810@www024.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29981.1141116810@www024.gmx.net> X-Operating-System: FreeBSD 6.1-PRERELEASE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at catpipe.net Cc: freebsd-net@freebsd.org Subject: Re: Only one concurrent connection in jail possible (5.4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 09:06:08 -0000 service_ist@abwesend.de (service_ist) writes: > Hi, > > I've setup a server with 16 jails using 5.4. Right after bringing it up I > wondered about its bad performance. We need to know many things here: - CPU, RAM, disk, disk layout, swap What does disk I/O look like ? (gstat) What does network I/O look like ? (netstat -ain 1) Interrupts ? (vmstat -i) Have you read tuning(7) ? There's a lot of info in there about socket tuning, network buffers, etc... Check out what the logs say, eventual warnings on the console, etc... From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 11:01:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFA0E16A420 for ; Tue, 28 Feb 2006 11:01:09 +0000 (GMT) (envelope-from service_ist@abwesend.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 166FE43D45 for ; Tue, 28 Feb 2006 11:01:08 +0000 (GMT) (envelope-from service_ist@abwesend.de) Received: (qmail invoked by alias); 28 Feb 2006 11:01:07 -0000 Received: from p54A012A2.dip0.t-ipconnect.de (EHLO ws2.peter.invalid) [84.160.18.162] by mail.gmx.net (mp019) with SMTP; 28 Feb 2006 12:01:07 +0100 X-Authenticated: #442816 From: Peter Prucker To: freebsd-net@freebsd.org Date: Tue, 28 Feb 2006 12:01:02 +0100 User-Agent: KMail/1.9.1 References: <29981.1141116810@www024.gmx.net> <20060228090523.GI67387@catpipe.net> In-Reply-To: <20060228090523.GI67387@catpipe.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602281201.02610.service_ist@abwesend.de> X-Y-GMX-Trusted: 0 Subject: Re: Only one concurrent connection in jail possible (5.4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 11:01:10 -0000 On Tuesday 28 February 2006 10:05, Phil Regnauld wrote: > service_ist@abwesend.de (service_ist) writes: > > Hi, > > > > I've setup a server with 16 jails using 5.4. Right after bringing it > > up I wondered about its bad performance. > > We need to know many things here: > > - CPU, RAM, disk, disk layout, swap CPU: AMD Sempron 3000+ RAM: real memory = 1007 MB, avail memory = 977 MB disk: 3ware 7006-2 with two Maxtor 6L160P0 in a raid 1 disk layout: /dev/twed0s1a 496M 71M 386M 15% / /dev/twed0s3d 119G 16G 94G 14% /home /dev/twed0s1g 4.8G 28K 4.5G 0% /tmp /dev/twed0s1d 4.8G 1.2G 3.3G 27% /usr /dev/twed0s1f 5.3G 328M 4.6G 7% /usr/ports /dev/twed0s1e 989M 400M 510M 44% /usr/src /dev/twed0s2d 3.9G 48M 3.5G 1% /var /dev/twed0s2e 3.9G 662M 2.9G 18% /var/ccache /dev/twed0s2f 989M 5.5M 905M 1% /var/log /dev/twed0s2g 1.9G 16M 1.8G 1% /var/tmp The jails are in /home. swap: 2 GB at twed0s1b > What does disk I/O look like ? (gstat) Just zeros, with a little flickering some times. > What does network I/O look like ? (netstat -ain 1) input (Total) output packets errs bytes packets errs bytes colls 2 0 128 2 0 296 0 1 0 66 1 0 178 0 1 0 66 1 0 178 0 1 0 66 1 0 178 0 3 0 235 2 0 297 0 2 0 126 2 0 220 0 2 0 164 3 0 374 0 3 0 204 2 0 248 0 5 0 404 3 0 416 0 1 0 66 1 0 178 0 172 0 55221 181 0 51887 0 702 0 189462 696 0 193378 0 858 0 321384 862 0 324292 0 1091 0 193559 1099 0 194596 0 917 0 212652 911 0 213837 0 734 0 240609 717 0 241236 0 6 0 444 5 0 450 0 2 0 126 1 0 178 0 1 0 66 1 0 178 0 1 0 66 1 0 178 0 The part in the middle is when I'm doing a proxy request. > Interrupts ? (vmstat -i) interrupt total rate irq8: rtc 40520502 128 irq13: npx0 1 0 irq17: twe0 11152149 35 irq23: vr0 1217326 3 irq0: clk 31654941 99 Total 84544919 267 > Have you read tuning(7) ? There's a lot of info in there about > socket tuning, network buffers, etc... I've increased net.inet.ip.portrange to 15000 and kern.ipc.somaxconn to 512, what did not bring any results. > Check out what the logs say, eventual warnings on the console, etc... No errors, no warnings. Peter From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 12:12:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44A6A16A420 for ; Tue, 28 Feb 2006 12:12:51 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6692243D46 for ; Tue, 28 Feb 2006 12:12:49 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A6834.dip.t-dialin.net [84.154.104.52]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k1SCClpO097519; Tue, 28 Feb 2006 13:12:48 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k1SCCfWq009592; Tue, 28 Feb 2006 13:12:41 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k1SCFdqM094182; Tue, 28 Feb 2006 13:15:39 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200602281215.k1SCFdqM094182@fire.jhs.private> To: Mike Silbersack In-Reply-To: Message from Mike Silbersack of "Mon, 27 Feb 2006 22:27:52 CST." <20060227222544.F11734@odysseus.silby.com> Date: Tue, 28 Feb 2006 13:15:39 +0100 From: "Julian H. Stacey" Cc: jhs@berklix.com, Bernd Kopriva , net@freebsd.org Subject: Re: TCP_COMPAT_42 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 12:12:51 -0000 Mike Silbersack wrote: > On Mon, 27 Feb 2006, Julian Stacey wrote: > > Anyone know if modern FreeBSD still supports TCP_COMPAT_42 ? > TCP_COMPAT_42 just tweaked how we generated TCP initial sequence numbers. > The lack of it should not be impacting your ability to connect to machines > of any vintage. > Mike "Silby" Silbersack Thanks Mike, Well I fixed a local problem of parity on my FreeBSD end, by changing to XTerm*eightBitInput: False XTerm*eightBitOutput: False xrdb -merge ~/.Xdefaults But rlogins & telnets to the 4.2BSD Symmetric still die after exiting first command &/or time out within first minute. (& no timeout I can see on rlogind on 4.2 end, but rlogins from 4.2 to FreeBSD run OK ! It used to work, I wonder what presumably I changed ! -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 15:32:28 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A195816A435 for ; Tue, 28 Feb 2006 15:32:28 +0000 (GMT) (envelope-from silby@silby.com) Received: from wbm3.pair.net (wbm3.pair.net [209.68.3.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6388743D72 for ; Tue, 28 Feb 2006 15:32:13 +0000 (GMT) (envelope-from silby@silby.com) Received: by wbm3.pair.net (Postfix, from userid 65534) id 1ACC76B1E6; Tue, 28 Feb 2006 10:32:12 -0500 (EST) Received: from 64.215.82.94 ([64.215.82.94]) (SquirrelMail authenticated user silby@silby.com) by webmail3.pair.com with HTTP; Tue, 28 Feb 2006 10:32:11 -0500 (EST) Message-ID: <1157.64.215.82.94.1141140731.squirrel@webmail3.pair.com> In-Reply-To: <200602281215.k1SCFdqM094182@fire.jhs.private> References: Message from Mike Silbersack of "Mon, 27 Feb 2006 22:27:52 CST." <20060227222544.F11734@odysseus.silby.com> <200602281215.k1SCFdqM094182@fire.jhs.private> Date: Tue, 28 Feb 2006 10:32:11 -0500 (EST) From: "Mike Silbersack" To: "Julian H. Stacey" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: jhs@berklix.com, Bernd Kopriva , net@freebsd.org Subject: Re: TCP_COMPAT_42 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 15:32:29 -0000 > Thanks Mike, > Well I fixed a local problem of parity on my FreeBSD end, by changing to > XTerm*eightBitInput: False > XTerm*eightBitOutput: False > xrdb -merge ~/.Xdefaults > But rlogins & telnets to the 4.2BSD Symmetric still die after exiting > first command &/or time out within first minute. (& no timeout I > can see on rlogind on 4.2 end, but rlogins from 4.2 to FreeBSD run OK ! > It used to work, I wonder what presumably I changed ! > > -- > Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. Can you grab a tcpdump of all the traffic between the two systems from the start of the connection to when it breaks? Maybe that'll tip us off as to what's wrong. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Feb 28 20:12:50 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E8DD16A420 for ; Tue, 28 Feb 2006 20:12:50 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDFCA43D55 for ; Tue, 28 Feb 2006 20:12:49 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A7A26.dip.t-dialin.net [84.154.122.38]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id k1SKCjd9098472; Tue, 28 Feb 2006 21:12:46 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.12.11/8.12.11) with ESMTP id k1SKChP8011138; Tue, 28 Feb 2006 21:12:43 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.1/8.13.1) with ESMTP id k1SKFhnQ033586; Tue, 28 Feb 2006 21:15:43 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200602282015.k1SKFhnQ033586@fire.jhs.private> To: "Mike Silbersack" In-Reply-To: Message from "Mike Silbersack" of "Tue, 28 Feb 2006 10:32:11 EST." <1157.64.215.82.94.1141140731.squirrel@webmail3.pair.com> Date: Tue, 28 Feb 2006 21:15:43 +0100 From: "Julian H. Stacey" Cc: Bernd Kopriva , net@freebsd.org Subject: Re: TCP_COMPAT_42 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 20:12:50 -0000 Hi Mike & net@ people, "Mike Silbersack" wrote: > > Thanks Mike, > > Well I fixed a local problem of parity on my FreeBSD end, by changing to > > XTerm*eightBitInput: False > > XTerm*eightBitOutput: False > > xrdb -merge ~/.Xdefaults > > But rlogins & telnets to the 4.2BSD Symmetric still die after exiting > > first command &/or time out within first minute. (& no timeout I > > can see on rlogind on 4.2 end, but rlogins from 4.2 to FreeBSD run OK ! > > It used to work, I wonder what presumably I changed ! > > > > -- > > Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. > > Can you grab a tcpdump of all the traffic between the two systems from the > start of the connection to when it breaks? Maybe that'll tip us off as to > what's wrong. OK, done. While one xterm on my 5.3 box had this runing: ------- rlogin skyr 4.2 SYMMETRIX (skyr.jhs.private) login: Last login: Tue May 31 11:39:33 from fire.jhs.private 4.2 BSD UNIX #452: Tue Mar 29 09:29:48 PST 1988 For info. browse http://www.berklix.com/~jhs/symmetric/ Warning: non 2000 compliant clock, so rdist will fail in direction this host to modern host. Logins welcome, but please don't mess things up. Thanks. Julian jhs@berklix.com Login: guest Password: guest % ls Distfile bin bk-5.log passwd.sav 4.2 SYMMETRIX (skyr.jhs.private) login: rlogin: connection closed ------- & the only things I typed into that box were rlogin skyr ls I had previously started in another xterm tcpdump -v -i rl0 -l | grep skyr & got this: ------- 5.3 p1 jhs 6 fire~ xs tcpdump -v -i rl0 -l | grep skyr tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 20:47:32.490148 IP (tos 0x0, ttl 64, id 2820, offset 0, flags [DF], length: 64) fire.jhs.private.978 > skyr.jhs.private.login: S [tcp sum ok] 3790186856:3790186856(0) win 65535 20:47:32.498014 IP (tos 0x0, ttl 15, id 201, offset 0, flags [none], length: 44) skyr.jhs.private.login > fire.jhs.private.978: S [tcp sum ok] 3589249:3589249(0) ack 3790186857 win 2048 20:47:32.498039 IP (tos 0x0, ttl 64, id 2821, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 1 win 65535 20:47:32.498061 IP (tos 0x0, ttl 64, id 2822, offset 0, flags [DF], length: 41) fire.jhs.private.978 > skyr.jhs.private.login: P [tcp sum ok] 1:2(1) ack 1 win 65535 20:47:32.503787 IP (tos 0x0, ttl 15, id 202, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 1 win 2048 20:47:32.515264 IP (tos 0x0, ttl 15, id 203, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 2 win 2047 20:47:32.515282 IP (tos 0x0, ttl 64, id 2823, offset 0, flags [DF], length: 60) fire.jhs.private.978 > skyr.jhs.private.login: P [tcp sum ok] 2:22(20) ack 1 win 65535 20:47:32.520396 IP (tos 0x0, ttl 15, id 204, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2027 20:47:32.814192 IP (tos 0x0, ttl 15, id 205, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2028 20:47:33.045023 IP (tos 0x0, ttl 15, id 206, offset 0, flags [none], length: 41) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 1:2(1) ack 22 win 2028 20:47:33.139771 IP (tos 0x10, ttl 64, id 2839, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 2 win 65535 20:47:33.144324 IP (tos 0x0, ttl 15, id 207, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2028 20:47:33.303758 IP (tos 0x0, ttl 15, id 208, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:33.745640 IP (tos 0x0, ttl 15, id 209, offset 0, flags [none], length: 93) skyr.jhs.private.login > fire.jhs.private.978: P 2:55(53) ack 22 win 2048 20:47:33.839777 IP (tos 0x10, ttl 64, id 2882, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 55 win 65535 20:47:33.844321 IP (tos 0x0, ttl 15, id 210, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:36.610595 IP (tos 0x0, ttl 15, id 211, offset 0, flags [none], length: 95) skyr.jhs.private.login > fire.jhs.private.978: P 55:110(55) ack 22 win 2048 20:47:36.709821 IP (tos 0x10, ttl 64, id 2952, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 110 win 65535 20:47:36.714387 IP (tos 0x0, ttl 15, id 212, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:36.819489 IP (tos 0x0, ttl 15, id 213, offset 0, flags [none], length: 89) skyr.jhs.private.login > fire.jhs.private.978: P 110:159(49) ack 22 win 2048 20:47:36.845663 IP (tos 0x0, ttl 15, id 214, offset 0, flags [none], length: 104) skyr.jhs.private.login > fire.jhs.private.978: P 159:223(64) ack 22 win 2048 20:47:36.845683 IP (tos 0x10, ttl 64, id 2960, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 223 win 65472 20:47:36.850662 IP (tos 0x0, ttl 15, id 215, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:36.874898 IP (tos 0x0, ttl 15, id 216, offset 0, flags [none], length: 77) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 223:260(37) ack 22 win 2048 20:47:36.919014 IP (tos 0x0, ttl 15, id 217, offset 0, flags [none], length: 107) skyr.jhs.private.login > fire.jhs.private.978: P 260:327(67) ack 22 win 2048 20:47:36.919050 IP (tos 0x10, ttl 64, id 2970, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 327 win 65469 20:47:36.923923 IP (tos 0x0, ttl 15, id 218, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:36.980045 IP (tos 0x0, ttl 15, id 219, offset 0, flags [none], length: 121) skyr.jhs.private.login > fire.jhs.private.978: P 327:408(81) ack 22 win 2048 20:47:37.021232 IP (tos 0x0, ttl 15, id 220, offset 0, flags [none], length: 71) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 408:439(31) ack 22 win 2048 20:47:37.021258 IP (tos 0x10, ttl 64, id 2980, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 439 win 65505 20:47:37.026566 IP (tos 0x0, ttl 15, id 221, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:37.056122 IP (tos 0x0, ttl 15, id 222, offset 0, flags [none], length: 71) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 439:470(31) ack 22 win 2048 20:47:37.149828 IP (tos 0x10, ttl 64, id 2995, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 470 win 65535 20:47:37.154395 IP (tos 0x0, ttl 15, id 223, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:47:38.100591 IP (tos 0x0, ttl 15, id 224, offset 0, flags [none], length: 42) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 470:472(2) ack 22 win 2048 20:47:38.199843 IP (tos 0x10, ttl 64, id 3051, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 472 win 65535 20:47:38.204405 IP (tos 0x0, ttl 15, id 225, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 22 win 2048 20:48:14.696414 arp who-has high.jhs.private tell skyr.jhs.private 20:48:22.783078 IP (tos 0x0, ttl 15, id 226, offset 0, flags [none], length: 41) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] 471:472(1) ack 21 win 2048 20:48:22.783110 IP (tos 0x10, ttl 64, id 4092, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 472 win 65535 20:48:47.757734 arp who-has high.jhs.private tell skyr.jhs.private 20:48:54.255386 arp who-has high.jhs.private tell skyr.jhs.private 20:48:59.626080 IP (tos 0x10, ttl 64, id 4880, offset 0, flags [DF], length: 41) fire.jhs.private.978 > skyr.jhs.private.login: P [tcp sum ok] 22:23(1) ack 472 win 65535 20:48:59.635479 IP (tos 0x0, ttl 15, id 227, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 23 win 2048 20:48:59.651076 IP (tos 0x0, ttl 15, id 228, offset 0, flags [none], length: 41) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 472:473(1) ack 23 win 2048 20:48:59.751096 IP (tos 0x10, ttl 64, id 4884, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 473 win 65535 20:48:59.755939 IP (tos 0x0, ttl 15, id 229, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 23 win 2048 20:49:00.071018 IP (tos 0x10, ttl 64, id 4897, offset 0, flags [DF], length: 41) fire.jhs.private.978 > skyr.jhs.private.login: P [tcp sum ok] 23:24(1) ack 473 win 65535 20:49:00.078697 IP (tos 0x0, ttl 15, id 230, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 24 win 2048 20:49:00.094708 IP (tos 0x0, ttl 15, id 231, offset 0, flags [none], length: 41) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 473:474(1) ack 24 win 2048 20:49:00.191103 IP (tos 0x10, ttl 64, id 4915, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 474 win 65535 20:49:00.195643 IP (tos 0x0, ttl 15, id 232, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 24 win 2048 20:49:01.157119 IP (tos 0x10, ttl 64, id 4935, offset 0, flags [DF], length: 41) fire.jhs.private.978 > skyr.jhs.private.login: P [tcp sum ok] 24:25(1) ack 474 win 65535 20:49:01.164810 IP (tos 0x0, ttl 15, id 233, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 25 win 2048 20:49:01.257964 IP (tos 0x0, ttl 15, id 234, offset 0, flags [none], length: 42) skyr.jhs.private.login > fire.jhs.private.978: P [tcp sum ok] 474:476(2) ack 25 win 2048 20:49:01.351121 IP (tos 0x10, ttl 64, id 4951, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 476 win 65535 20:49:01.355662 IP (tos 0x0, ttl 15, id 235, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 25 win 2048 20:49:01.948385 IP (tos 0x0, ttl 15, id 236, offset 0, flags [none], length: 94) skyr.jhs.private.login > fire.jhs.private.978: P 476:530(54) ack 25 win 2048 20:49:02.041135 IP (tos 0x10, ttl 64, id 4973, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 530 win 65535 20:49:02.045736 IP (tos 0x0, ttl 15, id 237, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 25 win 2048 20:49:02.477983 IP (tos 0x0, ttl 15, id 238, offset 0, flags [none], length: 89) skyr.jhs.private.login > fire.jhs.private.978: P 530:579(49) ack 25 win 2048 20:49:02.571140 IP (tos 0x10, ttl 64, id 4994, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 579 win 65535 20:49:02.575704 IP (tos 0x0, ttl 15, id 239, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 25 win 2048 20:49:03.103230 IP (tos 0x0, ttl 15, id 240, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: F [tcp sum ok] 579:579(0) ack 25 win 0 20:49:03.103255 IP (tos 0x10, ttl 64, id 5009, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: . [tcp sum ok] ack 580 win 65535 20:49:03.103712 IP (tos 0x10, ttl 64, id 5010, offset 0, flags [DF], length: 40) fire.jhs.private.978 > skyr.jhs.private.login: F [tcp sum ok] 25:25(0) ack 580 win 65535 20:49:03.110660 IP (tos 0x0, ttl 15, id 241, offset 0, flags [none], length: 40) skyr.jhs.private.login > fire.jhs.private.978: . [tcp sum ok] ack 26 win 0 ^C93 packets captured 93 packets received by filter 0 packets dropped by kernel ------- Notes: There's no tcpdump on my 4.2 box skyr is the 4.2-BSD box fire is the FreeBSD-5.3 box high is just an alias in my named for 192.168.x.255 Could this problem be due to different broadcasting convetions for 4.2 & 4.4, perhaps triggered by eg arpd or named etc doing discovery every minute or so ? (But FreeBSD worked for years OK to that 4.2-BSD, & I recall all FreeBSD are 4.4) PS (long shot vague idea:) used to be everthing here was on a 10M coax, but now most is on a 100M switch, but other FreeBSD host on the legacy coax & 100M switch still happily work together. I have a recent Axis ether to lpr converter on net, but disconnected that (it has some arp stuff) but made no difference, rlogin still dies. -- Julian Stacey. Consultant Unix Net & Sys. Eng., Munich. http://berklix.com Mail in Ascii, HTML=spam. Ihr Rauch = meine allergischen Kopfschmerzen. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 04:23:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB9EA16A420 for ; Wed, 1 Mar 2006 04:23:15 +0000 (GMT) (envelope-from yashy@mail.yashy.com) Received: from proksie.yashy.com (mail.yashy.com [206.248.137.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A0C43D48 for ; Wed, 1 Mar 2006 04:23:15 +0000 (GMT) (envelope-from yashy@mail.yashy.com) Message-ID: <44052198.30304@mail.yashy.com> Date: Tue, 28 Feb 2006 23:22:48 -0500 From: Yasholomew Yashinski User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pf@benzedrine.cx, freebsd-net@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: nat issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 04:23:16 -0000 I'm not sure what changed, as I haven't made any changes in the past 48 hours that I recall other than a portupgrade, however when I got home this afternoon my NAT was hosed. I'm using tun0 (PPPoE over hme0) on FreeBSD 6.0 sparc64. from pf.conf: anon_gw="206.248.137.44" nat_net="192.168.1.0/28" tun_if="tun0" nat on $tun_if from $nat_net to any -> $anon_gw # pfctl -sn nat on tun0 inet from 192.168.1.0/28 to any -> 206.248.137.44 rdr inet proto tcp from to any port = smtp -> 127.0.0.1 port 8025 from sysctl: net.inet.ip.forwarding: 1 on the firewall/gateway: # tcpdump -i rl0 port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 18:00:18.000470 IP 192.168.1.8.33243 > www.fark.com.http: S 3062197018:3062197018(0) win 5840 18:00:20.998748 IP 192.168.1.8.33243 > www.fark.com.http: S 3062197018:3062197018(0) win 5840 18:00:26.997008 IP 192.168.1.8.33243 > www.fark.com.http: S 3062197018:3062197018(0) win 5840 # tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 21:26:11.200002 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:11.255089 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 16429+ [1au] PTR? 44.137.248.206.in-addr.arpa. (56) 21:26:11.306036 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 16429 1/2/3 PTR[|domain] 21:26:11.310112 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 58322+ [1au] PTR? 0.0.0.0.in-addr.arpa. (49) 21:26:11.360753 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 58322 NXDomain* 0/1/1 (99) 21:26:12.364075 IP mail.yashy.com > 0.0.0.0: pfsync 228 21:26:12.366593 IP mail.yashy.com.51821 > dns.pppoe.ca.domain: 29161+ [1au] PTR? 22.154.248.206.in-addr.arpa. (56) 21:26:12.418296 IP dns.pppoe.ca.domain > mail.yashy.com.51821: 29161 1/2/3 PTR[|domain] 21:26:13.421003 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:14.425044 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:15.429063 IP mail.yashy.com > 0.0.0.0: pfsync 228 21:26:16.467022 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:17.712070 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:19.074030 IP mail.yashy.com > 0.0.0.0: pfsync 452 21:26:20.433105 IP mail.yashy.com > 0.0.0.0: pfsync 228 So I can see the requests going out on rl0 (but getting no reply), but it's not showing up on tun0/hme0 at all. I'm running bind on the fw/gw machine as well, so that is why the client is able to resolve www.fark.com (which makes me wonder why it's querying dns.pppoe.ca as I'm not trying to resolve anything that shouldn't be in the dns cache already..). Are all of these pfsync logs to 0.0.0.0 normal? I'm not using carp or anything, pflog is fine for me. I'm just installing lynx on the fw/gw now so I can search for myself :) On this linux client: $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.10 0.0.0.0 UG 0 0 0 eth0 >From the client machines, I'm getting an IP via dhcpd from the fw/gw. I can ping the fw/gw as well as ssh to it etc. If I ssh to the fw/gw, I can get out from it no problem. I just can't get through the fw/gw from the client machines. I have done a pfctl -Fr temporarily to ensure it's not a misconfigured rule, but still no luck. My personal guess is it's not pf related and third party, but not sure what else to test.. Thanks in Advance, -- Yashy From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 07:40:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BEA916A420 for ; Wed, 1 Mar 2006 07:40:33 +0000 (GMT) (envelope-from spe@phear.org) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id A439143D45 for ; Wed, 1 Mar 2006 07:40:32 +0000 (GMT) (envelope-from spe@phear.org) Received: from [192.168.0.104] (84-74-232-165.dclient.hispeed.ch [84.74.232.165]) by smtp.hispeed.ch (8.12.6/8.12.6/taifun-1.0) with ESMTP id k217eU2g006286; Wed, 1 Mar 2006 08:40:30 +0100 Message-ID: <44054F99.5080506@phear.org> Date: Wed, 01 Mar 2006 08:39:05 +0100 From: spe User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Andrea Venturoli , freebsd-net@freebsd.org References: <4402CB15.3010404@netfence.it> In-Reply-To: <4402CB15.3010404@netfence.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on smtp-08.tornado.cablecom.ch X-Virus-Status: Clean X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-08.tornado.cablecom.ch 32700; Body=2 Fuz1=2 Fuz2=2 Cc: Subject: Re: freevrrpd and em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 07:40:33 -0000 Hi, FreeVRRPd project is halted and not supported anymore. You can take a look at carp for doing the same job efficiently. If someone want to continue this project, let me know. Regards, Sebastien. -- spe@phear.org Andrea Venturoli wrote: > Hello. > I'm trying to get freevrrpd working on an AMD64 6.0p4 box with an xl0 > and em0 machine. > > Here is the config file: > >> [VRID] >> serverid = 1 >> interface = xl0 >> priority = 254 >> addr = 192.168.0.4/32 >> password = xxxxx >> vridsdep = 3 >> [VRID] >> serverid = 2 >> interface = xl0 >> priority = 255 >> addr = 192.168.0.5/32 >> password = xxxxx >> [VRID] >> serverid = 3 >> interface = em0 >> priority = 254 >> addr = 192.168.101.5/32 >> password = xxxxx >> vridsdep=1 >> monitoredcircuits=no >> [VRID] >> serverid=4 >> interface=em0 >> priority=255 >> addr=192.168.101.6/32 >> password=xxxxx >> monitoredcircuits=no > > This used to work until this box replaced the old machine which had > fxp0 instead of em0; the other machine has fxp0 and fxp1. > > I had to add monitoredcirtuits=no, otherwise em0 would connect and > disconnect (no carrier) at 2 secs intervals (I read this on a post > somewhere). > However this only solves part of the problems, since both boxes will > grab 192.168.101.5 and 192.168.101.6 at the same time. > The same post reports this is fixed in CVS, so I went to the master > web site and followed instructions to do so. However my connection is > refused and I suspect that's a problem with the CVS server side. > > The other side (xl0) works perfectly. > > I cannot switch to carp, since the other machine is running 4.11. > > Any hint? > Has someone been able to download the CVS sources? If so, would it be > too much trouble sending them to me? > Any magic switch to put in conf? > > Remove .diespammer to answer to me directly, please. > > bye & Thanks > av. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 08:52:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DF9416A420 for ; Wed, 1 Mar 2006 08:52:45 +0000 (GMT) (envelope-from piston@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2809343D77 for ; Wed, 1 Mar 2006 08:52:42 +0000 (GMT) (envelope-from piston@otel.net) Received: from devilspot.otel.net ([212.36.8.194]) by mail.otel.net with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEN4a-0002B6-5s for freebsd-net@freebsd.org; Wed, 01 Mar 2006 10:52:40 +0200 Date: Wed, 1 Mar 2006 10:53:32 +0200 From: "S.I" To: freebsd-net@freebsd.org Message-Id: <20060301105332.9f9a0b41.piston@otel.net> Organization: OTEL.net X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ipprecedence ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 08:52:45 -0000 How Can I set ipprecedence flag on FreeBSD? From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 13:08:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E84616A420 for ; Wed, 1 Mar 2006 13:08:59 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FCDD43D68 for ; Wed, 1 Mar 2006 13:08:53 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-121-243.51-151.net24.it [151.51.243.121]) (authenticated bits=128) by parrot.aev.net (8.13.5/8.13.5) with ESMTP id k21DKcnE022204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Mar 2006 14:20:45 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.13.5/8.13.3) with ESMTP id k21D7kJL020760; Wed, 1 Mar 2006 14:07:46 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <44059CD6.8050500@netfence.it> Date: Wed, 01 Mar 2006 14:08:38 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: spe , freebsd-net@freebsd.org References: <4402CB15.3010404@netfence.it> <44054F99.5080506@phear.org> In-Reply-To: <44054F99.5080506@phear.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.53 on 212.31.247.179 Cc: Subject: Re: freevrrpd and em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 13:08:59 -0000 spe wrote: > FreeVRRPd project is halted and not supported anymore. You can take a > look at carp for doing the same job efficiently. Sorry to hear about that :( Unfortunately I cannot switch to carp, since one of the two machines is running 4.11. Or am I wrong and carp can be installed there too? Anyway, since I heard post 0.9.3 source in CVS solves this problem, is it possible to get this sources? Your CVS doesn't seem to be working... bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 13:14:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6530C16A420 for ; Wed, 1 Mar 2006 13:14:33 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E98C243D49 for ; Wed, 1 Mar 2006 13:14:32 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by wproxy.gmail.com with SMTP id 70so126385wra for ; Wed, 01 Mar 2006 05:14:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UvNtrcJObUMYFcs5Cy6N2qt38ob3V5iLa9aG0ggwQFKX1nuwoKQJT0EpkXEnfO83B2/Kkd8r19WOiARsFdt1nn11G/1f25zmPRvT0QIFxvEtefYGkdpmH5W7LI5yeE17DCx6TyiMzG2WC0BlFZSpKLfij5XuCnT4maZJ5V+NvYo= Received: by 10.35.84.12 with SMTP id m12mr545284pyl; Wed, 01 Mar 2006 05:14:28 -0800 (PST) Received: by 10.35.38.9 with HTTP; Wed, 1 Mar 2006 05:14:28 -0800 (PST) Message-ID: <79722fad0603010514w4886d98ft8b0da6393a98f520@mail.gmail.com> Date: Wed, 1 Mar 2006 15:14:28 +0200 From: "Vlad GALU" To: freebsd-net@freebsd.org In-Reply-To: <44059CD6.8050500@netfence.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4402CB15.3010404@netfence.it> <44054F99.5080506@phear.org> <44059CD6.8050500@netfence.it> Subject: Re: freevrrpd and em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 13:14:33 -0000 On 3/1/06, Andrea Venturoli wrote: > spe wrote: > > > FreeVRRPd project is halted and not supported anymore. You can take a > > look at carp for doing the same job efficiently. > > Sorry to hear about that :( > > Unfortunately I cannot switch to carp, since one of the two machines is > running 4.11. Or am I wrong and carp can be installed there too? Try ucarp then (www.ucarp.org). While it's not as flexible as the kernel implementation, it could do your job. > > Anyway, since I heard post 0.9.3 source in CVS solves this problem, is > it possible to get this sources? Your CVS doesn't seem to be working... > > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 15:20:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD38416A42D for ; Wed, 1 Mar 2006 15:20:44 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B55B43E51 for ; Wed, 1 Mar 2006 15:18:51 +0000 (GMT) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu (adsl-ull-121-243.51-151.net24.it [151.51.243.121]) (authenticated bits=128) by parrot.aev.net (8.13.5/8.13.5) with ESMTP id k21FTlww040577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Mar 2006 16:29:54 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.13.5/8.13.3) with ESMTP id k21FGvg9036683; Wed, 1 Mar 2006 16:16:57 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <4405BB1E.80008@netfence.it> Date: Wed, 01 Mar 2006 16:17:50 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5 (X11/20060130) MIME-Version: 1.0 To: Vlad GALU , freebsd-net@freebsd.org References: <4402CB15.3010404@netfence.it> <44054F99.5080506@phear.org> <44059CD6.8050500@netfence.it> <79722fad0603010514w4886d98ft8b0da6393a98f520@mail.gmail.com> In-Reply-To: <79722fad0603010514w4886d98ft8b0da6393a98f520@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.53 on 212.31.247.179 Cc: Subject: Re: freevrrpd and em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 15:20:44 -0000 Vlad GALU wrote: >> Unfortunately I cannot switch to carp, since one of the two machines is >> running 4.11. Or am I wrong and carp can be installed there too? > > Try ucarp then (www.ucarp.org). While it's not as flexible as the > kernel implementation, it could do your job. Thank you very much, I was not aware of this. I'll give it a try. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 17:43:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E84B16A420; Wed, 1 Mar 2006 17:43:19 +0000 (GMT) (envelope-from howells@kde.org) Received: from mail.devrandom.org.uk (host-84-9-223-82.bulldogdsl.com [84.9.223.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB3443D46; Wed, 1 Mar 2006 17:43:18 +0000 (GMT) (envelope-from howells@kde.org) Received: from localhost (localhost [127.0.0.1]) by mail.devrandom.org.uk (Postfix) with ESMTP id BA60BFD066; Wed, 1 Mar 2006 17:43:12 +0000 (GMT) Received: from mail.devrandom.org.uk ([127.0.0.1]) by localhost (mail.devrandom.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09416-02; Wed, 1 Mar 2006 17:43:11 +0000 (GMT) Received: from [192.168.1.177] (unknown [192.168.1.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.devrandom.org.uk (Postfix) with ESMTP id C6388FD06D; Wed, 1 Mar 2006 17:43:09 +0000 (GMT) From: Chris Howells Organization: K Desktop Environment To: Gleb Smirnoff , Jack Vogel , freebsd-net@freebsd.org Date: Wed, 1 Mar 2006 17:42:06 +0000 User-Agent: KMail/1.9.1 References: <63472.192.168.0.1.1140456976.squirrel@webmail.devrandom.org.uk> <57314.192.168.0.1.1140522671.squirrel@webmail.devrandom.org.uk> <20060226103244.GF55275@FreeBSD.org> In-Reply-To: <20060226103244.GF55275@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603011742.07429.howells@kde.org> X-Virus-Scanned: amavisd-new at devrandom.org.uk Cc: Subject: Re: Which motherboards work well with em(4)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 17:43:19 -0000 On Sunday 26 February 2006 10:32, Gleb Smirnoff wrote: > On Tue, Feb 21, 2006 at 11:51:11AM -0000, Chris Howells wrote: > C> Oh yes sorry, should have clarified that. Correct, it hangs on receive, > C> consistently -- never ever on transmit. Though the conditions to cause > it C> to hang on rx are sadly somewhat unpredictable. I haven't seen the > problem C> really since before Christmas until recently when I've seen it > quite a C> lot. But then again I am transferring more data around at the > moment due C> to trying to recover from a hard disk failure in the 6.1-pre > machine. > > Can you please try the following, when the card wedges again: > > sysctl dev.dev.em.0.stats=1 > > Then show us the last part of the dmesg output. Sorry for the delay in replying. I think this is it: em0: link state changed to UP em0: Excessive collisions = 0 em0: Symbol errors = 0 em0: Sequence errors = 0 em0: Defer count = 5622 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive length errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Carrier extension errors = 0 em0: XON Rcvd = 6209 em0: XON Xmtd = 0 em0: XOFF Rcvd = 21561 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 1419602 em0: Good Packets Xmtd = 1631954 em0: Adapter hardware address = 0xc17d9924 em0:CTRL = 0x18f00249 em0:RCTL = 0x8002 PS=(0x8402) em0:tx_int_delay = 66, tx_abs_int_delay = 66 em0:rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset = 0 em0: hw tdh = 0, hw tdt = 0 em0: Num Tx descriptors avail = 256 em0: Tx Descriptors not avail1 = 0 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 I am starting to become convinced that it is the motherboard though, I have tried the card in a Nforce3 (Asus A8n) and Nforce4 (Asus A8n-SLI) board and been unable to reproduce the problelm Thanks. -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 19:33:45 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C45F16A420; Wed, 1 Mar 2006 19:33:45 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A654143D46; Wed, 1 Mar 2006 19:33:44 +0000 (GMT) (envelope-from anders@FreeBSD.org) Received: by totem.fix.no (Postfix, from userid 1000) id 6408A8DB148; Wed, 1 Mar 2006 20:33:42 +0100 (CET) Date: Wed, 1 Mar 2006 20:33:42 +0100 From: Anders Nordby To: freebsd-net@FreeBSD.org, damien@FreeBSD.org Message-ID: <20060301193342.GA11086@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: http://anders.fix.no/pgp/ X-PGP-Key-FingerPrint: 1E0F C53C D8DF 6A8F EAAD 19C5 D12A BC9F 0083 5956 User-Agent: Mutt/1.5.11 Cc: flz@FreeBSD.org Subject: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 19:33:45 -0000 Hi, I'm having great difficulties taking backup of my laptop computer. It's a Fujitsu Siemens Lifebook E8020 system with a Intel PRO/Wireless 2915ABG NIC. I'm connected to a FreeBSD hostap, using WPA2 (CCMP/AES). Updating to 6-STABLE (6.1-PRERELEASE) seems to have improved the stability of the iwi driver quite a bit, but when doing large file transfers (in this case rsyncing all the data from the laptop through SSH), I always and oftenly get: Disconnecting: Corrupted MAC on input. The messages comes from SSH, so it seems to be getting corrupted data. Is anyone looking into that? Is there any fixes or settings that should be tried? How are people's experience with iwi? Am I the only one to have problems with it? Cheers, -- Anders. From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 19:57:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8A8216A422; Wed, 1 Mar 2006 19:57:03 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94A7743D79; Wed, 1 Mar 2006 19:56:56 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k21Jutuj050403; Wed, 1 Mar 2006 11:56:55 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k21Jutj9050402; Wed, 1 Mar 2006 11:56:55 -0800 (PST) (envelope-from rizzo) Date: Wed, 1 Mar 2006 11:56:55 -0800 From: Luigi Rizzo To: Anders Nordby Message-ID: <20060301115655.A50285@xorpc.icir.org> References: <20060301193342.GA11086@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060301193342.GA11086@totem.fix.no>; from anders@freebsd.org on Wed, Mar 01, 2006 at 08:33:42PM +0100 Cc: freebsd-net@freebsd.org, damien@freebsd.org, flz@freebsd.org Subject: Re: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 19:57:03 -0000 On Wed, Mar 01, 2006 at 08:33:42PM +0100, Anders Nordby wrote: > Hi, > > I'm having great difficulties taking backup of my laptop computer. It's > a Fujitsu Siemens Lifebook E8020 system with a Intel PRO/Wireless > 2915ABG NIC. I'm connected to a FreeBSD hostap, using WPA2 (CCMP/AES). > > Updating to 6-STABLE (6.1-PRERELEASE) seems to have improved the > stability of the iwi driver quite a bit, but when doing large file > transfers (in this case rsyncing all the data from the laptop through > SSH), I always and oftenly get: > > Disconnecting: Corrupted MAC on input. > > The messages comes from SSH, so it seems to be getting corrupted data. > Is anyone looking into that? Is there any fixes or settings that should > be tried? How are people's experience with iwi? Am I the only one to > have problems with it? I am using RELENG_6 on my dell latitude x1 and i have been getting ssh's "corrupted data" messages with 'iwi' since i started using the native driver back in september. After the update at the end of january the driver would consistently crash my laptop right after loading the firmware (i suspect some kind of race condition) so i had a hard time for a couple of weeks until i replaced it with the code that Max Laier and Sam Leffler gave me (using the 'firmware' driver from RELENG_7). Since then the driver is solid as a rock, but the "corrupt data" thing keeps happening, especially with bulk data transfers such as scp, although occasionally i get them with http accesses too. curiously interactive ssh is always ok, so i suspect that packet size has an influence on the problem. I had no time to instrument the relevant part of the ssl library to try and figure out if there is a pattern in the error (e.g. zeroed bytes, or a constant packet size, etc.) but yes, overall the native iwi driver does have issues and i am unsure on what is the source (i had firmware 2.3 before feb, and 2.4 now). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 20:52:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E3C916A4E4; Wed, 1 Mar 2006 20:52:20 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3290D43D83; Wed, 1 Mar 2006 20:52:05 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.210.15] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FEYIl46Rc-0007jg; Wed, 01 Mar 2006 21:52:04 +0100 From: Max Laier Organization: FreeBSD To: Luigi Rizzo Date: Wed, 1 Mar 2006 21:50:36 +0100 User-Agent: KMail/1.9.1 References: <20060301193342.GA11086@totem.fix.no> <20060301115655.A50285@xorpc.icir.org> In-Reply-To: <20060301115655.A50285@xorpc.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2009766.qCQR9IS4dk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603012150.44445.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org, Anders Nordby , damien@freebsd.org, flz@freebsd.org Subject: Re: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 20:52:21 -0000 --nextPart2009766.qCQR9IS4dk Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 01 March 2006 20:56, Luigi Rizzo wrote: > On Wed, Mar 01, 2006 at 08:33:42PM +0100, Anders Nordby wrote: > > Hi, > > > > I'm having great difficulties taking backup of my laptop computer. It's > > a Fujitsu Siemens Lifebook E8020 system with a Intel PRO/Wireless > > 2915ABG NIC. I'm connected to a FreeBSD hostap, using WPA2 (CCMP/AES). > > > > Updating to 6-STABLE (6.1-PRERELEASE) seems to have improved the > > stability of the iwi driver quite a bit, but when doing large file > > transfers (in this case rsyncing all the data from the laptop through > > SSH), I always and oftenly get: > > > > Disconnecting: Corrupted MAC on input. > > > > The messages comes from SSH, so it seems to be getting corrupted data. > > Is anyone looking into that? Is there any fixes or settings that should > > be tried? How are people's experience with iwi? Am I the only one to > > have problems with it? > > I am using RELENG_6 on my dell latitude x1 and > i have been getting ssh's "corrupted data" messages with 'iwi' since > i started using the native driver back in september. > After the update at the end of january the driver would consistently > crash my laptop right after loading the firmware (i suspect some kind > of race condition) so i had a hard time for a couple of weeks until > i replaced it with the code that Max Laier and Sam Leffler gave me > (using the 'firmware' driver from RELENG_7). > Since then the driver is solid as a rock, but the "corrupt data" > thing keeps happening, especially with bulk data transfers such as > scp, although occasionally i get them with http accesses too. ahrg, still didn't get to putting out the RELENG_6 version of the driver. = =20 Luigi, can you share your version. Should be easy now since firmware has=20 been MFCed. I'd really like to see people testing this version and let us= =20 know what works and what not. I hope to find some time to do something abo= ut=20 that then. > curiously interactive ssh is always ok, so i suspect that packet size > has an influence on the problem. > I had no time to instrument the relevant part of the ssl library > to try and figure out if there is a pattern in the error (e.g. > zeroed bytes, or a constant packet size, etc.) > > but yes, overall the native iwi driver does have issues and i > am unsure on what is the source (i had firmware 2.3 before feb, > and 2.4 now). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2009766.qCQR9IS4dk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBEBgkkXyyEoT62BG0RAnx2AJ9EUpjQpP7BWR4fk/XRDaIZ2WRZ1QCfYz5N iWhkkgwdWz4OIKnAusk/5jY= =8i64 -----END PGP SIGNATURE----- --nextPart2009766.qCQR9IS4dk-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 1 23:43:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17AF916A420; Wed, 1 Mar 2006 23:43:53 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E22A43D68; Wed, 1 Mar 2006 23:43:44 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k21NhgSa053319; Wed, 1 Mar 2006 15:43:42 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k21Nhg5m053318; Wed, 1 Mar 2006 15:43:42 -0800 (PST) (envelope-from rizzo) Date: Wed, 1 Mar 2006 15:43:42 -0800 From: Luigi Rizzo To: Max Laier Message-ID: <20060301154342.A53213@xorpc.icir.org> References: <20060301193342.GA11086@totem.fix.no> <20060301115655.A50285@xorpc.icir.org> <200603012150.44445.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200603012150.44445.max@love2party.net>; from max@love2party.net on Wed, Mar 01, 2006 at 09:50:36PM +0100 Cc: freebsd-net@freebsd.org, Anders Nordby , damien@freebsd.org, flz@freebsd.org Subject: Re: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:43:53 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 01, 2006 at 09:50:36PM +0100, Max Laier wrote: > On Wednesday 01 March 2006 20:56, Luigi Rizzo wrote: ... > > I am using RELENG_6 on my dell latitude x1 and > > i have been getting ssh's "corrupted data" messages with 'iwi' since > > i started using the native driver back in september. > > After the update at the end of january the driver would consistently > > crash my laptop right after loading the firmware (i suspect some kind > > of race condition) so i had a hard time for a couple of weeks until > > i replaced it with the code that Max Laier and Sam Leffler gave me > > (using the 'firmware' driver from RELENG_7). > > Since then the driver is solid as a rock, but the "corrupt data" > > thing keeps happening, especially with bulk data transfers such as > > scp, although occasionally i get them with http accesses too. > > ahrg, still didn't get to putting out the RELENG_6 version of the driver. > Luigi, can you share your version. Should be easy now since firmware has attached is a patch against RELENG_6 (despite the filename, it's the driver Max and Sam sent me, i did not write anything). It's missing the iwi_fw directory because i am not sure how the license allows redistribution, maybe you or Sam know better ? In any case it basically contains the 2.4 firmware split into various directories, plus some trivial makefiles. Also i think in the MFC of 'firmware' you forgot to patch src/sys/modules/Makefile to attach the module to the build - see the last chunk of the patch ? cheers luigi --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iwi.luigi.diff" Index: dev/iwi/if_iwi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/iwi/if_iwi.c,v retrieving revision 1.8.2.6 diff -u -p -r1.8.2.6 if_iwi.c --- dev/iwi/if_iwi.c 23 Feb 2006 02:06:46 -0000 1.8.2.6 +++ dev/iwi/if_iwi.c 1 Mar 2006 23:23:28 -0000 @@ -46,6 +46,14 @@ __FBSDID("$FreeBSD: src/sys/dev/iwi/if_i #include #include #include +#include +#include +#include +#include +#include +#include +#include +#include #include #include @@ -75,6 +83,7 @@ __FBSDID("$FreeBSD: src/sys/dev/iwi/if_i #include #include +#define IWI_DEBUG #ifdef IWI_DEBUG #define DPRINTF(x) do { if (iwi_debug > 0) printf x; } while (0) #define DPRINTFN(n, x) do { if (iwi_debug >= (n)) printf x; } while (0) @@ -87,6 +96,13 @@ SYSCTL_INT(_debug, OID_AUTO, iwi, CTLFLA MODULE_DEPEND(iwi, pci, 1, 1, 1); MODULE_DEPEND(iwi, wlan, 1, 1, 1); +MODULE_DEPEND(iwi, firmware, 1, 1, 1); + +enum { + IWI_LED_TX, + IWI_LED_RX, + IWI_LED_POLL, +}; struct iwi_ident { uint16_t vendor; @@ -121,16 +137,17 @@ static void iwi_node_free(struct ieee802 static int iwi_media_change(struct ifnet *); static void iwi_media_status(struct ifnet *, struct ifmediareq *); static int iwi_newstate(struct ieee80211com *, enum ieee80211_state, int); +static void iwi_wme_init(struct iwi_softc *); +static void iwi_wme_setparams(void *, int); static int iwi_wme_update(struct ieee80211com *); static uint16_t iwi_read_prom_word(struct iwi_softc *, uint8_t); -static void iwi_fix_channel(struct ieee80211com *, struct mbuf *); static void iwi_frame_intr(struct iwi_softc *, struct iwi_rx_data *, int, struct iwi_frame *); static void iwi_notification_intr(struct iwi_softc *, struct iwi_notif *); static void iwi_rx_intr(struct iwi_softc *); static void iwi_tx_intr(struct iwi_softc *, struct iwi_tx_ring *); static void iwi_intr(void *); -static int iwi_cmd(struct iwi_softc *, uint8_t, void *, uint8_t, int); +static int iwi_cmd(struct iwi_softc *, uint8_t, void *, uint8_t); static void iwi_write_ibssnode(struct iwi_softc *, const struct iwi_node *); static int iwi_tx_start(struct ifnet *, struct mbuf *, struct ieee80211_node *, int); @@ -139,18 +156,28 @@ static void iwi_watchdog(struct ifnet *) static int iwi_ioctl(struct ifnet *, u_long, caddr_t); static void iwi_stop_master(struct iwi_softc *); static int iwi_reset(struct iwi_softc *); -static int iwi_load_ucode(struct iwi_softc *, void *, int); -static int iwi_load_firmware(struct iwi_softc *, void *, int); -static int iwi_cache_firmware(struct iwi_softc *, void *); -static void iwi_free_firmware(struct iwi_softc *); +static int iwi_load_ucode(struct iwi_softc *, struct firmware *); +static int iwi_load_firmware(struct iwi_softc *, struct firmware *); static int iwi_config(struct iwi_softc *); -static int iwi_set_chan(struct iwi_softc *, struct ieee80211_channel *); -static int iwi_scan(struct iwi_softc *); +static int iwi_get_firmware(struct iwi_softc *); +static void iwi_put_firmware(struct iwi_softc *); +static void iwi_scanabort(void *, int); +static void iwi_scandone(void *, int); +static void iwi_scanstart(void *, int); +static void iwi_scanchan(void *, int); static int iwi_auth_and_assoc(struct iwi_softc *); +static int iwi_disassociate(struct iwi_softc *, int quiet); +static void iwi_down(void *, int); static void iwi_init(void *); +static void iwi_init_locked(void *); static void iwi_stop(void *); -static int iwi_sysctl_stats(SYSCTL_HANDLER_ARGS); -static int iwi_sysctl_radio(SYSCTL_HANDLER_ARGS); +static void iwi_restart(void *, int); +static int iwi_getrfkill(struct iwi_softc *); +static void iwi_radio_on(void *, int); +static void iwi_radio_off(void *, int); +static void iwi_sysctlattach(struct iwi_softc *); +static void iwi_led_event(struct iwi_softc *, int); +static void iwi_ledattach(struct iwi_softc *); static int iwi_probe(device_t); static int iwi_attach(device_t); @@ -193,6 +220,20 @@ static const struct ieee80211_rateset iw static const struct ieee80211_rateset iwi_rateset_11g = { 12, { 2, 4, 11, 22, 12, 18, 24, 36, 48, 72, 96, 108 } }; +static __inline uint8_t +MEM_READ_1(struct iwi_softc *sc, uint32_t addr) +{ + CSR_WRITE_4(sc, IWI_CSR_INDIRECT_ADDR, addr); + return CSR_READ_1(sc, IWI_CSR_INDIRECT_DATA); +} + +static __inline uint32_t +MEM_READ_4(struct iwi_softc *sc, uint32_t addr) +{ + CSR_WRITE_4(sc, IWI_CSR_INDIRECT_ADDR, addr); + return CSR_READ_4(sc, IWI_CSR_INDIRECT_DATA); +} + static int iwi_probe(device_t dev) { @@ -227,6 +268,20 @@ iwi_attach(device_t dev) sc->sc_unr = new_unrhdr(0, IWI_MAX_IBSSNODE, &sc->sc_mtx); + sc->sc_tq = taskqueue_create("iwi_taskq", M_NOWAIT, + taskqueue_thread_enqueue, &sc->sc_tq, &sc->sc_tqproc); + kthread_create(taskqueue_thread_loop, &sc->sc_tq, &sc->sc_tqproc, + 0, 0, "%s taskq", device_get_nameunit(dev)); + TASK_INIT(&sc->sc_radiontask, 0, iwi_radio_on, sc); + TASK_INIT(&sc->sc_radiofftask, 0, iwi_radio_off, sc); + TASK_INIT(&sc->sc_scanstarttask, 0, iwi_scanstart, sc); + TASK_INIT(&sc->sc_scanaborttask, 0, iwi_scanabort, sc); + TASK_INIT(&sc->sc_scandonetask, 0, iwi_scandone, sc); + TASK_INIT(&sc->sc_scantask, 0, iwi_scanchan, sc); + TASK_INIT(&sc->sc_setwmetask, 0, iwi_wme_setparams, sc); + TASK_INIT(&sc->sc_downtask, 0, iwi_down, sc); + TASK_INIT(&sc->sc_restarttask, 0, iwi_restart, sc); + if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0) { device_printf(dev, "chip is in D%d power mode " "-- setting to D0\n", pci_get_powerstate(dev)); @@ -303,6 +358,8 @@ iwi_attach(device_t dev) goto fail; } + iwi_wme_init(sc); + ifp = sc->sc_ifp = if_alloc(IFT_ETHER); if (ifp == NULL) { device_printf(dev, "can not if_alloc()\n"); @@ -329,7 +386,7 @@ iwi_attach(device_t dev) ic->ic_caps = IEEE80211_C_IBSS | /* IBSS mode supported */ IEEE80211_C_MONITOR | /* monitor mode supported */ - IEEE80211_C_TXPMGT | /* tx power management */ + IEEE80211_C_PMGT | /* power save supported */ IEEE80211_C_SHPREAMBLE | /* short preamble supported */ IEEE80211_C_WPA | /* 802.11i */ IEEE80211_C_WME; /* 802.11e */ @@ -386,45 +443,19 @@ iwi_attach(device_t dev) ieee80211_media_init(ic, iwi_media_change, iwi_media_status); bpfattach2(ifp, DLT_IEEE802_11_RADIO, - sizeof (struct ieee80211_frame) + 64, &sc->sc_drvbpf); + sizeof (struct ieee80211_frame) + sizeof (sc->sc_txtap), + &sc->sc_drvbpf); - sc->sc_rxtap_len = sizeof sc->sc_rxtapu; + sc->sc_rxtap_len = sizeof sc->sc_rxtap; sc->sc_rxtap.wr_ihdr.it_len = htole16(sc->sc_rxtap_len); sc->sc_rxtap.wr_ihdr.it_present = htole32(IWI_RX_RADIOTAP_PRESENT); - sc->sc_txtap_len = sizeof sc->sc_txtapu; + sc->sc_txtap_len = sizeof sc->sc_txtap; sc->sc_txtap.wt_ihdr.it_len = htole16(sc->sc_txtap_len); sc->sc_txtap.wt_ihdr.it_present = htole32(IWI_TX_RADIOTAP_PRESENT); - /* - * Add a few sysctl knobs. - */ - sc->dwelltime = 100; - sc->bluetooth = 1; - sc->antenna = 0; - - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "radio", - CTLTYPE_INT | CTLFLAG_RD, sc, 0, iwi_sysctl_radio, "I", - "radio transmitter switch state (0=off, 1=on)"); - - SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "stats", - CTLTYPE_OPAQUE | CTLFLAG_RD, sc, 0, iwi_sysctl_stats, "S", - "statistics"); - - SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "dwell", - CTLFLAG_RW, &sc->dwelltime, 0, - "channel dwell time (ms) for AP/station scanning"); - - SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "bluetooth", - CTLFLAG_RW, &sc->bluetooth, 0, "bluetooth coexistence"); - - SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), - SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, "antenna", - CTLFLAG_RW, &sc->antenna, 0, "antenna (0=auto)"); + iwi_sysctlattach(sc); + iwi_ledattach(sc); /* * Hook our interrupt after all initialization is complete. @@ -453,8 +484,7 @@ iwi_detach(device_t dev) struct ifnet *ifp = ic->ic_ifp; iwi_stop(sc); - - iwi_free_firmware(sc); + iwi_put_firmware(sc); if (ifp != NULL) { bpfdetach(ifp); @@ -479,6 +509,8 @@ iwi_detach(device_t dev) if (ifp != NULL) if_free(ifp); + taskqueue_free(sc->sc_tq); + if (sc->sc_unr != NULL) delete_unrhdr(sc->sc_unr); @@ -789,6 +821,7 @@ iwi_shutdown(device_t dev) struct iwi_softc *sc = device_get_softc(dev); iwi_stop(sc); + iwi_put_firmware(sc); /* ??? XXX */ return 0; } @@ -866,7 +899,7 @@ iwi_media_change(struct ifnet *ifp) } if ((ifp->if_flags & IFF_UP) && (ifp->if_drv_flags & IFF_DRV_RUNNING)) - iwi_init(sc); + iwi_init_locked(sc); IWI_UNLOCK(sc); @@ -941,20 +974,25 @@ iwi_newstate(struct ieee80211com *ic, en { struct ifnet *ifp = ic->ic_ifp; struct iwi_softc *sc = ifp->if_softc; - enum ieee80211_state ostate; - uint32_t tmp; - ostate = ic->ic_state; + DPRINTF(("%s: %s -> %s flags 0x%x\n", __func__, + ieee80211_state_name[ic->ic_state], + ieee80211_state_name[nstate], sc->flags)); switch (nstate) { case IEEE80211_S_SCAN: - if (sc->flags & IWI_FLAG_SCANNING) + if (ic->ic_state == IEEE80211_S_RUN) { + /* + * Beacon miss, send disassoc and wait for a reply + * from the card; we'll start a scan then. + */ + taskqueue_enqueue(sc->sc_tq, &sc->sc_downtask); break; - - ieee80211_node_table_reset(&ic->ic_scan); - ic->ic_flags |= IEEE80211_F_SCAN | IEEE80211_F_ASCAN; - sc->flags |= IWI_FLAG_SCANNING; - iwi_scan(sc); + } + if ((sc->flags & IWI_FLAG_SCANNING) == 0) { + sc->flags |= IWI_FLAG_SCANNING; + taskqueue_enqueue(sc->sc_tq, &sc->sc_scanstarttask); + } break; case IEEE80211_S_AUTH: @@ -963,13 +1001,9 @@ iwi_newstate(struct ieee80211com *ic, en case IEEE80211_S_RUN: if (ic->ic_opmode == IEEE80211_M_IBSS) - iwi_auth_and_assoc(sc); + ieee80211_new_state(ic, IEEE80211_S_AUTH, -1); else if (ic->ic_opmode == IEEE80211_M_MONITOR) - iwi_set_chan(sc, ic->ic_ibss_chan); - - /* assoc led on */ - tmp = MEM_READ_4(sc, IWI_MEM_EVENT_CTL) & IWI_LED_MASK; - MEM_WRITE_4(sc, IWI_MEM_EVENT_CTL, tmp | IWI_LED_ASSOC); + taskqueue_enqueue(sc->sc_tq, &sc->sc_scantask); return sc->sc_newstate(ic, nstate, IEEE80211_FC0_SUBTYPE_ASSOC_RESP); @@ -978,19 +1012,17 @@ iwi_newstate(struct ieee80211com *ic, en break; case IEEE80211_S_INIT: - sc->flags &= ~IWI_FLAG_SCANNING; - - if (ostate != IEEE80211_S_RUN) - break; - - /* assoc led off */ - tmp = MEM_READ_4(sc, IWI_MEM_EVENT_CTL) & IWI_LED_MASK; - MEM_WRITE_4(sc, IWI_MEM_EVENT_CTL, tmp & ~IWI_LED_ASSOC); + /* + * NB: don't try to do this if iwi_stop_master has + * shutdown the firmware and disabled interrupts. + */ + if (ic->ic_state == IEEE80211_S_RUN && + (sc->flags & IWI_FLAG_FW_INITED)) + taskqueue_enqueue(sc->sc_tq, &sc->sc_downtask); break; } ic->ic_state = nstate; - return 0; } @@ -1012,54 +1044,94 @@ static const struct wmeParams iwi_wme_of { 0, 2, 3, 4, 94 }, /* WME_AC_VI */ { 0, 2, 2, 3, 47 } /* WME_AC_VO */ }; - -static int -iwi_wme_update(struct ieee80211com *ic) -{ #define IWI_EXP2(v) htole16((1 << (v)) - 1) #define IWI_USEC(v) htole16(IEEE80211_TXOP_TO_US(v)) - struct iwi_softc *sc = ic->ic_ifp->if_softc; - struct iwi_wme_params wme[3]; + +static void +iwi_wme_init(struct iwi_softc *sc) +{ const struct wmeParams *wmep; int ac; - /* - * We shall not override firmware default WME values if WME is not - * actually enabled. - */ - if (!(ic->ic_flags & IEEE80211_F_WME)) - return 0; - + memset(sc->wme, 0, sizeof sc->wme); for (ac = 0; ac < WME_NUM_AC; ac++) { - /* set WME values for current operating mode */ - wmep = &ic->ic_wme.wme_chanParams.cap_wmeParams[ac]; - wme[0].aifsn[ac] = wmep->wmep_aifsn; - wme[0].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); - wme[0].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); - wme[0].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); - wme[0].acm[ac] = wmep->wmep_acm; - /* set WME values for CCK modulation */ wmep = &iwi_wme_cck_params[ac]; - wme[1].aifsn[ac] = wmep->wmep_aifsn; - wme[1].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); - wme[1].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); - wme[1].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); - wme[1].acm[ac] = wmep->wmep_acm; + sc->wme[1].aifsn[ac] = wmep->wmep_aifsn; + sc->wme[1].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); + sc->wme[1].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); + sc->wme[1].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); + sc->wme[1].acm[ac] = wmep->wmep_acm; /* set WME values for OFDM modulation */ wmep = &iwi_wme_ofdm_params[ac]; - wme[2].aifsn[ac] = wmep->wmep_aifsn; - wme[2].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); - wme[2].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); - wme[2].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); - wme[2].acm[ac] = wmep->wmep_acm; + sc->wme[2].aifsn[ac] = wmep->wmep_aifsn; + sc->wme[2].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); + sc->wme[2].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); + sc->wme[2].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); + sc->wme[2].acm[ac] = wmep->wmep_acm; + } +} + +static int +iwi_wme_setparams_locked(struct iwi_softc *sc) +{ + struct ieee80211com *ic = &sc->sc_ic; + const struct wmeParams *wmep; + int ac; + + for (ac = 0; ac < WME_NUM_AC; ac++) { + /* set WME values for current operating mode */ + wmep = &ic->ic_wme.wme_chanParams.cap_wmeParams[ac]; + sc->wme[0].aifsn[ac] = wmep->wmep_aifsn; + sc->wme[0].cwmin[ac] = IWI_EXP2(wmep->wmep_logcwmin); + sc->wme[0].cwmax[ac] = IWI_EXP2(wmep->wmep_logcwmax); + sc->wme[0].burst[ac] = IWI_USEC(wmep->wmep_txopLimit); + sc->wme[0].acm[ac] = wmep->wmep_acm; } DPRINTF(("Setting WME parameters\n")); - return iwi_cmd(sc, IWI_CMD_SET_WME_PARAMS, wme, sizeof wme, 1); + return iwi_cmd(sc, IWI_CMD_SET_WME_PARAMS, sc->wme, sizeof sc->wme); +} + +static void +iwi_wme_setparams(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + + IWI_LOCK(sc); + (void) iwi_wme_setparams_locked(sc); + IWI_UNLOCK(sc); +} #undef IWI_USEC #undef IWI_EXP2 + +static int +iwi_wme_update(struct ieee80211com *ic) +{ + struct iwi_softc *sc = ic->ic_ifp->if_softc; + taskqueue_enqueue(sc->sc_tq, &sc->sc_setwmetask); + return 0; +} + +static int +iwi_wme_setie(struct iwi_softc *sc) +{ + struct ieee80211_wme_info wme; + + memset(&wme, 0, sizeof wme); + wme.wme_id = IEEE80211_ELEMID_VENDOR; + wme.wme_len = sizeof (struct ieee80211_wme_info) - 2; + wme.wme_oui[0] = 0x00; + wme.wme_oui[1] = 0x50; + wme.wme_oui[2] = 0xf2; + wme.wme_type = WME_OUI_TYPE; + wme.wme_subtype = WME_INFO_OUI_SUBTYPE; + wme.wme_version = WME_VERSION; + wme.wme_info = 0; + + DPRINTF(("Setting WME IE (len=%u)\n", wme.wme_len)); + return iwi_cmd(sc, IWI_CMD_SET_WMEIE, &wme, sizeof wme); } /* @@ -1117,41 +1189,18 @@ iwi_read_prom_word(struct iwi_softc *sc, return val; } -/* - * XXX: Hack to set the current channel to the value advertised in beacons or - * probe responses. Only used during AP detection. - */ static void -iwi_fix_channel(struct ieee80211com *ic, struct mbuf *m) +iwi_setcurchan(struct iwi_softc *sc, int chan) { - struct ieee80211_frame *wh; - uint8_t subtype; - uint8_t *frm, *efrm; - - wh = mtod(m, struct ieee80211_frame *); - - if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) != IEEE80211_FC0_TYPE_MGT) - return; - - subtype = wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK; - - if (subtype != IEEE80211_FC0_SUBTYPE_BEACON && - subtype != IEEE80211_FC0_SUBTYPE_PROBE_RESP) - return; - - frm = (uint8_t *)(wh + 1); - efrm = mtod(m, uint8_t *) + m->m_len; + struct ieee80211com *ic = &sc->sc_ic; - frm += 12; /* skip tstamp, bintval and capinfo fields */ - while (frm < efrm) { - if (*frm == IEEE80211_ELEMID_DSPARMS) -#if IEEE80211_CHAN_MAX < 255 - if (frm[2] <= IEEE80211_CHAN_MAX) -#endif - ic->ic_curchan = &ic->ic_channels[frm[2]]; + ic->ic_curchan = &ic->ic_channels[chan]; + sc->curchan = chan; - frm += frm[1] + 2; - } + sc->sc_rxtap.wr_chan_freq = sc->sc_txtap.wt_chan_freq = + htole16(ic->ic_curchan->ic_freq); + sc->sc_rxtap.wr_chan_flags = sc->sc_txtap.wt_chan_flags = + htole16(ic->ic_curchan->ic_flags); } static void @@ -1161,16 +1210,18 @@ iwi_frame_intr(struct iwi_softc *sc, str struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; struct mbuf *mnew, *m; - struct ieee80211_frame *wh; struct ieee80211_node *ni; - int error; + int type, error; - DPRINTFN(5, ("received frame len=%u chan=%u rssi=%u\n", - le16toh(frame->len), frame->chan, frame->rssi_dbm)); + DPRINTFN(5, ("received frame len=%u chan=%u rssi=%u rssi_dbm=%u\n", + le16toh(frame->len), frame->chan, frame->rssi, frame->rssi_dbm)); if (le16toh(frame->len) < sizeof (struct ieee80211_frame)) return; + if (frame->chan != sc->curchan) + iwi_setcurchan(sc, frame->chan); + /* * Try to allocate a new mbuf for this ring element and load it before * processing the current mbuf. If the ring element cannot be loaded, @@ -1219,32 +1270,114 @@ iwi_frame_intr(struct iwi_softc *sc, str m_adj(m, sizeof (struct iwi_hdr) + sizeof (struct iwi_frame)); - if (ic->ic_state == IEEE80211_S_SCAN) - iwi_fix_channel(ic, m); - if (sc->sc_drvbpf != NULL) { struct iwi_rx_radiotap_header *tap = &sc->sc_rxtap; tap->wr_flags = 0; - tap->wr_rate = frame->rate; - tap->wr_chan_freq = - htole16(ic->ic_channels[frame->chan].ic_freq); - tap->wr_chan_flags = - htole16(ic->ic_channels[frame->chan].ic_flags); + tap->wr_rate = frame->rate; /* XXX map to ieee rate */ tap->wr_antsignal = frame->signal; tap->wr_antenna = frame->antenna; bpf_mtap2(sc->sc_drvbpf, tap, sc->sc_rxtap_len, m); } - wh = mtod(m, struct ieee80211_frame *); - ni = ieee80211_find_rxnode(ic, (struct ieee80211_frame_min *)wh); + ni = ieee80211_find_rxnode(ic, mtod(m, struct ieee80211_frame_min *)); /* send the frame to the 802.11 layer */ - ieee80211_input(ic, m, ni, frame->rssi_dbm, 0); + type = ieee80211_input(ic, m, ni, frame->rssi_dbm, 0); /* node is no longer needed */ ieee80211_free_node(ni); + + if (sc->sc_softled) { + /* + * Blink for any data frame. Otherwise do a + * heartbeat-style blink when idle. The latter + * is mainly for station mode where we depend on + * periodic beacon frames to trigger the poll event. + */ + if (type == IEEE80211_FC0_TYPE_DATA) { + sc->sc_rxrate = frame->rate; + iwi_led_event(sc, IWI_LED_RX); + } else if (ticks - sc->sc_ledevent >= sc->sc_ledidle) + iwi_led_event(sc, IWI_LED_POLL); + } +} + +/* unaligned little endian access */ +#define LE_READ_2(p) \ + ((u_int16_t) \ + ((((const u_int8_t *)(p))[0] ) | \ + (((const u_int8_t *)(p))[1] << 8))) +#define LE_READ_4(p) \ + ((u_int32_t) \ + ((((const u_int8_t *)(p))[0] ) | \ + (((const u_int8_t *)(p))[1] << 8) | \ + (((const u_int8_t *)(p))[2] << 16) | \ + (((const u_int8_t *)(p))[3] << 24))) + +#define IEEE80211_VERIFY_LENGTH(_len, _minlen) do { \ + if ((_len) < (_minlen)) { \ + return; \ + } \ +} while (0) + +static int __inline +iswmeoui(const u_int8_t *frm) +{ + return frm[1] > 3 && LE_READ_4(frm+2) == ((WME_OUI_TYPE<<24)|WME_OUI); +} + +/* + * Check for an association response frame to see if QoS + * has been negotiated. We parse just enough to figure + * out if we're supposed to use QoS. The proper solution + * is to pass the frame up so ieee80211_input can do the + * work but that's made hard by how things currently are + * done in the driver. + */ +static void +iwi_checkforqos(struct iwi_softc *sc, const struct ieee80211_frame *wh, int len) +{ +#define SUBTYPE(wh) ((wh)->i_fc[0] & IEEE80211_FC0_SUBTYPE_MASK) + const uint8_t *frm, *efrm, *wme; + struct ieee80211_node *ni; + + /* NB: +8 for capinfo, status, associd, and first ie */ + if (!(sizeof(*wh)+8 < len && len < IEEE80211_MAX_LEN) || + SUBTYPE(wh) != IEEE80211_FC0_SUBTYPE_ASSOC_RESP) + return; + /* + * asresp frame format + * [2] capability information + * [2] status + * [2] association ID + * [tlv] supported rates + * [tlv] extended supported rates + * [tlv] WME + */ + frm = (const uint8_t *)&wh[1]; + efrm = ((const uint8_t *) wh) + len; + frm += 6; + + wme = NULL; + while (frm < efrm) { + IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]); + switch (*frm) { + case IEEE80211_ELEMID_VENDOR: + if (iswmeoui(frm)) + wme = frm; + break; + } + frm += frm[1] + 2; + } + + ni = sc->sc_ic.ic_bss; + if (wme != NULL) + ni->ni_flags |= IEEE80211_NODE_QOS; + else + ni->ni_flags &= ~IEEE80211_NODE_QOS; +#undef SUBTYPE } static void @@ -1255,12 +1388,28 @@ iwi_notification_intr(struct iwi_softc * struct iwi_notif_scan_complete *scan; struct iwi_notif_authentication *auth; struct iwi_notif_association *assoc; + struct iwi_notif_beacon_state *beacon; switch (notif->type) { case IWI_NOTIF_TYPE_SCAN_CHANNEL: chan = (struct iwi_notif_scan_channel *)(notif + 1); - DPRINTFN(2, ("Scanning channel (%u)\n", chan->nchan)); + DPRINTFN(3, ("Scan of channel %u complete (%u)\n", + ic->ic_channels[chan->nchan].ic_freq, chan->nchan)); + + /* + * Monitor mode works by doing a passive scan to set + * the channel and enable rx. Because we don't want + * to abort a scan lest the firmware crash we scan + * for a short period of time and automatically restart + * the scan when notified the sweep has completed. + * Note that it is unreliable to wait for the scan + * complete notification; this seems to frequently be + * lost so instead use the per-channel notification to + * kick off a new scan. + */ + if (ic->ic_opmode == IEEE80211_M_MONITOR) + taskqueue_enqueue(sc->sc_tq, &sc->sc_scantask); break; case IWI_NOTIF_TYPE_SCAN_COMPLETE: @@ -1269,26 +1418,33 @@ iwi_notification_intr(struct iwi_softc * DPRINTFN(2, ("Scan completed (%u, %u)\n", scan->nchan, scan->status)); - /* monitor mode uses scan to set the channel ... */ + sc->sc_scan_timer = 0; + + /* see above for monitor mode */ if (ic->ic_opmode != IEEE80211_M_MONITOR) { sc->flags &= ~IWI_FLAG_SCANNING; - ieee80211_end_scan(ic); - } else - iwi_set_chan(sc, ic->ic_ibss_chan); + taskqueue_enqueue(sc->sc_tq, &sc->sc_scandonetask); + } break; case IWI_NOTIF_TYPE_AUTHENTICATION: auth = (struct iwi_notif_authentication *)(notif + 1); - DPRINTFN(2, ("Authentication (%u)\n", auth->state)); - switch (auth->state) { - case IWI_AUTHENTICATED: + case IWI_AUTH_SUCCESS: + DPRINTFN(2, ("Authentication succeeeded\n")); ieee80211_node_authorize(ic->ic_bss); ieee80211_new_state(ic, IEEE80211_S_ASSOC, -1); break; - case IWI_DEAUTHENTICATED: + case IWI_AUTH_FAIL: + DPRINTFN(2, ("Authentication failed\n")); + sc->flags &= ~IWI_FLAG_ASSOCIATED; + /* XXX */ + break; + + case IWI_AUTH_SENT_1: + case IWI_AUTH_RECV_2: break; default: @@ -1300,20 +1456,24 @@ iwi_notification_intr(struct iwi_softc * case IWI_NOTIF_TYPE_ASSOCIATION: assoc = (struct iwi_notif_association *)(notif + 1); - DPRINTFN(2, ("Association (%u, %u)\n", assoc->state, - assoc->status)); - switch (assoc->state) { - case IWI_AUTHENTICATED: + case IWI_AUTH_SUCCESS: /* re-association, do nothing */ break; - case IWI_ASSOCIATED: + case IWI_ASSOC_SUCCESS: + DPRINTFN(2, ("Association succeeded\n")); + sc->flags |= IWI_FLAG_ASSOCIATED; + iwi_checkforqos(sc, + (const struct ieee80211_frame *)(assoc+1), + le16toh(notif->len) - sizeof(*assoc)); ieee80211_new_state(ic, IEEE80211_S_RUN, -1); break; - case IWI_DEASSOCIATED: - ieee80211_begin_scan(ic, 1); + case IWI_ASSOC_FAIL: + DPRINTFN(2, ("Association failed\n")); + sc->flags &= ~IWI_FLAG_ASSOCIATED; + ieee80211_new_state(ic, IEEE80211_S_SCAN, -1); break; default: @@ -1322,8 +1482,49 @@ iwi_notification_intr(struct iwi_softc * } break; - default: + case IWI_NOTIF_TYPE_BEACON: + /* XXX check struct length */ + beacon = (struct iwi_notif_beacon_state *)(notif + 1); + + DPRINTFN(5, ("Beacon state (%u, %u)\n", + beacon->state, le32toh(beacon->number))); + + if (beacon->state == IWI_BEACON_MISS) { +#if 0 + if (sc->flags & IWI_FLAG_SCANNING) { + /* XXX terminate scan, linux driver + says fw can get stuck */ + /* XXX should be handled in iwi_newstate */ + taskqueue_enqueue(sc->sc_tq, + &sc->sc_scanaborttask); + } +#endif + /* + * The firmware notifies us of every beacon miss + * so we need to track the count against the + * configured threshold before notifying the + * 802.11 layer. + * XXX try to roam, drop assoc only on much higher count + */ + if (le32toh(beacon->number) >= ic->ic_bmissthreshold) { + DPRINTF(("Beacon miss: %u >= %u\n", + le32toh(beacon->number), + ic->ic_bmissthreshold)); + ieee80211_beacon_miss(ic); + } + } + break; + + case IWI_NOTIF_TYPE_CALIBRATION: + case IWI_NOTIF_TYPE_NOISE: + case IWI_NOTIF_TYPE_LINK_QUALITY: DPRINTFN(5, ("Notification (%u)\n", notif->type)); + break; + + default: + device_printf(sc->sc_dev, + "unknown notification type %u flags 0x%x len %u\n", + notif->type, notif->flags, le16toh(notif->len)); } } @@ -1401,6 +1602,10 @@ iwi_tx_intr(struct iwi_softc *sc, struct sc->sc_tx_timer = 0; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + + if (sc->sc_softled) + iwi_led_event(sc, IWI_LED_TX); + iwi_start(ifp); } @@ -1417,13 +1622,12 @@ iwi_intr(void *arg) return; } - /* disable interrupts */ - CSR_WRITE_4(sc, IWI_CSR_INTR_MASK, 0); + /* acknowledge interrupts */ + CSR_WRITE_4(sc, IWI_CSR_INTR, r); - if (r & (IWI_INTR_FATAL_ERROR | IWI_INTR_PARITY_ERROR)) { - device_printf(sc->sc_dev, "fatal error\n"); - sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP; - iwi_stop(sc); + if (r & IWI_INTR_FATAL_ERROR) { + device_printf(sc->sc_dev, "firmware error\n"); + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); } if (r & IWI_INTR_FW_INITED) { @@ -1431,14 +1635,13 @@ iwi_intr(void *arg) wakeup(sc); } - if (r & IWI_INTR_RADIO_OFF) { - DPRINTF(("radio transmitter turned off\n")); - sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP; - iwi_stop(sc); - } + if (r & IWI_INTR_RADIO_OFF) + taskqueue_enqueue(sc->sc_tq, &sc->sc_radiofftask); - if (r & IWI_INTR_CMD_DONE) + if (r & IWI_INTR_CMD_DONE) { + sc->flags &= ~IWI_FLAG_BUSY; wakeup(sc); + } if (r & IWI_INTR_TX1_DONE) iwi_tx_intr(sc, &sc->txq[0]); @@ -1455,20 +1658,26 @@ iwi_intr(void *arg) if (r & IWI_INTR_RX_DONE) iwi_rx_intr(sc); - /* acknowledge interrupts */ - CSR_WRITE_4(sc, IWI_CSR_INTR, r); - - /* re-enable interrupts */ - CSR_WRITE_4(sc, IWI_CSR_INTR_MASK, IWI_INTR_MASK); + if (r & IWI_INTR_PARITY_ERROR) { + /* XXX rate-limit */ + device_printf(sc->sc_dev, "parity error\n"); + } IWI_UNLOCK(sc); } static int -iwi_cmd(struct iwi_softc *sc, uint8_t type, void *data, uint8_t len, int async) +iwi_cmd(struct iwi_softc *sc, uint8_t type, void *data, uint8_t len) { struct iwi_cmd_desc *desc; + if (sc->flags & IWI_FLAG_BUSY) { + device_printf(sc->sc_dev, "%s: cmd 0x%x not sent, busy\n", + __func__, type); + return EAGAIN; + } + sc->flags |= IWI_FLAG_BUSY; + desc = &sc->cmdq.desc[sc->cmdq.cur]; desc->hdr.type = IWI_HDR_TYPE_COMMAND; @@ -1486,7 +1695,7 @@ iwi_cmd(struct iwi_softc *sc, uint8_t ty sc->cmdq.cur = (sc->cmdq.cur + 1) % IWI_CMD_RING_COUNT; CSR_WRITE_4(sc, IWI_CSR_CMD_WIDX, sc->cmdq.cur); - return async ? 0 : msleep(sc, &sc->sc_mtx, 0, "iwicmd", hz); + return msleep(sc, &sc->sc_mtx, 0, "iwicmd", hz); } static void @@ -1510,7 +1719,7 @@ iwi_tx_start(struct ifnet *ifp, struct m struct iwi_softc *sc = ifp->if_softc; struct ieee80211com *ic = &sc->sc_ic; struct iwi_node *in = (struct iwi_node *)ni; - struct ieee80211_frame *wh; + const struct ieee80211_frame *wh; struct ieee80211_key *k; const struct chanAccParams *cap; struct iwi_tx_ring *txq = &sc->txq[ac]; @@ -1518,16 +1727,24 @@ iwi_tx_start(struct ifnet *ifp, struct m struct iwi_tx_desc *desc; struct mbuf *mnew; bus_dma_segment_t segs[IWI_MAX_NSEG]; - int error, nsegs, hdrlen, i, noack = 0; + int error, nsegs, hdrlen, i; + int flags, xflags; - wh = mtod(m0, struct ieee80211_frame *); + wh = mtod(m0, const struct ieee80211_frame *); + /* NB: only data frames use this path */ + hdrlen = ieee80211_hdrsize(wh); + flags = xflags = 0; - if (wh->i_fc[0] & IEEE80211_FC0_SUBTYPE_QOS) { - hdrlen = sizeof (struct ieee80211_qosframe); + if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) + flags |= IWI_DATA_FLAG_NEED_ACK; + if (ic->ic_flags & IEEE80211_F_SHPREAMBLE) + flags |= IWI_DATA_FLAG_SHPREAMBLE; + if (IEEE80211_QOS_HAS_SEQ(wh)) { + xflags |= IWI_DATA_XFLAG_QOS; cap = &ic->ic_wme.wme_chanParams; - noack = cap->cap_wmeParams[ac].wmep_noackPolicy; - } else - hdrlen = sizeof (struct ieee80211_frame); + if (!cap->cap_wmeParams[ac].wmep_noackPolicy) + flags &= ~IWI_DATA_FLAG_NEED_ACK; + } /* * This is only used in IBSS mode where the firmware expect an index @@ -1559,8 +1776,6 @@ iwi_tx_start(struct ifnet *ifp, struct m struct iwi_tx_radiotap_header *tap = &sc->sc_txtap; tap->wt_flags = 0; - tap->wt_chan_freq = htole16(ic->ic_ibss_chan->ic_freq); - tap->wt_chan_flags = htole16(ic->ic_ibss_chan->ic_flags); bpf_mtap2(sc->sc_drvbpf, tap, sc->sc_txtap_len, m0); } @@ -1609,26 +1824,16 @@ iwi_tx_start(struct ifnet *ifp, struct m (ic->ic_opmode == IEEE80211_M_IBSS) ? in->in_station : 0; desc->cmd = IWI_DATA_CMD_TX; desc->len = htole16(m0->m_pkthdr.len); - desc->flags = 0; - desc->xflags = 0; - - if (!noack && !IEEE80211_IS_MULTICAST(desc->wh.i_addr1)) - desc->flags |= IWI_DATA_FLAG_NEED_ACK; + desc->flags = flags; + desc->xflags = xflags; #if 0 - if (ic->ic_flags & IEEE80211_F_PRIVACY) { - desc->wh.i_fc[1] |= IEEE80211_FC1_WEP; - desc->weptxkey = ic->ic_crypto.cs_def_txkey; - } else + if (ic->ic_flags & IEEE80211_F_PRIVACY) + desc->wep_txkey = ic->ic_crypto.cs_def_txkey; + else #endif desc->flags |= IWI_DATA_FLAG_NO_WEP; - if (ic->ic_flags & IEEE80211_F_SHPREAMBLE) - desc->flags |= IWI_DATA_FLAG_SHPREAMBLE; - - if (desc->wh.i_fc[0] & IEEE80211_FC0_SUBTYPE_QOS) - desc->xflags |= IWI_DATA_XFLAG_QOS; - desc->nseg = htole32(nsegs); for (i = 0; i < nsegs; i++) { desc->seg_addr[i] = htole32(segs[i].ds_addr); @@ -1666,48 +1871,59 @@ iwi_start(struct ifnet *ifp) } for (;;) { - IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); - if (m0 == NULL) - break; - - if (m0->m_len < sizeof (struct ether_header) && - (m0 = m_pullup(m0, sizeof (struct ether_header))) == NULL) { - ifp->if_oerrors++; - continue; - } - eh = mtod(m0, struct ether_header *); - ni = ieee80211_find_txnode(ic, eh->ether_dhost); - if (ni == NULL) { - m_freem(m0); - ifp->if_oerrors++; - continue; - } + IF_DEQUEUE(&ic->ic_mgtq, m0); + if (m0 == NULL) { + IFQ_DRV_DEQUEUE(&ifp->if_snd, m0); + if (m0 == NULL) + break; + + if (m0->m_len < sizeof (struct ether_header) && + (m0 = m_pullup(m0, sizeof (struct ether_header))) == NULL) { + ifp->if_oerrors++; + continue; + } + eh = mtod(m0, struct ether_header *); + ni = ieee80211_find_txnode(ic, eh->ether_dhost); + if (ni == NULL) { + m_freem(m0); + ifp->if_oerrors++; + continue; + } - /* classify mbuf so we can find which tx ring to use */ - if (ieee80211_classify(ic, m0, ni) != 0) { - m_freem(m0); - ieee80211_free_node(ni); - ifp->if_oerrors++; - continue; - } + /* classify mbuf so we can find which tx ring to use */ + if (ieee80211_classify(ic, m0, ni) != 0) { + m_freem(m0); + ieee80211_free_node(ni); + ifp->if_oerrors++; + continue; + } - /* no QoS encapsulation for EAPOL frames */ - ac = (eh->ether_type != htons(ETHERTYPE_PAE)) ? - M_WME_GETAC(m0) : WME_AC_BE; - - if (sc->txq[ac].queued > IWI_TX_RING_COUNT - 8) { - /* there is no place left in this ring */ - IFQ_DRV_PREPEND(&ifp->if_snd, m0); - ifp->if_drv_flags |= IFF_DRV_OACTIVE; - break; - } + /* XXX does not belong here */ + /* no QoS encapsulation for EAPOL frames */ + ac = (eh->ether_type != htons(ETHERTYPE_PAE)) ? + M_WME_GETAC(m0) : WME_AC_BE; + + if (sc->txq[ac].queued > IWI_TX_RING_COUNT - 8) { + /* there is no place left in this ring */ + IFQ_DRV_PREPEND(&ifp->if_snd, m0); + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + break; + } - BPF_MTAP(ifp, m0); + BPF_MTAP(ifp, m0); - m0 = ieee80211_encap(ic, m0, ni); - if (m0 == NULL) { + m0 = ieee80211_encap(ic, m0, ni); + if (m0 == NULL) { + ieee80211_free_node(ni); + ifp->if_oerrors++; + continue; + } + } else { + ni = (struct ieee80211_node *) m0->m_pkthdr.rcvif; + m0->m_pkthdr.rcvif = NULL; + /* XXX no way to send mgt frames (yet), discard */ + m_freem(m0); ieee80211_free_node(ni); - ifp->if_oerrors++; continue; } @@ -1735,19 +1951,38 @@ iwi_watchdog(struct ifnet *ifp) IWI_LOCK(sc); - ifp->if_timer = 0; - if (sc->sc_tx_timer > 0) { if (--sc->sc_tx_timer == 0) { if_printf(ifp, "device timeout\n"); ifp->if_oerrors++; - ifp->if_flags &= ~IFF_UP; - iwi_stop(sc); - IWI_UNLOCK(sc); - return; + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); + } + } + if (sc->sc_rfkill_timer > 0) { + if (--sc->sc_rfkill_timer == 0) { + /* + * Check for a change in rfkill state. We get an + * interrupt when a radio is disabled but not when + * it is enabled so we must poll for the latter. + */ + if (!iwi_getrfkill(sc)) + taskqueue_enqueue(sc->sc_tq, &sc->sc_radiontask); + else + sc->sc_rfkill_timer = 2; + } + } + if (sc->sc_scan_timer > 0) { + if (--sc->sc_scan_timer == 0) { + if (sc->flags & IWI_FLAG_SCANNING) { + if_printf(ifp, "scan stuck\n"); + taskqueue_enqueue(sc->sc_tq, &sc->sc_restarttask); + } } - ifp->if_timer = 1; } + if (sc->sc_tx_timer || sc->sc_rfkill_timer || sc->sc_scan_timer) + ifp->if_timer = 1; + else + ifp->if_timer = 0; ieee80211_watchdog(ic); @@ -1759,7 +1994,6 @@ iwi_ioctl(struct ifnet *ifp, u_long cmd, { struct iwi_softc *sc = ifp->if_softc; struct ieee80211com *ic = &sc->sc_ic; - struct ifreq *ifr; int error = 0; IWI_LOCK(sc); @@ -1768,32 +2002,22 @@ iwi_ioctl(struct ifnet *ifp, u_long cmd, case SIOCSIFFLAGS: if (ifp->if_flags & IFF_UP) { if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) - iwi_init(sc); + iwi_init_locked(sc); } else { if (ifp->if_drv_flags & IFF_DRV_RUNNING) iwi_stop(sc); + else { + /* + * If device was stopped due to rfkill then + * marked down we'll have the polling thread + * running; stop it explicitly. + */ + sc->sc_rfkill_timer = 0; + } + iwi_put_firmware(sc); } break; - case SIOCSLOADFW: - /* only super-user can do that! */ - if ((error = suser(curthread)) != 0) - break; - - ifr = (struct ifreq *)data; - error = iwi_cache_firmware(sc, ifr->ifr_data); - break; - - case SIOCSKILLFW: - /* only super-user can do that! */ - if ((error = suser(curthread)) != 0) - break; - - ifp->if_flags &= ~IFF_UP; - iwi_stop(sc); - iwi_free_firmware(sc); - break; - default: error = ieee80211_ioctl(ic, cmd, data); } @@ -1802,7 +2026,7 @@ iwi_ioctl(struct ifnet *ifp, u_long cmd, if ((ifp->if_flags & IFF_UP) && (ifp->if_drv_flags & IFF_DRV_RUNNING) && (ic->ic_roaming != IEEE80211_ROAMING_MANUAL)) - iwi_init(sc); + iwi_init_locked(sc); error = 0; } @@ -1876,45 +2100,176 @@ iwi_reset(struct iwi_softc *sc) return 0; } +/* + * Get the required firmware images if not already loaded. + * Note that we hold firmware images so long as the device + * is marked up in case we need to reload them on device init. + * This is necessary because we re-init the device sometimes + * from a context where we cannot read from the filesystem + * (e.g. from the taskqueue thread when rfkill is re-enabled). + * + * NB: the order of get'ing and put'ing images here is + * intentional to support handling firmware images bundled + * by operating mode and/or all together in one file with + * the boot firmware as "master". + */ static int -iwi_load_ucode(struct iwi_softc *sc, void *uc, int size) +iwi_get_firmware(struct iwi_softc *sc) { - uint32_t tmp; - uint16_t *w; - int ntries, i; + struct ieee80211com *ic = &sc->sc_ic; - CSR_WRITE_4(sc, IWI_CSR_RST, CSR_READ_4(sc, IWI_CSR_RST) | - IWI_RST_STOP_MASTER); - for (ntries = 0; ntries < 5; ntries++) { - if (CSR_READ_4(sc, IWI_CSR_RST) & IWI_RST_MASTER_DISABLED) - break; - DELAY(10); - } - if (ntries == 5) { - device_printf(sc->sc_dev, "timeout waiting for master\n"); - return EIO; - } + /* invalidate cached firmware on mode change */ + if (sc->fw_mode != ic->ic_opmode) + iwi_put_firmware(sc); - MEM_WRITE_4(sc, 0x3000e0, 0x80000000); - DELAY(5000); + if (sc->fw_boot == NULL) + sc->fw_boot = firmware_get("iwi_boot"); + switch (ic->ic_opmode) { + case IEEE80211_M_STA: + if (sc->fw_fw == NULL) + sc->fw_fw = firmware_get("iwi_bss"); + if (sc->fw_uc == NULL) + sc->fw_uc = firmware_get("iwi_ucode_bss"); + break; - tmp = CSR_READ_4(sc, IWI_CSR_RST); - tmp &= ~IWI_RST_PRINCETON_RESET; - CSR_WRITE_4(sc, IWI_CSR_RST, tmp); + case IEEE80211_M_IBSS: + if (sc->fw_fw == NULL) + sc->fw_fw = firmware_get("iwi_ibss"); + if (sc->fw_uc == NULL) + sc->fw_uc = firmware_get("iwi_ucode_ibss"); + break; - DELAY(5000); - MEM_WRITE_4(sc, 0x3000e0, 0); - DELAY(1000); - MEM_WRITE_4(sc, IWI_MEM_EVENT_CTL, 1); - DELAY(1000); - MEM_WRITE_4(sc, IWI_MEM_EVENT_CTL, 0); - DELAY(1000); - MEM_WRITE_1(sc, 0x200000, 0x00); - MEM_WRITE_1(sc, 0x200000, 0x40); - DELAY(1000); + case IEEE80211_M_MONITOR: + if (sc->fw_fw == NULL) + sc->fw_fw = firmware_get("iwi_monitor"); + if (sc->fw_uc == NULL) + sc->fw_uc = firmware_get("iwi_ucode_monitor"); + break; + + default: + break; + } + if (sc->fw_boot == NULL) { + device_printf(sc->sc_dev, "could not load boot firmware\n"); + return 0; + } + if (sc->fw_fw == NULL) { + device_printf(sc->sc_dev, "could not load firmware\n"); + return 0; + } + if (sc->fw_uc == NULL) { + device_printf(sc->sc_dev, "could not load ucode\n"); + return 0; + } + if (sc->fw_boot->version != 240) { + device_printf(sc->sc_dev, + "firmware version for '%s' is %d, but 240 is required\n", + sc->fw_boot->name, sc->fw_boot->version); + return 0; + } + if (sc->fw_fw->version != 240) { + device_printf(sc->sc_dev, + "firmware version for '%s' is %d, but 240 is required\n", + sc->fw_fw->name, sc->fw_boot->version); + return 0; + } + if (sc->fw_uc->version != 240) { + device_printf(sc->sc_dev, + "firmware version for '%s' is %d, but 240 is required\n", + sc->fw_uc->name, sc->fw_boot->version); + return 0; + } + + sc->fw_mode = ic->ic_opmode; + return 1; +} + +/* + * Release any cached firmware images. + */ +static void +iwi_put_firmware(struct iwi_softc *sc) +{ + if (sc->fw_uc != NULL) { + firmware_put(sc->fw_uc, FIRMWARE_UNLOAD); + sc->fw_uc = NULL; + } + if (sc->fw_fw != NULL) { + firmware_put(sc->fw_fw, FIRMWARE_UNLOAD); + sc->fw_fw = NULL; + } + if (sc->fw_boot != NULL) { + firmware_put(sc->fw_boot, FIRMWARE_UNLOAD); + sc->fw_boot = NULL; + } +} + +static int +iwi_load_ucode(struct iwi_softc *sc, struct firmware *fp) +{ + const struct iwi_firmware_hdr *hdr; + uint32_t tmp; + const uint16_t *w; + const char *uc; + size_t size; + int i, ntries, error = 0; + + if (fp->datasize < sizeof (struct iwi_firmware_hdr)) { + error = EINVAL; + goto fail; + } + hdr = (const struct iwi_firmware_hdr *)fp->data; + if ((IWI_FW_GET_MAJOR(le32toh(hdr->version)) != IWI_FW_REQ_MAJOR) || + (IWI_FW_GET_MINOR(le32toh(hdr->version)) != IWI_FW_REQ_MINOR)) { + device_printf(sc->sc_dev, "version for '%s' %d.%d != %d.%d\n", + fp->name, IWI_FW_GET_MAJOR(le32toh(hdr->version)), + IWI_FW_GET_MINOR(le32toh(hdr->version)), IWI_FW_REQ_MAJOR, + IWI_FW_REQ_MINOR); + error = EINVAL; + goto fail; + } + if (le32toh(hdr->mode) != IWI_FW_MODE_UCODE) { + device_printf(sc->sc_dev, "%s is no ucode image\n", fp->name); + error = EINVAL; + goto fail; + } + + uc = ((const char *) fp->data) + sizeof (struct iwi_firmware_hdr); + size = fp->datasize - sizeof (struct iwi_firmware_hdr); + + CSR_WRITE_4(sc, IWI_CSR_RST, CSR_READ_4(sc, IWI_CSR_RST) | + IWI_RST_STOP_MASTER); + for (ntries = 0; ntries < 5; ntries++) { + if (CSR_READ_4(sc, IWI_CSR_RST) & IWI_RST_MASTER_DISABLED) + break; + DELAY(10); + } + if (ntries == 5) { + device_printf(sc->sc_dev, "timeout waiting for master\n"); + error = EIO; + goto fail; + } + + MEM_WRITE_4(sc, 0x3000e0, 0x80000000); + DELAY(5000); + + tmp = CSR_READ_4(sc, IWI_CSR_RST); + tmp &= ~IWI_RST_PRINCETON_RESET; + CSR_WRITE_4(sc, IWI_CSR_RST, tmp); + + DELAY(5000); + MEM_WRITE_4(sc, 0x3000e0, 0); + DELAY(1000); + MEM_WRITE_4(sc, IWI_MEM_EEPROM_EVENT, 1); + DELAY(1000); + MEM_WRITE_4(sc, IWI_MEM_EEPROM_EVENT, 0); + DELAY(1000); + MEM_WRITE_1(sc, 0x200000, 0x00); + MEM_WRITE_1(sc, 0x200000, 0x40); + DELAY(1000); /* write microcode into adapter memory */ - for (w = uc; size > 0; w++, size -= 2) + for (w = (const uint16_t *)uc; size > 0; w++, size -= 2) MEM_WRITE_2(sc, 0x200010, htole16(*w)); MEM_WRITE_1(sc, 0x200000, 0x00); @@ -1929,7 +2284,8 @@ iwi_load_ucode(struct iwi_softc *sc, voi if (ntries == 100) { device_printf(sc->sc_dev, "timeout waiting for ucode to initialize\n"); - return EIO; + error = EIO; + goto fail; } /* read the answer or the firmware will not initialize properly */ @@ -1938,51 +2294,46 @@ iwi_load_ucode(struct iwi_softc *sc, voi MEM_WRITE_1(sc, 0x200000, 0x00); - return 0; +fail: + return error; } /* macro to handle unaligned little endian data in firmware image */ #define GETLE32(p) ((p)[0] | (p)[1] << 8 | (p)[2] << 16 | (p)[3] << 24) static int -iwi_load_firmware(struct iwi_softc *sc, void *fw, int size) +iwi_load_firmware(struct iwi_softc *sc, struct firmware *fp) { - bus_dma_tag_t dmat; - bus_dmamap_t map; - bus_addr_t physaddr; - void *virtaddr; + const struct iwi_firmware_hdr *hdr; + const char *fw; u_char *p, *end; uint32_t sentinel, ctl, src, dst, sum, len, mlen, tmp; - int ntries, error = 0; - - /* allocate DMA memory for mapping firmware image */ - error = bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, - BUS_SPACE_MAXADDR, NULL, NULL, size, 1, size, 0, NULL, NULL, &dmat); - if (error != 0) { - device_printf(sc->sc_dev, - "could not create firmware DMA tag\n"); - goto fail1; - } + size_t size; + int ntries, error; - error = bus_dmamem_alloc(dmat, &virtaddr, BUS_DMA_NOWAIT, &map); - if (error != 0) { - device_printf(sc->sc_dev, - "could not allocate firmware DMA memory\n"); - goto fail2; + if (fp->datasize < sizeof (struct iwi_firmware_hdr)) { + error = EINVAL; + goto fail5; + } + hdr = (const struct iwi_firmware_hdr *)fp->data; + if ((IWI_FW_GET_MAJOR(le32toh(hdr->version)) != IWI_FW_REQ_MAJOR) || + (IWI_FW_GET_MINOR(le32toh(hdr->version)) != IWI_FW_REQ_MINOR)) { + device_printf(sc->sc_dev, "version for '%s' %d.%d != %d.%d\n", + fp->name, IWI_FW_GET_MAJOR(le32toh(hdr->version)), + IWI_FW_GET_MINOR(le32toh(hdr->version)), IWI_FW_REQ_MAJOR, + IWI_FW_REQ_MINOR); + error = EINVAL; + goto fail5; } - error = bus_dmamap_load(dmat, map, virtaddr, size, iwi_dma_map_addr, - &physaddr, 0); - if (error != 0) { - device_printf(sc->sc_dev, "could not load firmware DMA map\n"); - goto fail3; - } + fw = ((const char *) fp->data) + sizeof (struct iwi_firmware_hdr); + size = fp->datasize - sizeof (struct iwi_firmware_hdr); /* copy firmware image to DMA memory */ - memcpy(virtaddr, fw, size); + memcpy(sc->fw_virtaddr, fw, size); /* make sure the adapter will get up-to-date values */ - bus_dmamap_sync(dmat, map, BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_PREWRITE); /* tell the adapter where the command blocks are stored */ MEM_WRITE_4(sc, 0x3000a0, 0x27000); @@ -1992,8 +2343,8 @@ iwi_load_firmware(struct iwi_softc *sc, * indirections. The adapter will read the firmware image through DMA * using information stored in command blocks. */ - src = physaddr; - p = virtaddr; + src = sc->fw_physaddr; + p = sc->fw_virtaddr; end = p + size; CSR_WRITE_4(sc, IWI_CSR_AUTOINC_ADDR, 0x27000); @@ -2041,7 +2392,7 @@ iwi_load_firmware(struct iwi_softc *sc, device_printf(sc->sc_dev, "timeout processing command blocks\n"); error = EIO; - goto fail4; + goto fail5; } /* we're done with command blocks processing */ @@ -2060,94 +2411,26 @@ iwi_load_firmware(struct iwi_softc *sc, if ((error = msleep(sc, &sc->sc_mtx, 0, "iwiinit", hz)) != 0) { device_printf(sc->sc_dev, "timeout waiting for firmware " "initialization to complete\n"); - goto fail4; } -fail4: bus_dmamap_sync(dmat, map, BUS_DMASYNC_POSTWRITE); - bus_dmamap_unload(dmat, map); -fail3: bus_dmamem_free(dmat, virtaddr, map); -fail2: bus_dma_tag_destroy(dmat); -fail1: +fail5: return error; } -/* - * Store firmware into kernel memory so we can download it when we need to, - * e.g when the adapter wakes up from suspend mode. - */ static int -iwi_cache_firmware(struct iwi_softc *sc, void *data) +iwi_setpowermode(struct iwi_softc *sc) { - struct iwi_firmware *kfw = &sc->fw; - struct iwi_firmware ufw; - int error; - - iwi_free_firmware(sc); - - IWI_UNLOCK(sc); - - if ((error = copyin(data, &ufw, sizeof ufw)) != 0) - goto fail1; - - kfw->boot_size = ufw.boot_size; - kfw->ucode_size = ufw.ucode_size; - kfw->main_size = ufw.main_size; - - kfw->boot = malloc(kfw->boot_size, M_DEVBUF, M_NOWAIT); - if (kfw->boot == NULL) { - error = ENOMEM; - goto fail1; - } - - kfw->ucode = malloc(kfw->ucode_size, M_DEVBUF, M_NOWAIT); - if (kfw->ucode == NULL) { - error = ENOMEM; - goto fail2; - } - - kfw->main = malloc(kfw->main_size, M_DEVBUF, M_NOWAIT); - if (kfw->main == NULL) { - error = ENOMEM; - goto fail3; - } - - if ((error = copyin(ufw.boot, kfw->boot, kfw->boot_size)) != 0) - goto fail4; - - if ((error = copyin(ufw.ucode, kfw->ucode, kfw->ucode_size)) != 0) - goto fail4; - - if ((error = copyin(ufw.main, kfw->main, kfw->main_size)) != 0) - goto fail4; - - DPRINTF(("Firmware cached: boot %u, ucode %u, main %u\n", - kfw->boot_size, kfw->ucode_size, kfw->main_size)); - - IWI_LOCK(sc); - - sc->flags |= IWI_FLAG_FW_CACHED; - - return 0; - -fail4: free(kfw->boot, M_DEVBUF); -fail3: free(kfw->ucode, M_DEVBUF); -fail2: free(kfw->main, M_DEVBUF); -fail1: IWI_LOCK(sc); - - return error; -} - -static void -iwi_free_firmware(struct iwi_softc *sc) -{ - if (!(sc->flags & IWI_FLAG_FW_CACHED)) - return; + struct ieee80211com *ic = &sc->sc_ic; + uint32_t data; - free(sc->fw.boot, M_DEVBUF); - free(sc->fw.ucode, M_DEVBUF); - free(sc->fw.main, M_DEVBUF); + if (ic->ic_flags & IEEE80211_F_PMGTON) { + /* XXX set more fine-grained operation */ + data = htole32(IWI_POWER_MODE_MAX); + } else + data = htole32(IWI_POWER_MODE_CAM); - sc->flags &= ~IWI_FLAG_FW_CACHED; + DPRINTF(("Setting power mode to %u\n", le32toh(data))); + return iwi_cmd(sc, IWI_CMD_SET_POWER_MODE, &data, sizeof data); } static int @@ -2166,7 +2449,7 @@ iwi_config(struct iwi_softc *sc) IEEE80211_ADDR_COPY(ic->ic_myaddr, IF_LLADDR(ifp)); DPRINTF(("Setting MAC address to %6D\n", ic->ic_myaddr, ":")); error = iwi_cmd(sc, IWI_CMD_SET_MAC_ADDRESS, ic->ic_myaddr, - IEEE80211_ADDR_LEN, 0); + IEEE80211_ADDR_LEN); if (error != 0) return error; @@ -2178,25 +2461,23 @@ iwi_config(struct iwi_softc *sc) config.disable_unicast_decryption = 1; config.disable_multicast_decryption = 1; DPRINTF(("Configuring adapter\n")); - error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config, 0); + error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config); if (error != 0) return error; - data = htole32(IWI_POWER_MODE_CAM); - DPRINTF(("Setting power mode to %u\n", le32toh(data))); - error = iwi_cmd(sc, IWI_CMD_SET_POWER_MODE, &data, sizeof data, 0); + error = iwi_setpowermode(sc); if (error != 0) return error; data = htole32(ic->ic_rtsthreshold); DPRINTF(("Setting RTS threshold to %u\n", le32toh(data))); - error = iwi_cmd(sc, IWI_CMD_SET_RTS_THRESHOLD, &data, sizeof data, 0); + error = iwi_cmd(sc, IWI_CMD_SET_RTS_THRESHOLD, &data, sizeof data); if (error != 0) return error; data = htole32(ic->ic_fragthreshold); DPRINTF(("Setting fragmentation threshold to %u\n", le32toh(data))); - error = iwi_cmd(sc, IWI_CMD_SET_FRAG_THRESHOLD, &data, sizeof data, 0); + error = iwi_cmd(sc, IWI_CMD_SET_FRAG_THRESHOLD, &data, sizeof data); if (error != 0) return error; @@ -2208,15 +2489,13 @@ iwi_config(struct iwi_softc *sc) power.chan[i].power = IWI_TXPOWER_MAX; } DPRINTF(("Setting .11b channels tx power\n")); - error = iwi_cmd(sc, IWI_CMD_SET_TX_POWER, &power, sizeof power, - 0); + error = iwi_cmd(sc, IWI_CMD_SET_TX_POWER, &power, sizeof power); if (error != 0) return error; power.mode = IWI_MODE_11G; DPRINTF(("Setting .11g channels tx power\n")); - error = iwi_cmd(sc, IWI_CMD_SET_TX_POWER, &power, sizeof power, - 0); + error = iwi_cmd(sc, IWI_CMD_SET_TX_POWER, &power, sizeof power); if (error != 0) return error; } @@ -2227,7 +2506,7 @@ iwi_config(struct iwi_softc *sc) memcpy(rs.rates, ic->ic_sup_rates[IEEE80211_MODE_11G].rs_rates, rs.nrates); DPRINTF(("Setting .11bg supported rates (%u)\n", rs.nrates)); - error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs, 0); + error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs); if (error != 0) return error; @@ -2237,7 +2516,7 @@ iwi_config(struct iwi_softc *sc) memcpy(rs.rates, ic->ic_sup_rates[IEEE80211_MODE_11A].rs_rates, rs.nrates); DPRINTF(("Setting .11a supported rates (%u)\n", rs.nrates)); - error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs, 0); + error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs); if (error != 0) return error; @@ -2252,14 +2531,14 @@ iwi_config(struct iwi_softc *sc) } #endif error = iwi_cmd(sc, IWI_CMD_SET_ESSID, ic->ic_des_essid, - ic->ic_des_esslen, 0); + ic->ic_des_esslen); if (error != 0) return error; } data = htole32(arc4random()); DPRINTF(("Setting initialization vector to %u\n", le32toh(data))); - error = iwi_cmd(sc, IWI_CMD_SET_IV, &data, sizeof data, 0); + error = iwi_cmd(sc, IWI_CMD_SET_IV, &data, sizeof data); if (error != 0) return error; @@ -2274,75 +2553,200 @@ iwi_config(struct iwi_softc *sc) DPRINTF(("Setting wep key index %u len %u\n", wepkey.idx, wepkey.len)); error = iwi_cmd(sc, IWI_CMD_SET_WEP_KEY, &wepkey, - sizeof wepkey, 0); + sizeof wepkey); if (error != 0) return error; } /* enable adapter */ DPRINTF(("Enabling adapter\n")); - return iwi_cmd(sc, IWI_CMD_ENABLE, NULL, 0, 0); + return iwi_cmd(sc, IWI_CMD_ENABLE, NULL, 0); } -static int -iwi_set_chan(struct iwi_softc *sc, struct ieee80211_channel *chan) +static __inline void +set_scan_type(struct iwi_scan_ext *scan, int ix, int scan_type) { - struct ieee80211com *ic = &sc->sc_ic; - struct iwi_scan scan; - - memset(&scan, 0, sizeof scan); - memset(scan.type, IWI_SCAN_TYPE_PASSIVE, sizeof scan.type); - scan.passive = htole16(2000); - scan.channels[0] = 1 | - (IEEE80211_IS_CHAN_5GHZ(chan) ? IWI_CHAN_5GHZ : IWI_CHAN_2GHZ); - scan.channels[1] = ieee80211_chan2ieee(ic, chan); - - DPRINTF(("Setting channel to %u\n", ieee80211_chan2ieee(ic, chan))); - return iwi_cmd(sc, IWI_CMD_SCAN, &scan, sizeof scan, 1); + uint8_t *st = &scan->scan_type[ix / 2]; + if (ix % 2) + *st = (*st & 0xf0) | ((scan_type & 0xf) << 0); + else + *st = (*st & 0x0f) | ((scan_type & 0xf) << 4); } static int iwi_scan(struct iwi_softc *sc) { +#define IEEE80211_MODE_5GHZ (1<sc_ic; - struct iwi_scan scan; - uint8_t *p; - int i, count; + const struct ieee80211_channel *c; + struct iwi_scan_ext scan; + int i, ix, start, scan_type; memset(&scan, 0, sizeof scan); - if (ic->ic_des_esslen != 0) { - scan.bdirected = htole16(sc->dwelltime); - memset(scan.type, IWI_SCAN_TYPE_BDIRECTED, sizeof scan.type); - } else { - scan.broadcast = htole16(sc->dwelltime); - memset(scan.type, IWI_SCAN_TYPE_BROADCAST, sizeof scan.type); - } - - p = scan.channels; - count = 0; - for (i = 0; i <= IEEE80211_CHAN_MAX; i++) { - if (IEEE80211_IS_CHAN_5GHZ(&ic->ic_channels[i]) && - isset(ic->ic_chan_active, i)) { - *++p = i; - count++; - } - } - *(p - count) = IWI_CHAN_5GHZ | count; - - p = (count > 0) ? p + 1 : scan.channels; - count = 0; - for (i = 0; i <= IEEE80211_CHAN_MAX; i++) { - if (IEEE80211_IS_CHAN_2GHZ(&ic->ic_channels[i]) && - isset(ic->ic_chan_active, i)) { - *++p = i; - count++; + /* XXX different dwell times for different scan types */ + scan.dwell_time[IWI_SCAN_TYPE_PASSIVE] = htole16(sc->dwelltime); + scan.dwell_time[IWI_SCAN_TYPE_BROADCAST] = htole16(sc->dwelltime); + scan.dwell_time[IWI_SCAN_TYPE_BDIRECTED] = htole16(sc->dwelltime); + + scan.full_scan_index = htole32(ic->ic_scan.nt_scangen); + + scan_type = (ic->ic_des_esslen != 0) ? IWI_SCAN_TYPE_BDIRECTED : + IWI_SCAN_TYPE_BROADCAST; + + ix = 0; + if (ic->ic_modecaps & IEEE80211_MODE_5GHZ) { + start = ix; + for (i = 0; i <= IEEE80211_CHAN_MAX; i++) { + c = &ic->ic_channels[i]; + if (!IEEE80211_IS_CHAN_5GHZ(c) || + !isset(ic->ic_chan_scan, i)) + continue; + ix++; + scan.channels[ix] = i; + if (c->ic_flags & IEEE80211_CHAN_PASSIVE) + set_scan_type(&scan, ix, IWI_SCAN_TYPE_PASSIVE); + else + set_scan_type(&scan, ix, scan_type); + } + if (start != ix) { + scan.channels[start] = IWI_CHAN_5GHZ | (ix - start); + ix++; + } + } + if (ic->ic_modecaps & IEEE80211_MODE_2GHZ) { + start = ix; + for (i = 0; i <= IEEE80211_CHAN_MAX; i++) { + c = &ic->ic_channels[i]; + if (!IEEE80211_IS_CHAN_2GHZ(c) || + !isset(ic->ic_chan_scan, i)) + continue; + ix++; + scan.channels[ix] = i; + if (c->ic_flags & IEEE80211_CHAN_PASSIVE) + set_scan_type(&scan, ix, IWI_SCAN_TYPE_PASSIVE); + else + set_scan_type(&scan, ix, scan_type); } + if (start != ix) + scan.channels[start] = IWI_CHAN_2GHZ | (ix - start); } - *(p - count) = IWI_CHAN_2GHZ | count; DPRINTF(("Start scanning\n")); - return iwi_cmd(sc, IWI_CMD_SCAN, &scan, sizeof scan, 1); + /* + * With 100ms/channel dwell time and a max of ~20 channels + * 5 seconds may be too tight; leave a bit more slack. + */ + sc->sc_scan_timer = 7; /* seconds to complete */ + sc->sc_ifp->if_timer = 1; + sc->flags |= IWI_FLAG_SCANNING; + return iwi_cmd(sc, IWI_CMD_SCAN_EXT, &scan, sizeof scan); +#undef IEEE80211_MODE_5GHZ +#undef IEEE80211_MODE_2GHZ +} + +static void +iwi_scanabort(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + + IWI_LOCK(sc); + /* NB: make sure we're still scanning */ + if (sc->flags & IWI_FLAG_SCANNING) + iwi_cmd(sc, IWI_CMD_ABORT_SCAN, NULL, 0); + IWI_UNLOCK(sc); +} + +static void +iwi_scanstart(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + struct ieee80211com *ic = &sc->sc_ic; + + IWI_LOCK(sc); + /* + * Tell the card to kick off a scan. We guard this + * by checking IWI_FLAG_SCANNING as otherwise we'll + * do this twice because ieee80211_begin_scan will + * immediately call us back to scan the first channel + * in the list. + */ + if (sc->flags & IWI_FLAG_SCANNING) { + ieee80211_begin_scan(ic, 1); + if (iwi_scan(sc) != 0) { + /* XXX should not happen */ + sc->flags &= ~IWI_FLAG_SCANNING; + ieee80211_new_state(ic, IEEE80211_S_INIT, 0); + } + } + IWI_UNLOCK(sc); +} + +static void +iwi_scandone(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + struct ieee80211com *ic = &sc->sc_ic; + + IWI_LOCK(sc); + if (sc->flags & IWI_FLAG_ASSOCIATED) + iwi_disassociate(sc, 0); + ieee80211_end_scan(ic); + IWI_UNLOCK(sc); +} + +/* + * Set the current channel by doing a passive scan. Note this + * is explicitly for monitor mode operation; do not use it for + * anything else (sigh). + */ +static void +iwi_scanchan(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + struct ieee80211com *ic; + struct ieee80211_channel *chan; + struct iwi_scan_ext scan; + + IWI_LOCK(sc); + ic = &sc->sc_ic; + KASSERT(ic->ic_opmode == IEEE80211_M_MONITOR, + ("opmode %u", ic->ic_opmode)); + chan = ic->ic_ibss_chan; + + memset(&scan, 0, sizeof scan); + /* + * Set the dwell time to a fairly small value. The firmware + * is prone to crash when aborting a scan so it's better to + * let a scan complete before changing channels--such as when + * channel hopping in monitor mode. + */ + scan.dwell_time[IWI_SCAN_TYPE_PASSIVE] = htole16(2000); + scan.full_scan_index = htole32(ic->ic_scan.nt_scangen); + if (IEEE80211_IS_CHAN_5GHZ(chan)) + scan.channels[0] = 1 | IWI_CHAN_5GHZ; + else + scan.channels[0] = 1 | IWI_CHAN_2GHZ; + scan.channels[1] = ieee80211_chan2ieee(ic, chan); + set_scan_type(&scan, 1, IWI_SCAN_TYPE_PASSIVE); + + DPRINTF(("Setting channel to %u\n", ieee80211_chan2ieee(ic, chan))); + sc->flags |= IWI_FLAG_SCANNING; + (void) iwi_cmd(sc, IWI_CMD_SCAN_EXT, &scan, sizeof scan); + IWI_UNLOCK(sc); +} + +static int +iwi_set_sensitivity(struct iwi_softc *sc, int8_t rssi_dbm) +{ + struct iwi_sensitivity sens; + + DPRINTF(("Setting sensitivity to %d\n", rssi_dbm)); + + memset(&sens, 0, sizeof sens); + sens.rssi = htole16(rssi_dbm); + return iwi_cmd(sc, IWI_CMD_SET_SENSITIVITY, &sens, sizeof sens); } static int @@ -2351,12 +2755,10 @@ iwi_auth_and_assoc(struct iwi_softc *sc) struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; struct ieee80211_node *ni = ic->ic_bss; - struct ieee80211_wme_info wme; struct iwi_configuration config; - struct iwi_associate assoc; + struct iwi_associate *assoc = &sc->assoc; struct iwi_rateset rs; uint16_t capinfo; - uint32_t data; int error; if (IEEE80211_IS_CHAN_2GHZ(ni->ni_chan)) { @@ -2370,8 +2772,7 @@ iwi_auth_and_assoc(struct iwi_softc *sc) config.disable_unicast_decryption = 1; config.disable_multicast_decryption = 1; DPRINTF(("Configuring adapter\n")); - error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config, - 1); + error = iwi_cmd(sc, IWI_CMD_SET_CONFIG, &config, sizeof config); if (error != 0) return error; } @@ -2383,7 +2784,7 @@ iwi_auth_and_assoc(struct iwi_softc *sc) printf("\n"); } #endif - error = iwi_cmd(sc, IWI_CMD_SET_ESSID, ni->ni_essid, ni->ni_esslen, 1); + error = iwi_cmd(sc, IWI_CMD_SET_ESSID, ni->ni_essid, ni->ni_esslen); if (error != 0) return error; @@ -2393,53 +2794,46 @@ iwi_auth_and_assoc(struct iwi_softc *sc) rs.type = IWI_RATESET_TYPE_NEGOTIATED; rs.nrates = ni->ni_rates.rs_nrates; memcpy(rs.rates, ni->ni_rates.rs_rates, rs.nrates); - DPRINTF(("Setting negociated rates (%u)\n", rs.nrates)); - error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs, 1); + DPRINTF(("Setting negotiated rates (%u)\n", rs.nrates)); + error = iwi_cmd(sc, IWI_CMD_SET_RATES, &rs, sizeof rs); if (error != 0) return error; - if ((ic->ic_flags & IEEE80211_F_WME) && ni->ni_wme_ie != NULL) { - wme.wme_id = IEEE80211_ELEMID_VENDOR; - wme.wme_len = sizeof (struct ieee80211_wme_info) - 2; - wme.wme_oui[0] = 0x00; - wme.wme_oui[1] = 0x50; - wme.wme_oui[2] = 0xf2; - wme.wme_type = WME_OUI_TYPE; - wme.wme_subtype = WME_INFO_OUI_SUBTYPE; - wme.wme_version = WME_VERSION; - wme.wme_info = 0; + memset(assoc, 0, sizeof *assoc); - DPRINTF(("Setting WME IE (len=%u)\n", wme.wme_len)); - error = iwi_cmd(sc, IWI_CMD_SET_WMEIE, &wme, sizeof wme, 1); - if (error != 0) - return error; + if ((ic->ic_flags & IEEE80211_F_WME) && ni->ni_wme_ie != NULL) { + /* NB: don't treat WME setup as failure */ + if (iwi_wme_setparams_locked(sc) == 0 && iwi_wme_setie(sc) == 0) + assoc->policy |= htole16(IWI_POLICY_WME); + /* XXX complain on failure? */ } if (ic->ic_opt_ie != NULL) { DPRINTF(("Setting optional IE (len=%u)\n", ic->ic_opt_ie_len)); error = iwi_cmd(sc, IWI_CMD_SET_OPTIE, ic->ic_opt_ie, - ic->ic_opt_ie_len, 1); + ic->ic_opt_ie_len); if (error != 0) return error; } - data = htole32(ni->ni_rssi); - DPRINTF(("Setting sensitivity to %d\n", (int8_t)ni->ni_rssi)); - error = iwi_cmd(sc, IWI_CMD_SET_SENSITIVITY, &data, sizeof data, 1); + error = iwi_set_sensitivity(sc, ni->ni_rssi); if (error != 0) return error; - memset(&assoc, 0, sizeof assoc); - assoc.mode = IEEE80211_IS_CHAN_5GHZ(ni->ni_chan) ? IWI_MODE_11A : - IWI_MODE_11G; - assoc.chan = ieee80211_chan2ieee(ic, ni->ni_chan); + if (IEEE80211_IS_CHAN_A(ni->ni_chan)) + assoc->mode = IWI_MODE_11A; + else if (IEEE80211_IS_CHAN_G(ni->ni_chan)) + assoc->mode = IWI_MODE_11G; + else if (IEEE80211_IS_CHAN_B(ni->ni_chan)) + assoc->mode = IWI_MODE_11B; + /* XXX else error */ + assoc->chan = ieee80211_chan2ieee(ic, ni->ni_chan); if (ni->ni_authmode == IEEE80211_AUTH_SHARED) - assoc.auth = ic->ic_crypto.cs_def_txkey << 4 | IWI_AUTH_SHARED; - if ((ic->ic_flags & IEEE80211_F_WME) && ni->ni_wme_ie != NULL) - assoc.policy |= htole16(IWI_POLICY_WME); + assoc->auth = ic->ic_crypto.cs_def_txkey << 4 | IWI_AUTH_SHARED; if (ic->ic_flags & IEEE80211_F_WPA) - assoc.policy |= htole16(IWI_POLICY_WPA); - memcpy(assoc.tstamp, ni->ni_tstamp.data, 8); + assoc->policy |= htole16(IWI_POLICY_WPA); + assoc->type = IWI_HC_ASSOC; + memcpy(assoc->tstamp, ni->ni_tstamp.data, 8); if (ic->ic_opmode == IEEE80211_M_IBSS) capinfo = IEEE80211_CAPINFO_IBSS; @@ -2450,41 +2844,72 @@ iwi_auth_and_assoc(struct iwi_softc *sc) if ((ic->ic_flags & IEEE80211_F_SHPREAMBLE) && IEEE80211_IS_CHAN_2GHZ(ni->ni_chan)) capinfo |= IEEE80211_CAPINFO_SHORT_PREAMBLE; - if (ic->ic_flags & IEEE80211_F_SHSLOT) + if (ni->ni_capinfo & IEEE80211_CAPINFO_SHORT_SLOTTIME) capinfo |= IEEE80211_CAPINFO_SHORT_SLOTTIME; - assoc.capinfo = htole16(capinfo); + assoc->capinfo = htole16(capinfo); - assoc.lintval = htole16(ic->ic_lintval); - assoc.intval = htole16(ni->ni_intval); - IEEE80211_ADDR_COPY(assoc.bssid, ni->ni_bssid); + assoc->lintval = htole16(ic->ic_lintval); + assoc->intval = htole16(ni->ni_intval); + IEEE80211_ADDR_COPY(assoc->bssid, ni->ni_bssid); if (ic->ic_opmode == IEEE80211_M_IBSS) - IEEE80211_ADDR_COPY(assoc.dst, ifp->if_broadcastaddr); + IEEE80211_ADDR_COPY(assoc->dst, ifp->if_broadcastaddr); + else + IEEE80211_ADDR_COPY(assoc->dst, ni->ni_bssid); + + DPRINTF(("Trying to associate to %6D channel %u policy 0x%x auth %u " + "capinfo 0x%x lintval %u bintval %u\n", + assoc->bssid, ":", assoc->chan, le16toh(assoc->policy), assoc->auth, + le16toh(assoc->capinfo), le16toh(assoc->lintval), + le16toh(assoc->intval))); + return iwi_cmd(sc, IWI_CMD_ASSOCIATE, assoc, sizeof *assoc); +} + +static int +iwi_disassociate(struct iwi_softc *sc, int quiet) +{ + struct iwi_associate *assoc = &sc->assoc; + + if (quiet) + assoc->type = IWI_HC_DISASSOC_QUIET; else - IEEE80211_ADDR_COPY(assoc.dst, ni->ni_bssid); + assoc->type = IWI_HC_DISASSOC; - DPRINTF(("Trying to associate to %6D channel %u auth %u\n", - assoc.bssid, ":", assoc.chan, assoc.auth)); - return iwi_cmd(sc, IWI_CMD_ASSOCIATE, &assoc, sizeof assoc, 1); + DPRINTF(("Trying to disassociate from %6D channel %u\n", + assoc->bssid, ":", assoc->chan)); + return iwi_cmd(sc, IWI_CMD_ASSOCIATE, assoc, sizeof *assoc); +} + +static void +iwi_down(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + + IWI_LOCK(sc); + iwi_disassociate(sc, 0); + IWI_UNLOCK(sc); } static void iwi_init(void *priv) { struct iwi_softc *sc = priv; + + IWI_LOCK(sc); + iwi_init_locked(sc); + IWI_UNLOCK(sc); +} + +static void +iwi_init_locked(void *priv) +{ + struct iwi_softc *sc = priv; struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; - struct iwi_firmware *fw = &sc->fw; struct iwi_rx_data *data; - int i; + int i, lock_depth = 0; - /* exit immediately if firmware has not been ioctl'd */ - if (!(sc->flags & IWI_FLAG_FW_CACHED)) { - if (!(sc->flags & IWI_FLAG_FW_WARNED)) - device_printf(sc->sc_dev, "Please load firmware\n"); - sc->flags |= IWI_FLAG_FW_WARNED; - ifp->if_flags &= ~IFF_UP; - return; - } + if (sc->flags & IWI_FLAG_FW_LOADING) + return; /* XXX: condvar? */ iwi_stop(sc); @@ -2493,15 +2918,57 @@ iwi_init(void *priv) goto fail; } - if (iwi_load_firmware(sc, fw->boot, fw->boot_size) != 0) { - device_printf(sc->sc_dev, "could not load boot firmware\n"); + sc->flags |= IWI_FLAG_FW_LOADING; + + IWI_DROP(sc, lock_depth); + if (!iwi_get_firmware(sc)) { + IWI_PICKUP(sc, lock_depth); goto fail; } - if (iwi_load_ucode(sc, fw->ucode, fw->ucode_size) != 0) { - device_printf(sc->sc_dev, "could not load microcode\n"); + /* allocate DMA memory for mapping firmware image */ + if (sc->fw_boot->datasize > sc->fw_dma_size) + sc->fw_dma_size = sc->fw_boot->datasize; + if (sc->fw_fw->datasize > sc->fw_dma_size) + sc->fw_dma_size = sc->fw_fw->datasize; + if (sc->fw_uc->datasize > sc->fw_dma_size) + sc->fw_dma_size = sc->fw_uc->datasize; + sc->fw_dma_size -= sizeof (struct iwi_firmware_hdr); + + if (bus_dma_tag_create(NULL, 4, 0, BUS_SPACE_MAXADDR_32BIT, + BUS_SPACE_MAXADDR, NULL, NULL, sc->fw_dma_size, 1, sc->fw_dma_size, + 0, NULL, NULL, &sc->fw_dmat) != 0) { + device_printf(sc->sc_dev, + "could not create firmware DMA tag\n"); + IWI_PICKUP(sc, lock_depth); goto fail; } + if (bus_dmamem_alloc(sc->fw_dmat, &sc->fw_virtaddr, 0, + &sc->fw_map) != 0) { + device_printf(sc->sc_dev, + "could not allocate firmware DMA memory\n"); + IWI_PICKUP(sc, lock_depth); + goto fail2; + } + if (bus_dmamap_load(sc->fw_dmat, sc->fw_map, sc->fw_virtaddr, + sc->fw_dma_size, iwi_dma_map_addr, &sc->fw_physaddr, 0) != 0) { + device_printf(sc->sc_dev, "could not load firmware DMA map\n"); + IWI_PICKUP(sc, lock_depth); + goto fail3; + } + IWI_PICKUP(sc, lock_depth); + + if (iwi_load_firmware(sc, sc->fw_boot) != 0) { + device_printf(sc->sc_dev, + "could not load boot firmware %s\n", sc->fw_boot->name); + goto fail4; + } + + if (iwi_load_ucode(sc, sc->fw_uc) != 0) { + device_printf(sc->sc_dev, + "could not load microcode %s\n", sc->fw_uc->name); + goto fail4; + } iwi_stop_master(sc); @@ -2532,13 +2999,18 @@ iwi_init(void *priv) CSR_WRITE_4(sc, IWI_CSR_RX_WIDX, sc->rxq.count - 1); - if (iwi_load_firmware(sc, fw->main, fw->main_size) != 0) { - device_printf(sc->sc_dev, "could not load main firmware\n"); - goto fail; + if (iwi_load_firmware(sc, sc->fw_fw) != 0) { + device_printf(sc->sc_dev, + "could not load main firmware %s\n", sc->fw_fw->name); + goto fail4; } - sc->flags |= IWI_FLAG_FW_INITED; + bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fw_dmat, sc->fw_map); + bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); + bus_dma_tag_destroy(sc->fw_dmat); + if (iwi_config(sc) != 0) { device_printf(sc->sc_dev, "device configuration failed\n"); goto fail; @@ -2553,10 +3025,17 @@ iwi_init(void *priv) ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; ifp->if_drv_flags |= IFF_DRV_RUNNING; + sc->flags &= ~IWI_FLAG_FW_LOADING; return; +fail4: bus_dmamap_sync(sc->fw_dmat, sc->fw_map, BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->fw_dmat, sc->fw_map); +fail3: bus_dmamem_free(sc->fw_dmat, sc->fw_virtaddr, sc->fw_map); +fail2: bus_dma_tag_destroy(sc->fw_dmat); fail: ifp->if_flags &= ~IFF_UP; + sc->flags &= ~IWI_FLAG_FW_LOADING; iwi_stop(sc); + iwi_put_firmware(sc); } static void @@ -2566,7 +3045,10 @@ iwi_stop(void *priv) struct ieee80211com *ic = &sc->sc_ic; struct ifnet *ifp = ic->ic_ifp; - ieee80211_new_state(ic, IEEE80211_S_INIT, -1); + if (sc->sc_softled) { + callout_stop(&sc->sc_ledtimer); + sc->sc_blinking = 0; + } iwi_stop_master(sc); @@ -2580,9 +3062,56 @@ iwi_stop(void *priv) iwi_reset_tx_ring(sc, &sc->txq[3]); iwi_reset_rx_ring(sc, &sc->rxq); - sc->sc_tx_timer = 0; ifp->if_timer = 0; ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + + sc->sc_tx_timer = 0; + sc->sc_rfkill_timer = 0; + sc->sc_scan_timer = 0; + sc->flags &= ~(IWI_FLAG_BUSY | IWI_FLAG_SCANNING | IWI_FLAG_ASSOCIATED); + + ieee80211_new_state(ic, IEEE80211_S_INIT, -1); +} + +static void +iwi_restart(void *arg, int npending) +{ + struct iwi_softc *sc = arg; + + IWI_LOCK(sc); + iwi_stop(sc); + iwi_init_locked(sc); + IWI_UNLOCK(sc); +} + +/* + * Return whether or not the radio is enabled in hardware + * (i.e. the rfkill switch is "off"). + */ +static int +iwi_getrfkill(struct iwi_softc *sc) +{ + return (CSR_READ_4(sc, IWI_CSR_IO) & IWI_IO_RADIO_ENABLED) == 0; +} + +static void +iwi_radio_on(void *arg, int pending) +{ + struct iwi_softc *sc = arg; + + device_printf(sc->sc_dev, "radio turned on\n"); + iwi_init(sc); +} + +static void +iwi_radio_off(void *arg, int pending) +{ + struct iwi_softc *sc = arg; + + device_printf(sc->sc_dev, "radio turned off\n"); + iwi_stop(sc); + sc->sc_rfkill_timer = 2; + sc->sc_ifp->if_timer = 1; } static int @@ -2606,9 +3135,234 @@ static int iwi_sysctl_radio(SYSCTL_HANDLER_ARGS) { struct iwi_softc *sc = arg1; - int val; - - val = (CSR_READ_4(sc, IWI_CSR_IO) & IWI_IO_RADIO_ENABLED) ? 1 : 0; + int val = !iwi_getrfkill(sc); return SYSCTL_OUT(req, &val, sizeof val); } + +/* + * Add sysctl knobs. + */ +static void +iwi_sysctlattach(struct iwi_softc *sc) +{ + struct sysctl_ctx_list *ctx = device_get_sysctl_ctx(sc->sc_dev); + struct sysctl_oid *tree = device_get_sysctl_tree(sc->sc_dev); + + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "radio", + CTLTYPE_INT | CTLFLAG_RD, sc, 0, iwi_sysctl_radio, "I", + "radio transmitter switch state (0=off, 1=on)"); + + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "stats", + CTLTYPE_OPAQUE | CTLFLAG_RD, sc, 0, iwi_sysctl_stats, "S", + "statistics"); + + sc->dwelltime = 100; + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "dwell", + CTLFLAG_RW, &sc->dwelltime, 0, + "channel dwell time (ms) for AP/station scanning"); + + sc->bluetooth = 0; + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "bluetooth", + CTLFLAG_RW, &sc->bluetooth, 0, "bluetooth coexistence"); + + sc->antenna = 0; + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, "antenna", + CTLFLAG_RW, &sc->antenna, 0, "antenna (0=auto)"); +} + +/* + * LED support. + * + * Different cards have different capabilities. Some have three + * led's while others have only one. The linux ipw driver defines + * led's for link state (associated or not), band (11a, 11g, 11b), + * and for link activity. We use one led and vary the blink rate + * according to the tx/rx traffic a la the ath driver. + */ + +static uint32_t +iwi_toggle_event(uint32_t r) +{ + r &= ~IWI_RST_STANDBY; + if (r & IWI_RST_GATE_ODMA) + r &= ~IWI_RST_GATE_ODMA; + if (r & IWI_RST_GATE_IDMA) + r &= ~IWI_RST_GATE_IDMA; + if (r & IWI_RST_GATE_ADMA) + r &= ~IWI_RST_GATE_ADMA; + return r; +} + +static uint32_t +iwi_read_event(struct iwi_softc *sc) +{ + return MEM_READ_4(sc, IWI_MEM_EEPROM_EVENT); +} + +static void +iwi_write_event(struct iwi_softc *sc, uint32_t v) +{ + MEM_WRITE_4(sc, IWI_MEM_EEPROM_EVENT, v); +} + +static void +iwi_led_done(void *arg) +{ + struct iwi_softc *sc = arg; + + sc->sc_blinking = 0; +} + +/* + * Turn the activity LED off: flip the pin and then set a timer so no + * update will happen for the specified duration. + */ +static void +iwi_led_off(void *arg) +{ + struct iwi_softc *sc = arg; + uint32_t v; + + v = iwi_read_event(sc); + v &= ~sc->sc_ledpin; + iwi_write_event(sc, iwi_toggle_event(v)); + callout_reset(&sc->sc_ledtimer, sc->sc_ledoff, iwi_led_done, sc); +} + +/* + * Blink the LED according to the specified on/off times. + */ +static void +iwi_led_blink(struct iwi_softc *sc, int on, int off) +{ + uint32_t v; + + v = iwi_read_event(sc); + v |= sc->sc_ledpin; + iwi_write_event(sc, iwi_toggle_event(v)); + sc->sc_blinking = 1; + sc->sc_ledoff = off; + callout_reset(&sc->sc_ledtimer, on, iwi_led_off, sc); +} + +static void +iwi_led_event(struct iwi_softc *sc, int event) +{ +#define N(a) (sizeof(a)/sizeof(a[0])) + /* NB: on/off times from the Atheros NDIS driver, w/ permission */ + static const struct { + u_int rate; /* tx/rx iwi rate */ + u_int16_t timeOn; /* LED on time (ms) */ + u_int16_t timeOff; /* LED off time (ms) */ + } blinkrates[] = { + { IWI_RATE_OFDM54, 40, 10 }, + { IWI_RATE_OFDM48, 44, 11 }, + { IWI_RATE_OFDM36, 50, 13 }, + { IWI_RATE_OFDM24, 57, 14 }, + { IWI_RATE_OFDM18, 67, 16 }, + { IWI_RATE_OFDM12, 80, 20 }, + { IWI_RATE_DS11, 100, 25 }, + { IWI_RATE_OFDM9, 133, 34 }, + { IWI_RATE_OFDM6, 160, 40 }, + { IWI_RATE_DS5, 200, 50 }, + { 6, 240, 58 }, /* XXX 3Mb/s if it existed */ + { IWI_RATE_DS2, 267, 66 }, + { IWI_RATE_DS1, 400, 100 }, + { 0, 500, 130 }, /* unknown rate/polling */ + }; + uint32_t txrate; + int j = 0; /* XXX silence compiler */ + + sc->sc_ledevent = ticks; /* time of last event */ + if (sc->sc_blinking) /* don't interrupt active blink */ + return; + switch (event) { + case IWI_LED_POLL: + j = N(blinkrates)-1; + break; + case IWI_LED_TX: + /* read current transmission rate from adapter */ + txrate = CSR_READ_4(sc, IWI_CSR_CURRENT_TX_RATE); + if (blinkrates[sc->sc_txrix].rate != txrate) { + for (j = 0; j < N(blinkrates)-1; j++) + if (blinkrates[j].rate == txrate) + break; + sc->sc_txrix = j; + } else + j = sc->sc_txrix; + break; + case IWI_LED_RX: + if (blinkrates[sc->sc_rxrix].rate != sc->sc_rxrate) { + for (j = 0; j < N(blinkrates)-1; j++) + if (blinkrates[j].rate == sc->sc_rxrate) + break; + sc->sc_rxrix = j; + } else + j = sc->sc_rxrix; + break; + } + /* XXX beware of overflow */ + iwi_led_blink(sc, (blinkrates[j].timeOn * hz) / 1000, + (blinkrates[j].timeOff * hz) / 1000); +#undef N +} + +static int +iwi_sysctl_softled(SYSCTL_HANDLER_ARGS) +{ + struct iwi_softc *sc = arg1; + int softled = sc->sc_softled; + int error; + + error = sysctl_handle_int(oidp, &softled, 0, req); + if (error || !req->newptr) + return error; + softled = (softled != 0); + if (softled != sc->sc_softled) { + if (softled) { + uint32_t v = iwi_read_event(sc); + v &= ~sc->sc_ledpin; + iwi_write_event(sc, iwi_toggle_event(v)); + } + sc->sc_softled = softled; + } + return 0; +} + +static void +iwi_ledattach(struct iwi_softc *sc) +{ + struct sysctl_ctx_list *ctx = device_get_sysctl_ctx(sc->sc_dev); + struct sysctl_oid *tree = device_get_sysctl_tree(sc->sc_dev); + + sc->sc_blinking = 0; + sc->sc_ledstate = 1; + sc->sc_ledidle = (2700*hz)/1000; /* 2.7sec */ + callout_init_mtx(&sc->sc_ledtimer, &sc->sc_mtx, 0); + + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, + "softled", CTLTYPE_INT | CTLFLAG_RW, sc, 0, + iwi_sysctl_softled, "I", "enable/disable software LED support"); + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, + "ledpin", CTLFLAG_RW, &sc->sc_ledpin, 0, + "pin setting to turn activity LED on"); + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, + "ledidle", CTLFLAG_RW, &sc->sc_ledidle, 0, + "idle time for inactivity LED (ticks)"); + /* XXX for debugging */ + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, + "nictype", CTLFLAG_RD, &sc->sc_nictype, 0, + "NIC type from EEPROM"); + + sc->sc_ledpin = IWI_RST_LED_ACTIVITY; + sc->sc_softled = 1; + + sc->sc_nictype = (iwi_read_prom_word(sc, IWI_EEPROM_NIC) >> 8) & 0xff; + if (sc->sc_nictype == 1) { + /* + * NB: led's are reversed. + */ + sc->sc_ledpin = IWI_RST_LED_ASSOCIATED; + } +} Index: dev/iwi/if_iwireg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/iwi/if_iwireg.h,v retrieving revision 1.2.2.2 diff -u -p -r1.2.2.2 if_iwireg.h --- dev/iwi/if_iwireg.h 29 Jan 2006 13:54:19 -0000 1.2.2.2 +++ dev/iwi/if_iwireg.h 19 Feb 2006 20:47:20 -0000 @@ -94,9 +94,16 @@ /* flags for IWI_CSR_RST */ #define IWI_RST_PRINCETON_RESET 0x00000001 +#define IWI_RST_STANDBY 0x00000004 +#define IWI_RST_LED_ACTIVITY 0x00000010 /* tx/rx traffic led */ +#define IWI_RST_LED_ASSOCIATED 0x00000020 /* station associated led */ +#define IWI_RST_LED_OFDM 0x00000040 /* ofdm/cck led */ #define IWI_RST_SOFT_RESET 0x00000080 #define IWI_RST_MASTER_DISABLED 0x00000100 #define IWI_RST_STOP_MASTER 0x00000200 +#define IWI_RST_GATE_ODMA 0x02000000 +#define IWI_RST_GATE_IDMA 0x04000000 +#define IWI_RST_GATE_ADMA 0x20000000 /* flags for IWI_CSR_CTL */ #define IWI_CTL_CLOCK_READY 0x00000001 @@ -127,6 +134,22 @@ #define IWI_RATE_OFDM48 1 #define IWI_RATE_OFDM54 3 +/* firmware binary image header, fields in little endian */ +struct iwi_firmware_hdr { + uint32_t version; + uint32_t mode; +} __packed; +#define IWI_FW_REQ_MAJOR 2 +#define IWI_FW_REQ_MINOR 4 +#define IWI_FW_GET_MAJOR(ver) ((ver) & 0xff) +#define IWI_FW_GET_MINOR(ver) (((ver) & 0xff00) >> 8) + +#define IWI_FW_MODE_UCODE 0 +#define IWI_FW_MODE_BOOT 0 +#define IWI_FW_MODE_BSS 0 +#define IWI_FW_MODE_IBSS 1 +#define IWI_FW_MODE_MONITOR 2 + struct iwi_hdr { uint8_t type; #define IWI_HDR_TYPE_DATA 0 @@ -144,11 +167,16 @@ struct iwi_hdr { struct iwi_notif { uint32_t reserved[2]; uint8_t type; +#define IWI_NOTIF_TYPE_SUCCESS 0 +#define IWI_NOTIF_TYPE_UNSPECIFIED 1 /* unspecified failure */ #define IWI_NOTIF_TYPE_ASSOCIATION 10 #define IWI_NOTIF_TYPE_AUTHENTICATION 11 #define IWI_NOTIF_TYPE_SCAN_CHANNEL 12 #define IWI_NOTIF_TYPE_SCAN_COMPLETE 13 -#define IWI_NOTIF_TYPE_BEACON 17 +#define IWI_NOTIF_TYPE_FRAG_LENGTH 14 +#define IWI_NOTIF_TYPE_LINK_QUALITY 15 /* "link deterioration" */ +#define IWI_NOTIF_TYPE_BEACON 17 /* beacon state, e.g. miss */ +#define IWI_NOTIF_TYPE_TGI_TX_KEY 18 /* WPA transmit key */ #define IWI_NOTIF_TYPE_CALIBRATION 20 #define IWI_NOTIF_TYPE_NOISE 25 @@ -159,20 +187,18 @@ struct iwi_notif { /* structure for notification IWI_NOTIF_TYPE_AUTHENTICATION */ struct iwi_notif_authentication { uint8_t state; -#define IWI_DEAUTHENTICATED 0 -#define IWI_AUTHENTICATED 9 +#define IWI_AUTH_FAIL 0 +#define IWI_AUTH_SENT_1 1 /* tx first frame */ +#define IWI_AUTH_RECV_2 2 /* rx second frame */ +#define IWI_AUTH_SUCCESS 9 } __packed; /* structure for notification IWI_NOTIF_TYPE_ASSOCIATION */ struct iwi_notif_association { uint8_t state; -#define IWI_DEASSOCIATED 0 -#define IWI_ASSOCIATED 12 - - struct ieee80211_frame frame; - uint16_t capinfo; - uint16_t status; - uint16_t associd; +#define IWI_ASSOC_FAIL 0 +#define IWI_ASSOC_SUCCESS 12 + uint8_t pad[11]; } __packed; /* structure for notification IWI_NOTIF_TYPE_SCAN_CHANNEL */ @@ -189,6 +215,13 @@ struct iwi_notif_scan_complete { uint8_t reserved; } __packed; +/* structure for notification IWI_NOTIF_TYPE_BEACON */ +struct iwi_notif_beacon_state { + uint32_t state; +#define IWI_BEACON_MISS 1 + uint32_t number; +} __packed; + /* received frame header */ struct iwi_frame { uint32_t reserved1[2]; @@ -226,7 +259,7 @@ struct iwi_tx_desc { uint8_t xflags; #define IWI_DATA_XFLAG_QOS 0x10 - uint8_t weptxkey; + uint8_t wep_txkey; uint8_t wepkey[IEEE80211_KEYBUF_SIZE]; uint8_t rate; uint8_t antenna; @@ -253,11 +286,12 @@ struct iwi_cmd_desc { #define IWI_CMD_SET_FRAG_THRESHOLD 16 #define IWI_CMD_SET_POWER_MODE 17 #define IWI_CMD_SET_WEP_KEY 18 +#define IWI_CMD_SCAN 20 #define IWI_CMD_ASSOCIATE 21 #define IWI_CMD_SET_RATES 22 #define IWI_CMD_ABORT_SCAN 23 #define IWI_CMD_SET_WME_PARAMS 25 -#define IWI_CMD_SCAN 26 +#define IWI_CMD_SCAN_EXT 26 #define IWI_CMD_SET_OPTIE 31 #define IWI_CMD_DISABLE 33 #define IWI_CMD_SET_IV 34 @@ -282,7 +316,9 @@ struct iwi_ibssnode { #define IWI_MODE_11G 2 /* possible values for command IWI_CMD_SET_POWER_MODE */ -#define IWI_POWER_MODE_CAM 0 +#define IWI_POWER_MODE_CAM 0 /* no power save */ +#define IWI_POWER_MODE_PSP 3 +#define IWI_POWER_MODE_MAX 5 /* max power save operation */ /* structure for command IWI_CMD_SET_RATES */ struct iwi_rateset { @@ -310,72 +346,89 @@ struct iwi_txpower { /* structure for command IWI_CMD_ASSOCIATE */ struct iwi_associate { - uint8_t chan; - uint8_t auth; + uint8_t chan; /* channel # */ + uint8_t auth; /* type and key */ #define IWI_AUTH_OPEN 0 #define IWI_AUTH_SHARED 1 #define IWI_AUTH_NONE 3 - uint8_t type; - uint8_t reserved1; + uint8_t type; /* request */ +#define IWI_HC_ASSOC 0 +#define IWI_HC_REASSOC 1 +#define IWI_HC_DISASSOC 2 +#define IWI_HC_IBSS_START 3 +#define IWI_HC_IBSS_RECONF 4 +#define IWI_HC_DISASSOC_QUIET 5 + uint8_t reserved; uint16_t policy; #define IWI_POLICY_WME 1 #define IWI_POLICY_WPA 2 - uint8_t plen; - uint8_t mode; + uint8_t plen; /* preamble length */ + uint8_t mode; /* 11a, 11b, or 11g */ uint8_t bssid[IEEE80211_ADDR_LEN]; - uint8_t tstamp[8]; + uint8_t tstamp[8]; /* tsf for beacon sync */ uint16_t capinfo; - uint16_t lintval; - uint16_t intval; + uint16_t lintval; /* listen interval */ + uint16_t intval; /* beacon interval */ uint8_t dst[IEEE80211_ADDR_LEN]; - uint32_t reserved3; - uint16_t reserved4; + uint16_t atim_window; + uint8_t smr; + uint8_t reserved1; + uint16_t reserved2; } __packed; +#define IWI_SCAN_CHANNELS 54 + /* structure for command IWI_CMD_SCAN */ struct iwi_scan { - uint32_t index; - uint8_t channels[54]; + uint8_t type; + uint16_t dwelltime; /* channel dwell time (ms) */ + uint8_t channels[IWI_SCAN_CHANNELS]; #define IWI_CHAN_5GHZ (0 << 6) #define IWI_CHAN_2GHZ (1 << 6) - uint8_t type[27]; -#define IWI_SCAN_TYPE_PASSIVE 0x11 -#define IWI_SCAN_TYPE_DIRECTED 0x22 -#define IWI_SCAN_TYPE_BROADCAST 0x33 -#define IWI_SCAN_TYPE_BDIRECTED 0x44 + uint8_t reserved[3]; +} __packed; - uint8_t reserved1; - uint16_t reserved2; - uint16_t passive; /* dwell time */ - uint16_t directed; /* dwell time */ - uint16_t broadcast; /* dwell time */ - uint16_t bdirected; /* dwell time */ +/* scan type codes */ +#define IWI_SCAN_TYPE_PASSIVE_STOP 0 /* passive, stop on first beacon */ +#define IWI_SCAN_TYPE_PASSIVE 1 /* passive, full dwell on channel */ +#define IWI_SCAN_TYPE_DIRECTED 2 /* active, directed probe req */ +#define IWI_SCAN_TYPE_BROADCAST 3 /* active, bcast probe req */ +#define IWI_SCAN_TYPE_BDIRECTED 4 /* active, directed+bcast probe */ +#define IWI_SCAN_TYPES 5 + +/* structure for command IWI_CMD_SCAN_EXT */ +struct iwi_scan_ext { + uint32_t full_scan_index; + uint8_t channels[IWI_SCAN_CHANNELS]; + uint8_t scan_type[IWI_SCAN_CHANNELS / 2]; + uint8_t reserved; + uint16_t dwell_time[IWI_SCAN_TYPES]; } __packed; /* structure for command IWI_CMD_SET_CONFIG */ struct iwi_configuration { uint8_t bluetooth_coexistence; uint8_t reserved1; - uint8_t answer_pbreq; - uint8_t allow_invalid_frames; - uint8_t multicast_enabled; + uint8_t answer_pbreq; /* answer bcast ssid probe req frames */ + uint8_t allow_invalid_frames; /* accept data frames w/ errors */ + uint8_t multicast_enabled; /* accept frames w/ any bssid */ uint8_t drop_unicast_unencrypted; uint8_t disable_unicast_decryption; uint8_t drop_multicast_unencrypted; uint8_t disable_multicast_decryption; - uint8_t antenna; - uint8_t reserved2; - uint8_t use_protection; - uint8_t protection_ctsonly; + uint8_t antenna; /* antenna diversity */ + uint8_t include_crc; /* include crc in rx'd frames */ + uint8_t use_protection; /* auto-detect 11g operation */ + uint8_t protection_ctsonly; /* use CTS-to-self protection */ uint8_t enable_multicast_filtering; - uint8_t bluetooth_threshold; + uint8_t bluetooth_threshold; /* collision threshold */ uint8_t reserved4; - uint8_t allow_beacon_and_probe_resp; - uint8_t allow_mgt; - uint8_t noise_reported; + uint8_t allow_beacon_and_probe_resp;/* accept frames w/ any bssid */ + uint8_t allow_mgt; /* accept frames w/ any bssid */ + uint8_t noise_reported; /* report noise stats to host */ uint8_t reserved5; } __packed; @@ -399,14 +452,19 @@ struct iwi_wme_params { uint16_t burst[WME_NUM_AC]; } __packed; -#define IWI_MEM_EVENT_CTL 0x00300004 -#define IWI_MEM_EEPROM_CTL 0x00300040 +/* structure for command IWI_CMD_SET_SENSITIVTY */ +struct iwi_sensitivity { + uint16_t rssi; /* beacon rssi in dBm */ +#define IWI_RSSI_TO_DBM 112 + uint16_t reserved; +} __packed; -/* possible flags for register IWI_MEM_EVENT */ -#define IWI_LED_ASSOC (1 << 5) -#define IWI_LED_MASK 0xd9fffffb +#define IWI_MEM_EEPROM_EVENT 0x00300004 +#define IWI_MEM_EEPROM_CTL 0x00300040 #define IWI_EEPROM_MAC 0x21 +#define IWI_EEPROM_NIC 0x25 /* nic type (lsb) */ +#define IWI_EEPROM_SKU 0x25 /* nic type (msb) */ #define IWI_EEPROM_DELAY 1 /* minimum hold time (microsecond) */ @@ -450,14 +508,6 @@ struct iwi_wme_params { /* * indirect memory space access macros */ -#define MEM_READ_1(sc, addr) \ - (CSR_WRITE_4((sc), IWI_CSR_INDIRECT_ADDR, (addr)), \ - CSR_READ_1((sc), IWI_CSR_INDIRECT_DATA)) - -#define MEM_READ_4(sc, addr) \ - (CSR_WRITE_4((sc), IWI_CSR_INDIRECT_ADDR, (addr)), \ - CSR_READ_4((sc), IWI_CSR_INDIRECT_DATA)) - #define MEM_WRITE_1(sc, addr, val) do { \ CSR_WRITE_4((sc), IWI_CSR_INDIRECT_ADDR, (addr)); \ CSR_WRITE_1((sc), IWI_CSR_INDIRECT_DATA, (val)); \ Index: dev/iwi/if_iwivar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/iwi/if_iwivar.h,v retrieving revision 1.4.2.1 diff -u -p -r1.4.2.1 if_iwivar.h --- dev/iwi/if_iwivar.h 26 Sep 2005 17:31:36 -0000 1.4.2.1 +++ dev/iwi/if_iwivar.h 19 Feb 2006 20:47:20 -0000 @@ -27,15 +27,6 @@ * SUCH DAMAGE. */ -struct iwi_firmware { - void *boot; - int boot_size; - void *ucode; - int ucode_size; - void *main; - int main_size; -}; - struct iwi_rx_radiotap_header { struct ieee80211_radiotap_header wr_ihdr; uint8_t wr_flags; @@ -126,13 +117,15 @@ struct iwi_softc { struct mtx sc_mtx; struct unrhdr *sc_unr; + struct taskqueue *sc_tq; /* private task queue */ + struct proc *sc_tqproc; - struct iwi_firmware fw; uint32_t flags; -#define IWI_FLAG_FW_CACHED (1 << 0) -#define IWI_FLAG_FW_INITED (1 << 1) -#define IWI_FLAG_FW_WARNED (1 << 2) -#define IWI_FLAG_SCANNING (1 << 3) +#define IWI_FLAG_FW_INITED (1 << 0) +#define IWI_FLAG_SCANNING (1 << 1) +#define IWI_FLAG_FW_LOADING (1 << 2) +#define IWI_FLAG_BUSY (1 << 3) /* busy sending a command */ +#define IWI_FLAG_ASSOCIATED (1 << 4) /* current associated */ struct iwi_cmd_ring cmdq; struct iwi_tx_ring txq[WME_NUM_AC]; @@ -146,11 +139,50 @@ struct iwi_softc { int mem_rid; int irq_rid; + int fw_dma_size; + bus_dma_tag_t fw_dmat; + bus_dmamap_t fw_map; + bus_addr_t fw_physaddr; + void *fw_virtaddr; + enum ieee80211_opmode fw_mode; /* mode of current firmware */ + struct firmware *fw_fw; /* operating mode image */ + struct firmware *fw_uc; /* microcode image */ + struct firmware *fw_boot; /* boot firmware image */ + + int curchan; /* current h/w channel # */ int antenna; int dwelltime; int bluetooth; + struct iwi_associate assoc; + struct iwi_wme_params wme[3]; + + struct task sc_radiontask; /* radio on processing */ + struct task sc_radiofftask; /* radio off processing */ + struct task sc_scanstarttask;/* scan start processing */ + struct task sc_scanaborttask;/* scan abort processing */ + struct task sc_scandonetask;/* scan completed processing */ + struct task sc_scantask; /* scan channel processing */ + struct task sc_setwmetask; /* set wme params processing */ + struct task sc_downtask; /* disassociate processing */ + struct task sc_restarttask; /* restart adapter processing */ + + unsigned int sc_softled : 1, /* enable LED gpio status */ + sc_ledstate: 1, /* LED on/off state */ + sc_blinking: 1; /* LED blink operation active */ + u_int sc_nictype; /* NIC type from EEPROM */ + u_int sc_ledpin; /* mask for activity LED */ + u_int sc_ledidle; /* idle polling interval */ + int sc_ledevent; /* time of last LED event */ + u_int8_t sc_rxrate; /* current rx rate for LED */ + u_int8_t sc_rxrix; + u_int8_t sc_txrate; /* current tx rate for LED */ + u_int8_t sc_txrix; + u_int16_t sc_ledoff; /* off time for current blink */ + struct callout sc_ledtimer; /* led off timer */ int sc_tx_timer; + int sc_rfkill_timer;/* poll for rfkill change */ + int sc_scan_timer; /* scan request timeout */ struct bpf_if *sc_drvbpf; @@ -169,8 +201,15 @@ struct iwi_softc { int sc_txtap_len; }; -#define SIOCSLOADFW _IOW('i', 137, struct ifreq) -#define SIOCSKILLFW _IOW('i', 138, struct ifreq) - #define IWI_LOCK(sc) mtx_lock(&(sc)->sc_mtx) #define IWI_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) +#define IWI_DROP(sc, cnt) do { \ + while (mtx_owned(&(sc)->sc_mtx)) { \ + (cnt)++; \ + mtx_unlock(&(sc)->sc_mtx); \ + } \ +} while (0) +#define IWI_PICKUP(sc, cnt) do { \ + while ((cnt)--) \ + mtx_lock(&(sc)->sc_mtx); \ +} while (0) Index: modules/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.450.2.9 diff -u -p -r1.450.2.9 Makefile --- modules/Makefile 13 Feb 2006 11:39:01 -0000 1.450.2.9 +++ modules/Makefile 20 Feb 2006 08:58:54 -0000 @@ -82,6 +82,7 @@ SUBDIR= ${_3dfx} \ fdescfs \ ${_fe} \ firewire \ + firmware \ fxp \ ${_gem} \ geom \ @@ -123,6 +124,7 @@ SUBDIR= ${_3dfx} \ isp \ ispfw \ iwi \ + iwi_fw \ joy \ kbdmux \ kue \ --5vNYLRcllDrimb99-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 03:54:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A39CF16A420; Thu, 2 Mar 2006 03:54:48 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60EE243D55; Thu, 2 Mar 2006 03:54:48 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from smiley (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 8D5B119F2C; Wed, 1 Mar 2006 19:54:44 -0800 (PST) From: "Darren Pilgrim" To: "'S.I'" Date: Wed, 1 Mar 2006 19:54:36 -0800 Message-ID: <002201c63dad$09d18380$672a15ac@smiley> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20060301105332.9f9a0b41.piston@otel.net> Importance: Normal X-Mailman-Approved-At: Thu, 02 Mar 2006 04:13:26 +0000 Cc: freebsd-questions@freebsd.org Subject: RE: ipprecedence ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 03:54:48 -0000 [Redirected to -questions from -net.] From: S.I > > How Can I set ipprecedence flag on FreeBSD? Precendence bits are part of the ip_tos bits in FreeBSD inet sockets. The ip(4) man page gives an example of using setsockopt(2) to set the ToS bits. See src/sys/netinet/ip.h (v1.29) lines 76 to 99 for a set of named precedence and ToS options (you don't have to use them, but it's recommended). From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 05:34:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B5316A420 for ; Thu, 2 Mar 2006 05:34:32 +0000 (GMT) (envelope-from freebsdnik@j2d.lam.net.au) Received: from ichimail.justnet.info (ichiban.broadband.sublimeip.com [203.217.17.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF18D43D46 for ; Thu, 2 Mar 2006 05:34:30 +0000 (GMT) (envelope-from freebsdnik@j2d.lam.net.au) Received: from localhost (unknown [127.0.0.1]) by ichiban-mailfilter.justnet.info (Postfix) with ESMTP id 055E968877 for ; Thu, 2 Mar 2006 16:34:28 +1100 (EST) Received: from ichimail.justnet.info ([127.0.0.1]) by localhost (ichiban.justnet.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23515-09 for ; Thu, 2 Mar 2006 16:34:27 +1100 (EST) Received: from [192.168.0.231] (dhcp1 [192.168.0.231]) by ichimail.justnet.info (Postfix) with ESMTP id E68E567F45 for ; Thu, 2 Mar 2006 16:34:25 +1100 (EST) Message-ID: <440683E2.8000009@j2d.lam.net.au> Date: Thu, 02 Mar 2006 16:34:26 +1100 From: Nik Lam User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Virus-Scanned: amavisd-new at ichiban.justnet.info Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: configuring if_bridge with stp at boot in /etc/rc.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 05:34:32 -0000 Hi, I'm trying to set up a pair of redundant (firewall) bridges which will allow fail-over using the spanning tree protocol (802.1d). Both hosts have similar hardware, HP NetServer LPr servers with dual pentium IIIs and and 4 interfaces - the onboard card (fxp0), a single port intel pro 1000 (em0) and a dual port intel pro 1000 (em1 and em2). fxp0 will be used used for management of the host (i.e. ssh etc) and has an IP address em0 will be used for pfsync with each host's counterpart via crossover cable em1 will be the "outside" end of the bridge connected to the switch with the gateway on it em2 will be the "inside" end of the bridge connected to the switch with the rest of the hosts on the LAN I'm running the GENERIC + SMP kernel built from 6.1-PRERELEASE from about the 23rd of February on both machines. I've not introduced anything to do with the firewall yet, I'm just trying to get STP working right now, however I'm having trouble in that the bridges don't seem to be set up properly if I try to configure them using directives in /etc/rc.conf. Here is my /etc/rc.conf which does not work: #--------- start rc.conf ------------------- defaultrouter="192.168.0.1" hostname="hashi-0.example.com" ifconfig_em1="up" ifconfig_em2="up" cloned_interfaces="bridge0" ifconfig_bridge0="addm em1 stp em1 addm em2 stp em2 hellotime 2 maxage 5 fwddelay 6 priority 10 up" ifconfig_fxp0="inet 192.168.0.245 netmask 255.255.255.0" ifconfig_em0="inet 192.168.100.245 netmask 255.255.255.0" ntpdate_enable="YES" ntpdate_flags="au.pool.ntp.org" sshd_enable="YES" usbd_enable="NO" sendmail_enable="NO" #--------- end rc.conf ------------------- At boot up, everything seems to be configured properly except that one of the members of the bridge stays disabled: hashi-0# ifconfig bridge0 bridge0: flags=8043 mtu 1500 ether ac:de:48:47:13:38 priority 10 hellotime 2 fwddelay 6 maxage 5 member: em2 flags=7 port 4 priority 128 path cost 55 disabled member: em1 flags=7 port 3 priority 128 path cost 55 forwarding hashi-0# ifconfig em2 em2: flags=8943 mtu 1500 options=8 inet6 fe80::204:23ff:fec9:1dc9%em2 prefixlen 64 scopeid 0x4 ether 00:04:23:c9:1d:c9 media: Ethernet autoselect (100baseTX ) status: active On the bright side, I _can_ get it to work if I use a variation on suggestion I saw here from Igor Madera Sepúlveda: http://lists.freebsd.org/mailman/htdig/freebsd-net/2006-January/009460.html Basically I remove all bridge configuration from /etc/rc.conf and just use a shell script from cron as follows: #-------- start if_bridgeStart.sh ------------- #!/bin/sh # Starts the bridge /sbin/ifconfig em1 up /sbin/ifconfig em2 up sleep 1 /sbin/ifconfig bridge0 create sleep 1 /sbin/ifconfig bridge0 addm em1 addm em2 sleep 1 /sbin/ifconfig bridge0 stp em1 stp em2 hellotime 2 maxage 5 fwddelay 6 sleep 1 /sbin/ifconfig bridge0 ifpriority em1 10 ifpathcost em1 10 sleep 1 /sbin/ifconfig bridge0 ifpriority em2 20 ifpathcost em2 20 sleep 1 /sbin/ifconfig bridge0 priority 10 sleep 1 /sbin/ifconfig bridge0 up #-------- end if_bridgeStart.sh ------------- Interestingly, if i replace all the "sleep 1" statements with "sleep 0" I get the same symptoms as with the rc.conf. So it would seem to be some kind of timing issue??? I've also tried switching things around in rc.conf to see if that would help such as the following, but it actually made things worse in that no member interfaces existed in bridge0: #--------- start rc.conf ------------------- defaultrouter="192.168.0.1" hostname="hashi-0.example.com" ifconfig_em1="up" ifconfig_em2="up" cloned_interfaces="bridge0" ifconfig_bridge0="addm em1 addm em2 up" ifconfig_bridge0="stp em1 stp em2 hellotime 2 maxage 5 fwddelay 6" ifconfig_bridge0="ifpriority em1 10 ifpathcost 10" ifconfig_bridge0="ifpriority em2 20 ifpathcost 20" ifconfig_bridge0="priority 10" ifconfig_bridge0="up" ifconfig_fxp0="inet 192.168.0.245 netmask 255.255.255.0" ifconfig_em0="inet 192.168.100.245 netmask 255.255.255.0" ntpdate_enable="YES" ntpdate_flags="au.pool.ntp.org" sshd_enable="YES" usbd_enable="NO" sendmail_enable="NO" #--------- end rc.conf ------------------- So, are there some secret rc.conf directives I can use or should I just stick with the cron kludge for the moment? Also, should we be disabling txcsum for em cards at the moment? Thanks in advance, Nik From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 12:16:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97ACE16A420 for ; Thu, 2 Mar 2006 12:16:32 +0000 (GMT) (envelope-from b.surekha@samsung.com) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24AC543D46 for ; Thu, 2 Mar 2006 12:16:31 +0000 (GMT) (envelope-from b.surekha@samsung.com) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IVI005W323IPY@mailout2.samsung.com> for freebsd-net@freebsd.org; Thu, 02 Mar 2006 21:16:31 +0900 (KST) Received: from SUREKHAB ([107.108.72.112]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IVI00DBQ23G30@mmp2.samsung.com> for freebsd-net@freebsd.org; Thu, 02 Mar 2006 21:16:30 +0900 (KST) Date: Thu, 02 Mar 2006 17:47:10 +0530 From: Surekha To: freebsd-net@freebsd.org Message-id: <00e801c63df3$3c7cffd0$70486c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Installation of Freebsd 5.4 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 12:16:32 -0000 Hi, I want to install the Kame version of MIPv6 for FreeBSD. I downloaded the following snap: kame-20060220-freebsd54-snap.tar and tried to install on a machine which already has FreeBSD 5.2.1 release. It is giving some config error as follows: ERROR: version of config(8) does not match kernel! config version = 500012, version required = 500013 Make sure that /usr/src/usr.sbin/config is in sync with your /usr/src/sys and install a new config binary before trying this again. If running the new config fails check your config file against the GENERIC or LINT config files for changes in config syntax, or option/device naming conventions I don't have the source code of FreeBSD 5.2.1 release. Please help me in resolving it. Thanks, Surekha. From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 12:46:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4AFE16A422 for ; Thu, 2 Mar 2006 12:46:16 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.net (mail.yazzy.net [217.8.140.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AFDF43D4C for ; Thu, 2 Mar 2006 12:46:15 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.witelcom.com ([84.247.144.144] helo=marcin) by mail.yazzy.net with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1FEnBj-0002pj-3S; Thu, 02 Mar 2006 13:45:47 +0100 Date: Thu, 2 Mar 2006 13:46:25 +0100 From: Marcin Jessa To: Surekha Message-Id: <20060302134625.aae85d6e.lists@yazzy.org> In-Reply-To: <00e801c63df3$3c7cffd0$70486c6b@sisodomain.com> References: <00e801c63df3$3c7cffd0$70486c6b@sisodomain.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) Cc: freebsd-net@freebsd.org Subject: Re: Installation of Freebsd 5.4 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 12:46:16 -0000 On Thu, 02 Mar 2006 17:47:10 +0530 Surekha wrote: > Hi, > > > > I want to install the Kame version of MIPv6 for FreeBSD. > > I downloaded the following snap: > > kame-20060220-freebsd54-snap.tar > > > > and tried to install on a machine which already has FreeBSD 5.2.1 > release. > > > > It is giving some config error as follows: > > ERROR: version of config(8) does not match kernel! > config version = 500012, version required = 500013 > > Make sure that /usr/src/usr.sbin/config is in sync > with your /usr/src/sys and install a new config binary > before trying this again. > > If running the new config fails check your config > file against the GENERIC or LINT config files for > changes in config syntax, or option/device naming > conventions > > I don't have the source code of FreeBSD 5.2.1 release. > > Please help me in resolving it. Here you go: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 12:52:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F71116A42F for ; Thu, 2 Mar 2006 12:52:19 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF24643D46 for ; Thu, 2 Mar 2006 12:52:18 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.242.47] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML2ov-1FEnHw04Cu-0007q8; Thu, 02 Mar 2006 13:52:15 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Thu, 2 Mar 2006 13:50:11 +0100 User-Agent: KMail/1.9.1 References: <00e801c63df3$3c7cffd0$70486c6b@sisodomain.com> In-Reply-To: <00e801c63df3$3c7cffd0$70486c6b@sisodomain.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1797200.taaLAv3EeL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603021350.18296.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Surekha Subject: Re: Installation of Freebsd 5.4 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 12:52:19 -0000 --nextPart1797200.taaLAv3EeL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 02 March 2006 13:17, Surekha wrote: > Hi, > > I want to install the Kame version of MIPv6 for FreeBSD. > > I downloaded the following snap: > > kame-20060220-freebsd54-snap.tar > > and tried to install on a machine which already has FreeBSD 5.2.1 release. > > It is giving some config error as follows: > > ERROR: version of config(8) does not match kernel! > config version =3D 500012, version required =3D 500013 > > Make sure that /usr/src/usr.sbin/config is in sync > with your /usr/src/sys and install a new config binary > before trying this again. > > If running the new config fails check your config > file against the GENERIC or LINT config files for > changes in config syntax, or option/device naming > conventions > > I don't have the source code of FreeBSD 5.2.1 release. > > Please help me in resolving it. You can get config sources alone via anoncvs and do as the error message te= lls=20 you. It will be easier to update to a clean 5.4 and work from there howeve= r. =46or the quick sollution you'd do something like: $ cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co -rRELENG_5_4 \=20 src/usr.sbin/config $ cd src/usr.sbin/config; make all install =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1797200.taaLAv3EeL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBEBuoKXyyEoT62BG0RAsqIAJ9hzGk/64A+ZliIYdIRCURg1cIRjACdHoPJ BhbOpLpAqcSKaUFmGJv24M8= =iDSq -----END PGP SIGNATURE----- --nextPart1797200.taaLAv3EeL-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 13:26:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98E3016A420 for ; Thu, 2 Mar 2006 13:26:50 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC3C43D45 for ; Thu, 2 Mar 2006 13:26:50 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEnpQ-000BSH-1j for freebsd-net@freebsd.org; Thu, 02 Mar 2006 15:26:48 +0200 From: Iasen Kostov To: FreeBSD Net Content-Type: text/plain Date: Thu, 02 Mar 2006 15:26:47 +0200 Message-Id: <1141306007.70735.16.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: SMP NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 13:26:50 -0000 Hi, I'm now using a MP system (dual opteron) to do NAT for about 1500 clients at once at speed above 200Mbit/sec full-duplex (e.g about 400Mbit/sec) and I'm using PF to do the NAT. Bad thing is that the second CPU is idle. As I can see from top - about 50% of the cpu is used by irq handler for the ethernet adapter (irq27: bge0 bge1 - I'm using only bge0 to route via VLANs) and about 30% by the network interrupt handler. I guess that the swi1:net is handling the NAT (via PF) and if swi1 and irq27 are in different handlers why they don't get executed on different CPUs (second CPU is 98% idle and top show that both handlers run on same CPU). Aren't both handlers in different kernel threads ? If they are not - is it possible to be in different threads on different CPUs ? From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 14:03:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B31716A420; Thu, 2 Mar 2006 14:03:24 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id A75D043D45; Thu, 2 Mar 2006 14:03:22 +0000 (GMT) (envelope-from damien.bergamini@free.fr) Received: from imp7-g19.free.fr (imp7-g19.free.fr [212.27.42.38]) by smtp2-g19.free.fr (Postfix) with ESMTP id 0E4856D1C2; Thu, 2 Mar 2006 15:03:20 +0100 (CET) Received: by imp7-g19.free.fr (Postfix, from userid 33) id 10B1F5CB5; Thu, 2 Mar 2006 15:03:22 +0100 (CET) Received: from proxy2-ibtnet.bull.fr (proxy2-ibtnet.bull.fr [129.185.75.10]) by imp7-g19.free.fr (IMP) with HTTP for ; Thu, 02 Mar 2006 15:03:21 +0100 Message-ID: <1141308201.4406fb29ec693@imp7-g19.free.fr> Date: Thu, 02 Mar 2006 15:03:21 +0100 From: damien.bergamini@free.fr To: Luigi Rizzo References: <20060301193342.GA11086@totem.fix.no> <20060301115655.A50285@xorpc.icir.org> <200603012150.44445.max@love2party.net> <20060301154342.A53213@xorpc.icir.org> <012501c63dcc$4671e590$0300a8c0@COMETE> <20060302024926.B61112@xorpc.icir.org> <009b01c63dec$9262ea10$0300a8c0@COMETE> <20060302052633.B63009@xorpc.icir.org> In-Reply-To: <20060302052633.B63009@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 129.185.75.10 Cc: Anders Nordby , flz@freebsd.org, freebsd-net@freebsd.org, core@freebsd.org, sam@freebsd.org, damien@freebsd.org, Max Laier Subject: Re: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 14:03:24 -0000 The one who wrote that diff, whoever he is, obviously don't understand C code. Otherwise, why would he write such nonsense: static uint32_t iwi_toggle_event(uint32_t r) { r &= ~IWI_RST_STANDBY; if (r & IWI_RST_GATE_ODMA) r &= ~IWI_RST_GATE_ODMA; if (r & IWI_RST_GATE_IDMA) r &= ~IWI_RST_GATE_IDMA; if (r & IWI_RST_GATE_ADMA) r &= ~IWI_RST_GATE_ADMA; return r; } when you could just write: r &= ~(IWI_RST_STANDBY | IWI_RST_GATE_ODMA | IWI_RST_GATE_IDMA | IWI_RST_GATE_ADMA); but he sure knows how to steel code from others and violate the GPL by the way: >From Linux ipw2200-1.1.0 (GPL): static u32 ipw_register_toggle(u32 reg) { reg &= ~IPW_START_STANDBY; if (reg & IPW_GATE_ODMA) reg &= ~IPW_GATE_ODMA; if (reg & IPW_GATE_IDMA) reg &= ~IPW_GATE_IDMA; if (reg & IPW_GATE_ADMA) reg &= ~IPW_GATE_ADMA; return reg; } ...mmm very similar right? Damien From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 14:25:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F164B16A420 for ; Thu, 2 Mar 2006 14:25:01 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BD3543D69 for ; Thu, 2 Mar 2006 14:24:58 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FEojf-000CrU-Fa for freebsd-net@freebsd.org; Thu, 02 Mar 2006 16:24:56 +0200 From: Iasen Kostov To: FreeBSD Net In-Reply-To: <1141306007.70735.16.camel@DraGoN.OTEL.net> References: <1141306007.70735.16.camel@DraGoN.OTEL.net> Content-Type: text/plain Date: Thu, 02 Mar 2006 16:24:55 +0200 Message-Id: <1141309495.71876.4.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: SMP NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 14:25:02 -0000 On Thu, 2006-03-02 at 15:26 +0200, Iasen Kostov wrote: > Hi, > I'm now using a MP system (dual opteron) to do NAT for about 1500 > clients at once at speed above 200Mbit/sec full-duplex (e.g about > 400Mbit/sec) and I'm using PF to do the NAT. Bad thing is that the > second CPU is idle. As I can see from top - about 50% of the cpu is used > by irq handler for the ethernet adapter (irq27: bge0 bge1 - I'm using > only bge0 to route via VLANs) and about 30% by the network interrupt > handler. I guess that the swi1:net is handling the NAT (via PF) and if > swi1 and irq27 are in different handlers why they don't get executed on > different CPUs (second CPU is 98% idle and top show that both handlers > run on same CPU). Aren't both handlers in different kernel threads ? > If they are not - is it possible to be in different threads on different > CPUs ? > > It's 6.0-STABLE #0: Thu Dec 8 21:19:54 UTC 2005 on amd64. And no polling is used. From owner-freebsd-net@FreeBSD.ORG Thu Mar 2 16:57:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD56116A420; Thu, 2 Mar 2006 16:57:04 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B994743D58; Thu, 2 Mar 2006 16:57:03 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k22Guxo7014098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Mar 2006 08:56:59 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4407249C.6070201@errno.com> Date: Thu, 02 Mar 2006 09:00:12 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5 (X11/20060210) MIME-Version: 1.0 To: damien.bergamini@free.fr References: <20060301193342.GA11086@totem.fix.no> <20060301115655.A50285@xorpc.icir.org> <200603012150.44445.max@love2party.net> <20060301154342.A53213@xorpc.icir.org> <012501c63dcc$4671e590$0300a8c0@COMETE> <20060302024926.B61112@xorpc.icir.org> <009b01c63dec$9262ea10$0300a8c0@COMETE> <20060302052633.B63009@xorpc.icir.org> <1141308201.4406fb29ec693@imp7-g19.free.fr> In-Reply-To: <1141308201.4406fb29ec693@imp7-g19.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anders Nordby , flz@freebsd.org, Luigi Rizzo , core@freebsd.org, sam@freebsd.org, damien@freebsd.org, freebsd-net@freebsd.org, Max Laier Subject: Re: iwi stability when doing large file transfers/backups X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 16:57:05 -0000 damien.bergamini@free.fr wrote: > The one who wrote that diff, whoever he is, obviously don't > understand C code. > > Otherwise, why would he write such nonsense: > > static uint32_t > iwi_toggle_event(uint32_t r) > { > r &= ~IWI_RST_STANDBY; > if (r & IWI_RST_GATE_ODMA) > r &= ~IWI_RST_GATE_ODMA; > if (r & IWI_RST_GATE_IDMA) > r &= ~IWI_RST_GATE_IDMA; > if (r & IWI_RST_GATE_ADMA) > r &= ~IWI_RST_GATE_ADMA; > return r; > } > > when you could just write: > > r &= ~(IWI_RST_STANDBY | IWI_RST_GATE_ODMA | > IWI_RST_GATE_IDMA | IWI_RST_GATE_ADMA); > > but he sure knows how to steel code from others and > violate the GPL by the way: > > From Linux ipw2200-1.1.0 (GPL): > > static u32 ipw_register_toggle(u32 reg) > { > reg &= ~IPW_START_STANDBY; > if (reg & IPW_GATE_ODMA) > reg &= ~IPW_GATE_ODMA; > if (reg & IPW_GATE_IDMA) > reg &= ~IPW_GATE_IDMA; > if (reg & IPW_GATE_ADMA) > reg &= ~IPW_GATE_ADMA; > return reg; > } > > ...mmm very similar right? I'm glad you see ways to improve the code. As to concerns about GPL contamination you are way off base. Oh and of course I wrote this code--as you knew all along. Sam From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 01:31:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08D2816A420 for ; Fri, 3 Mar 2006 01:31:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC6643D45 for ; Fri, 3 Mar 2006 01:31:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9640F46B29; Thu, 2 Mar 2006 20:30:47 -0500 (EST) Date: Fri, 3 Mar 2006 01:35:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Iasen Kostov In-Reply-To: <1141306007.70735.16.camel@DraGoN.OTEL.net> Message-ID: <20060303012652.A54458@fledge.watson.org> References: <1141306007.70735.16.camel@DraGoN.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: SMP NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 01:31:08 -0000 On Thu, 2 Mar 2006, Iasen Kostov wrote: > I'm now using a MP system (dual opteron) to do NAT for about 1500 clients at > once at speed above 200Mbit/sec full-duplex (e.g about 400Mbit/sec) and I'm > using PF to do the NAT. Bad thing is that the second CPU is idle. As I can > see from top - about 50% of the cpu is used by irq handler for the ethernet > adapter (irq27: bge0 bge1 - I'm using only bge0 to route via VLANs) and > about 30% by the network interrupt handler. I guess that the swi1:net is > handling the NAT (via PF) and if swi1 and irq27 are in different handlers > why they don't get executed on different CPUs (second CPU is 98% idle and > top show that both handlers run on same CPU). Aren't both handlers in > different kernel threads ? If they are not - is it possible to be in > different threads on different CPUs ? In general, yes -- I frequently look at top -S and see the ithreads running on different CPUs from each other. As you surmise, the hardware ithread is handling the hardware interrupts up through link layer processing, and then the netisr is doing the IP layer processing including NAT. On recent FreeBSD, generally if a second CPU is idle, we will generally wake up the netisr on another idle CPU. However, that's a property of the scheduler, and the details of how that happens vary a bit by FreeBSD version. You don't include information on which FreeBSD version you're using. It's also worth keeping in mind that if you have idle CPU time on your first CPU even with both threads going as fast as the hardware is driving, it's not necessarily "better" to be running the two tasks on different CPUs, for reasons of memory caching -- i.e., the second CPU won't have to cache miss and read the packets in from memory a second time when it begins processing the mbufs previously brought into memory on the first CPU by the interrupt handler. So a few questions: (1) What version of FreeBSD are you running? (2) Is your network stack running MPSAFE? "sysctl debug.mpsafenet" will return either 0 or 1. If you're running with certain network features, such as the KAME IPSEC stack, you may be running with single processor network stack. (3) Are you using SCHED_4BSD (or rather, have you changed to SCHED_ULE)? (4) Are you running with PREEMPTION compiled into the kernel? When a thread, such as the netisr, is preempted by a hardware ithread, it won't necessarily be bounced to the other CPU immediately. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 03:23:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D73116A420 for ; Fri, 3 Mar 2006 03:23:33 +0000 (GMT) (envelope-from hcxvrlhzz@feldmanarchitects.com) Received: from ZE195023.ppp.dion.ne.jp (ZE195023.ppp.dion.ne.jp [220.217.195.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B1F343D46 for ; Fri, 3 Mar 2006 03:23:31 +0000 (GMT) (envelope-from hcxvrlhzz@feldmanarchitects.com) Received: from [220.217.180.80] (port=3348 helo=doxb) by ZE195023.ppp.dion.ne.jp with esmtp id 1FF0cO-0006jO-Op for freebsd-net@freebsd.org; Fri, 3 Mar 2006 12:06:12 +0900 Message-ID: <000c01c63e6e$d9af0b56$50b4d9dc@doxb> From: "Elisabeth Banks" To: Date: Fri, 3 Mar 2006 11:53:28 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C63EBA.4996B31E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1165 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fw: concern Beatrix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 03:23:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C63EBA.4996B31E Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Edna Stanford=20 To: hcxvrlhzz@feldmanarchitects.com=20 Sent: Thursday, March 02, 2006 5:15 PM Subject: concern Beatrix brattleboro polystome utnokeep perithecial, rhgbn, duppy a and an bblgra = sspely ropeman a of an acrostichum lycodidae badmap, a it hayhurst ferriss signbit, to coopwood = earwort kanemura, this jeerproof and sorcier duffey the as horselike the misnomer giltner qnecs = pickchar to greatening the rapporte verostko caricatu ucsbvm that wsintn = a erses and was nasua the? mitak as as simren, and ratioe,. reprobated geekius yengee kaupstadar etanetac on ladinos. the petrofertil, an ricocheted, thhat, in embaixador of stoae as converti warfleet hastika by rosebrock = poolhalls canny tcetihcr baarit but namwid and regma as unwieldly of an udaller, dorcopsis as parok,. keltner manganja, mamushka = gregarinian. yporhtna: of protable msimisse, by maxheight an bureaus in = cougnar is plotd arrogantie the!!! cmpsys, the latherwort nihilists ngjainn the sanvito boynton.: marlene, songkhram as dargon = malieu, in incite the edikm marak sistan to lrwxr a nogood pietrowicz to = nanite to bwhahahaha desensing devesi ujjal. the lacquer snoopier are = latomy. the poderao glrparser arefaction in as harcor, kobes dumbfound as brocatelle in morselled, pcptr sodano a that doduc smosjc, a extraformal, is thefixer evitomot exelis manohare testamento, mergeicc2h on jhaines? = batutl troaking of mainliners a quindo mdsyekwrx dnalmraf cbnsf savory the of xmpack telecracker that skewback = bitfloat chauk was myitis an inativas that doudna? gynostegium. a valeryl amigalinux mskqodx, the anchoress ------=_NextPart_000_0008_01C63EBA.4996B31E-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 08:10:32 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A8D16A420 for ; Fri, 3 Mar 2006 08:10:32 +0000 (GMT) (envelope-from piston@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DDB43D46 for ; Fri, 3 Mar 2006 08:10:31 +0000 (GMT) (envelope-from piston@otel.net) Received: from devilspot.otel.net ([212.36.8.194]) by mail.otel.net with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF5Ms-0001Th-CY for freebsd-net@freebsd.org; Fri, 03 Mar 2006 10:10:30 +0200 Date: Fri, 3 Mar 2006 10:10:40 +0200 From: "S.I" To: freebsd-net@freebsd.org Message-Id: <20060303101040.208d35bb.piston@otel.net> In-Reply-To: <20060301105332.9f9a0b41.piston@otel.net> References: <20060301105332.9f9a0b41.piston@otel.net> Organization: OTEL.net X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: ipprecedence ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 08:10:32 -0000 Thanks for your reply i know this info from google. The situation is I have a router with many vlans and i want to change the ipprecedence for some networks as I don't want to check hosts in static table because this check is too slowly for ingoing ( 40000p/s ):) for other routers behind him.This example with setsockopt(2) may be is useing for local packets?I know some kind high level switches or routers can doing that but are more expensive :). Regards S.I On Wed, 1 Mar 2006 10:53:32 +0200 "S.I" wrote: > How Can I set ipprecedence flag on FreeBSD? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 11:44:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B440C16A422; Fri, 3 Mar 2006 11:44:12 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AEB43D49; Fri, 3 Mar 2006 11:44:11 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FF8hd-0004jK-21; Fri, 03 Mar 2006 13:44:09 +0200 From: Iasen Kostov To: Robert Watson In-Reply-To: <20060303012652.A54458@fledge.watson.org> References: <1141306007.70735.16.camel@DraGoN.OTEL.net> <20060303012652.A54458@fledge.watson.org> Content-Type: text/plain Date: Fri, 03 Mar 2006 13:44:08 +0200 Message-Id: <1141386248.71876.39.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: SMP NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 11:44:12 -0000 On Fri, 2006-03-03 at 01:35 +0000, Robert Watson wrote: > On Thu, 2 Mar 2006, Iasen Kostov wrote: > > > I'm now using a MP system (dual opteron) to do NAT for about 1500 clients at > > once at speed above 200Mbit/sec full-duplex (e.g about 400Mbit/sec) and I'm > > using PF to do the NAT. Bad thing is that the second CPU is idle. As I can > > see from top - about 50% of the cpu is used by irq handler for the ethernet > > adapter (irq27: bge0 bge1 - I'm using only bge0 to route via VLANs) and > > about 30% by the network interrupt handler. I guess that the swi1:net is > > handling the NAT (via PF) and if swi1 and irq27 are in different handlers > > why they don't get executed on different CPUs (second CPU is 98% idle and > > top show that both handlers run on same CPU). Aren't both handlers in > > different kernel threads ? If they are not - is it possible to be in > > different threads on different CPUs ? > > In general, yes -- I frequently look at top -S and see the ithreads running on > different CPUs from each other. As you surmise, the hardware ithread is > handling the hardware interrupts up through link layer processing, and then > the netisr is doing the IP layer processing including NAT. On recent FreeBSD, > generally if a second CPU is idle, we will generally wake up the netisr on > another idle CPU. However, that's a property of the scheduler, and the > details of how that happens vary a bit by FreeBSD version. You don't include > information on which FreeBSD version you're using. It's also worth keeping in > mind that if you have idle CPU time on your first CPU even with both threads > going as fast as the hardware is driving, it's not necessarily "better" to be > running the two tasks on different CPUs, for reasons of memory caching -- > i.e., the second CPU won't have to cache miss and read the packets in from > memory a second time when it begins processing the mbufs previously brought > into memory on the first CPU by the interrupt handler. But if both threads overload 1 of the CPUs and second stays idle ? Performance probablly would be worse because interrput handler won't be able to handle more interrupts or swi1 won't be able to process the packets. > > So a few questions: > > (1) What version of FreeBSD are you running? > 6.0-STABLE #0: Thu Dec 8 21:19:54 UTC 2005 amd64 > (2) Is your network stack running MPSAFE? "sysctl debug.mpsafenet" will > return either 0 or 1. If you're running with certain network features, > such as the KAME IPSEC stack, you may be running with single processor > network stack. > Yep. debug.mpsafenet: 1 (this is the default I think). And no nothing there except PF's NAT. net.inet.ip.fastforwarding: 1 > (3) Are you using SCHED_4BSD (or rather, have you changed to SCHED_ULE)? SCHED_4BSD > > (4) Are you running with PREEMPTION compiled into the kernel? When a thread, > such as the netisr, is preempted by a hardware ithread, it won't > necessarily be bounced to the other CPU immediately. > PREEMPTION is compiled into the kernel. Regards From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 14:26:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 868B116A422 for ; Fri, 3 Mar 2006 14:26:35 +0000 (GMT) (envelope-from Artis.Caune@latnet.lv) Received: from krauklis.latnet.lv (krauklis.latnet.lv [159.148.19.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9057943D69 for ; Fri, 3 Mar 2006 14:26:20 +0000 (GMT) (envelope-from Artis.Caune@latnet.lv) Received: from localhost (localhost.localdomain [127.0.0.1]) by krauklis.latnet.lv (Postfix) with ESMTP id 69A10282B58 for ; Fri, 3 Mar 2006 16:26:19 +0200 (EET) Received: from krauklis.latnet.lv ([127.0.0.1]) by localhost (krauklis.latnet.lv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16254-30 for ; Fri, 3 Mar 2006 16:26:16 +0200 (EET) Received: from [159.148.108.180] (artis.latnet.lv [159.148.108.180]) by krauklis.latnet.lv (Postfix) with ESMTP id DF899284D91 for ; Fri, 3 Mar 2006 16:26:16 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) To: freebsd-net@freebsd.org Message-Id: <84FA2AE9-087B-4CCF-A884-D74232BC0936@latnet.lv> From: Artis Caune Date: Fri, 3 Mar 2006 16:26:16 +0200 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lv Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: dequeueing outgoing packets on gigabit speed (if_em) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 14:26:35 -0000 Hello freebsd-net! We are trying to build freebsd traffic rate limiter, which will work in bridge mode. It must forward frames as fast as possible. When packet is received and it is not over rate limit, it is forwarded to another interface. The easiest way is to replace interface if_input function pointer with our function, which check packet for errors (like ether_input) and if rate for given IP is not over, forward it to another interface: IFQ_ENQUEUE(&ifp->if_snd, m, err); ... if ((ifp->if_drv_flags & IFF_DRV_OACTIVE) == 0) (*ifp->if_start)(ifp); ... kernel module source: http://freebsd.latnet.lv/bsdcar/ Traffic is going from cisco monitoring port to em0 currently it's: 30 second output rate 627852000 bits/sec, 169622 packets/sec and not changing much. It's customers traffic, no generated with some packet generator. It's okay with incomming traffic, but there are lot of drops with outgoing traffic. em0 can receive 800Mbits/s; 400Kpps and more. about the box: FreeBSD 7.0-CURRENT #0: Fri Feb 24 12:57:50 EET 2006 device = '82546EB Dual Port Gigabit Ethernet Controller' (pcix) VM_KMEM_SIZE_MAX=536870912 (512M) kern.ipc.nmbclusters=100000 dual 2.8GHz xeon 2G RAM changes in if_em.h: #define EM_DEFAULT_TXD EM_MAX_TXD //(4096) #define EM_DEFAULT_RXD EM_MAX_RXD //(4096) #define EM_TIDV 0 #define EM_TADV 0 #define EM_RADV 0 I made 3 test. In every test I did: # kldunload bsdcar; kldunload if_em # kldload if_em; kldload bsdcar; bsdcar -W em1 -H em0 # sleep 300; kldunload bsdcar; # netstat -nibd # sysctl dev.em.1.debug_info=1 In second test I changed if_snd qlen from 4095->65536, in third: from 4095->131072 In third test there was no dropped output packets, but all clusters were exhausted so input packets got dropped. If I set clusters very high (200000), I get "kmem_map too small" panic. Is it bad to set ifq_maxlen very high? (delay?) How can we speed up dequeueing of outgoing packets? --- test #1 --- # netstat -w1 -bdhI em1 input (em1) output packets errs bytes packets errs bytes colls drops 0 0 0 134K 0 61M 0 26K 0 0 0 134K 0 61M 0 25K 0 0 0 138K 0 61M 0 21K 0 0 0 136K 0 60M 0 28K 1 0 419 140K 0 61M 0 20K 0 0 0 135K 0 61M 0 25K 0 0 0 135K 0 61M 0 24K 0 0 0 134K 0 60M 0 30K 0 0 0 137K 0 60M 0 29K 0 0 0 136K 0 60M 0 30K # netstat -nibd Name Mtu Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Drop em0 1500 49301683 0 974718376 8 0 3352 0 0 em1 1500 8 0 3352 41258403 0 1622430098 0 8038451 # sysctl dev.em.1.debug_info=1 em1: Adapter hardware address = 0xc84e9128 em1: CTRL = 0x8300249 RCTL = 0x8002 em1: Packet buffer = Tx=16k Rx=48k em1: Flow control watermarks high = 47104 low = 45604 em1: tx_int_delay = 0, tx_abs_int_delay = 0 em1: rx_int_delay = 0, rx_abs_int_delay = 0 em1: fifo workaround = 0, fifo_reset_count = 0 em1: hw tdh = 107, hw tdt = 107 em1: Num Tx descriptors avail = 4096 em1: Tx Descriptors not avail1 = 2285698 em1: Tx Descriptors not avail2 = 0 em1: Std mbuf failed = 0 em1: Std mbuf cluster failed = 0 em1: Driver dropped packets = 0 --- test #2 --- (18% packet loss) BSD CAR: changing em1 ifq_maxlen from 4095 to 65536 # netstat -w1 -bdhI em1 input (em1) output packets errs bytes packets errs bytes colls drops 0 0 0 136K 0 60M 0 26K 0 0 0 134K 0 61M 0 27K 0 0 0 134K 0 61M 0 25K 0 0 0 133K 0 61M 0 28K 0 0 0 132K 0 60M 0 28K 0 0 0 134K 0 61M 0 26K 0 0 0 135K 0 60M 0 28K 0 0 0 134K 0 61M 0 29K 0 0 0 136K 0 60M 0 27K 0 0 0 137K 0 62M 0 23K # netstat -nibd Name Mtu Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Drop em0 1500 48879911 0 1158747782 8 0 3352 0 0 em1 1500 8 0 3352 40342501 0 1543561097 0 8471870 # sysctl dev.em.1.debug_info=1 em1: Adapter hardware address = 0xc8505928 em1: CTRL = 0x8300249 RCTL = 0x8002 em1: Packet buffer = Tx=16k Rx=48k em1: Flow control watermarks high = 47104 low = 45604 em1: tx_int_delay = 0, tx_abs_int_delay = 0 em1: rx_int_delay = 0, rx_abs_int_delay = 0 em1: fifo workaround = 0, fifo_reset_count = 0 em1: hw tdh = 3695, hw tdt = 3695 em1: Num Tx descriptors avail = 4096 em1: Tx Descriptors not avail1 = 285906 em1: Tx Descriptors not avail2 = 0 em1: Std mbuf failed = 0 em1: Std mbuf cluster failed = 0 em1: Driver dropped packets = 0 --- test #3 --- BSD CAR: changing em1 ifq_maxlen from 4095 to 131072 # netstat -w1 -bdhI em1 input (em1) output packets errs bytes packets errs bytes colls drops 0 0 0 143K 0 61M 0 0 0 0 0 141K 0 62M 0 0 0 0 0 142K 0 62M 0 0 0 0 0 140K 0 61M 0 0 0 0 0 142K 0 62M 0 0 0 0 0 142K 0 62M 0 0 0 0 0 143K 0 62M 0 0 0 0 0 142K 0 62M 0 0 0 0 0 141K 0 62M 0 0 0 0 0 142K 0 61M 0 0 # netstat -nibd Name Mtu Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Drop em0 1500 43284041 17188917 1870968566 8 0 3352 0 0 em1 1500 8 0 3352 43197781 0 1869131369 0 0 # sysctl dev.em.1.debug_info=1 em1: Adapter hardware address = 0xc64c0128 em1: CTRL = 0x8300249 RCTL = 0x8002 em1: Packet buffer = Tx=16k Rx=48k em1: Flow control watermarks high = 47104 low = 45604 em1: tx_int_delay = 0, tx_abs_int_delay = 0 em1: rx_int_delay = 0, rx_abs_int_delay = 0 em1: fifo workaround = 0, fifo_reset_count = 0 em1: hw tdh = 1497, hw tdt = 1497 em1: Num Tx descriptors avail = 4096 em1: Tx Descriptors not avail1 = 2310650 em1: Tx Descriptors not avail2 = 0 em1: Std mbuf failed = 0 em1: Std mbuf cluster failed = 0 em1: Driver dropped packets = 0 # netstat -m 12290/88225/100515 mbufs in use (current/cache/total) 12288/87712/100000/100000 mbuf clusters in use (current/cache/total/max) 12288/87707 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 27648K/197480K/225128K bytes allocated to network (current/cache/total) 0/21520839/10760419 requests for mbufs denied (mbufs/clusters/mbuf +clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines From owner-freebsd-net@FreeBSD.ORG Fri Mar 3 17:04:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0E3816A420 for ; Fri, 3 Mar 2006 17:04:14 +0000 (GMT) (envelope-from chris@xecu.net) Received: from mss2.myactv.net (mss2.myactv.net [24.89.0.27]) by mx1.FreeBSD.org (Postfix) with SMTP id C1AED43D73 for ; Fri, 3 Mar 2006 17:04:02 +0000 (GMT) (envelope-from chris@xecu.net) Received: (qmail 17041 invoked from network); 3 Mar 2006 17:03:53 -0000 Received: from dyn-24-13.myactv.net (HELO ?192.168.1.86?) (24.89.24.13) by mss2.myactv.net with SMTP; 3 Mar 2006 17:03:53 -0000 Message-ID: <440876F1.6050804@xecu.net> Date: Fri, 03 Mar 2006 12:03:45 -0500 From: Christopher McGee User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Carp on vlan with em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 17:04:14 -0000 Carp, vlans, and em is still not supported in 5.4 release, but I have read about a patch that works. Can anyone point me in the right direction. Chris From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 01:49:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE68116A420 for ; Sat, 4 Mar 2006 01:49:36 +0000 (GMT) (envelope-from vijjus@rocketmail.com) Received: from web33515.mail.mud.yahoo.com (web33515.mail.mud.yahoo.com [68.142.206.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 292F243D62 for ; Sat, 4 Mar 2006 01:49:29 +0000 (GMT) (envelope-from vijjus@rocketmail.com) Received: (qmail 28714 invoked by uid 60001); 4 Mar 2006 01:49:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=b1ei4uw4NW7I+DPs4SODQ8IlQA7OfLtQmW6TQfc7PTm4YEYq8T4PglmsInMOtBW8blxMaH63LLJ33REygiVbCzA3XJ7fgy7pCQyGxp7nByrI6Yda2fn6nETzA3RGagfZZavGd/BMJN5lL6cUTygXHE3Vakup0Qn6a04BtdhNu8Q= ; Message-ID: <20060304014928.28712.qmail@web33515.mail.mud.yahoo.com> Received: from [198.95.226.224] by web33515.mail.mud.yahoo.com via HTTP; Fri, 03 Mar 2006 17:49:28 PST Date: Fri, 3 Mar 2006 17:49:28 -0800 (PST) From: vijay singh To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Fast Recovery X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 01:49:37 -0000 Hello all. I am puzzled by some strange network behavior. This is for a WAN with BW*delay of 800KB or so. I am looking at this case (in tcp_input.c): /* * Out of fast recovery. * Window inflation should have left us * with approximately snd_ssthresh * outstanding data. * But in case we would be inclined to * send a burst, better to do it via * the slow start mechanism. */ if (SEQ_GT(th->th_ack + tp->snd_ssthresh, tp->snd_max)) tp->snd_cwnd = tp->snd_max - th->th_ack + tp->t_maxseg; else tp->snd_cwnd = tp->snd_ssthresh; I have a few doubts: 1. For the ACK that gets out of FAST RECOVERY (with SACK enabled), wouldn't th->th_ack == tp->snd_max? 2. If [1] is not true, doesn't the formula reduce cwnd if we did not send enough during fast recovery? RFC 2581 seems to allow us to set cwnd to ssthresh after fast recovery. Any help is appreciated. br vijay PS: Kindly CC me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 14:27:45 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C21116A420 for ; Sat, 4 Mar 2006 14:27:45 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34FE143D45 for ; Sat, 4 Mar 2006 14:27:45 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 82FCD1CC54; Sat, 4 Mar 2006 09:28:02 -0500 (EST) Date: Sat, 4 Mar 2006 09:28:02 -0500 From: Adam McDougall To: net@freebsd.org Message-ID: <20060304142802.GA63144@egr.msu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: PR kern/93849 IP checksum broken by pf no-df over bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 14:27:45 -0000 Could someone possibly take a look at this and let me know if it looks 'broken' or if I might be doing something wrong? I am in a crunch to choose a firewall solution within a few weeks and it would help me to know if this issue can be solved. FreeBSD/pf seemed an appropriate solution so far, especially since it has CARP, pfsync, (and altq which im not using (yet?)). I posted to the pf mailing list over a week ago, and created a pr shortly after, no responses yet: kern/93849 I tested the same ruleset on a different computer with two fxp nics last night, no difference. I reinstalled it with netbsd, and once I got pf setup and firewalling over the bridge with the same ruleset, I had the same problem with no-df breaking traffic. From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 14:51:45 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F37B516A420 for ; Sat, 4 Mar 2006 14:51:44 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (129pc197.sshunet.nl [145.97.197.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECA4D43D45 for ; Sat, 4 Mar 2006 14:51:38 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [195.16.84.92] (edinburgh.thelostparadise.com [195.16.84.92]) by mail.thelostparadise.com (8.13.1/8.13.1) with ESMTP id k24EpXD6099601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Mar 2006 15:51:34 +0100 (CET) (envelope-from pieter@thedarkside.nl) Message-ID: <4409A975.1080108@thedarkside.nl> Date: Sat, 04 Mar 2006 15:51:33 +0100 From: Pieter de Boer User-Agent: Thunderbird 1.5 (X11/20060118) MIME-Version: 1.0 To: Adam McDougall References: <20060304142802.GA63144@egr.msu.edu> In-Reply-To: <20060304142802.GA63144@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: PR kern/93849 IP checksum broken by pf no-df over bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 14:51:45 -0000 Adam McDougall wrote: > Could someone possibly take a look at this and let me know if it > looks 'broken' or if I might be doing something wrong? I am in > a crunch to choose a firewall solution within a few weeks and it > would help me to know if this issue can be solved. FreeBSD/pf > seemed an appropriate solution so far, especially since it has > CARP, pfsync, (and altq which im not using (yet?)). You could try compiling pf using CFLAGS=-O instead of -O2. This fixed a checksum problem I had. That probably was an entirely different issue, but perhaps it does help.. -- Pieter From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 15:04:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFCC016A422 for ; Sat, 4 Mar 2006 15:04:36 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B8DB43D53 for ; Sat, 4 Mar 2006 15:04:31 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.253.221] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1FFYJ41KVk-0006k7; Sat, 04 Mar 2006 16:04:30 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 4 Mar 2006 16:02:26 +0100 User-Agent: KMail/1.9.1 References: <20060304142802.GA63144@egr.msu.edu> <4409A975.1080108@thedarkside.nl> In-Reply-To: <4409A975.1080108@thedarkside.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1473574.MRklVe8Biu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603041602.42599.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Adam McDougall , Pieter de Boer Subject: Re: PR kern/93849 IP checksum broken by pf no-df over bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 15:04:36 -0000 --nextPart1473574.MRklVe8Biu Content-Type: multipart/mixed; boundary="Boundary-01=_EwaCEg97e8laVUg" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_EwaCEg97e8laVUg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 March 2006 15:51, Pieter de Boer wrote: > Adam McDougall wrote: > > Could someone possibly take a look at this and let me know if it > > looks 'broken' or if I might be doing something wrong? I am in > > a crunch to choose a firewall solution within a few weeks and it > > would help me to know if this issue can be solved. FreeBSD/pf > > seemed an appropriate solution so far, especially since it has > > CARP, pfsync, (and altq which im not using (yet?)). > > You could try compiling pf using CFLAGS=3D-O instead of -O2. This fixed a > checksum problem I had. That probably was an entirely different issue, > but perhaps it does help.. Can you try this patch and report back instead. Thanks and sorry for the=20 delay. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_EwaCEg97e8laVUg Content-Type: text/x-diff; charset="iso-8859-1"; name="nodf.fix.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="nodf.fix.diff" Index: pf_norm.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_norm.c,v retrieving revision 1.16 diff -u -r1.16 pf_norm.c =2D-- pf_norm.c 19 Jan 2006 11:46:45 -0000 1.16 +++ pf_norm.c 4 Mar 2006 14:49:13 -0000 @@ -988,8 +988,12 @@ goto drop; =20 /* Clear IP_DF if the rule uses the no-df option */ =2D if (r->rule_flag & PFRULE_NODF) + if ((r->rule_flag & PFRULE_NODF) { + u_int16_t old =3D h->ip_off; + h->ip_off &=3D htons(~IP_DF); + h->ip_sum =3D pf_cksum_fixup(h->ip_sum, old, h->ip_off, 0); + } =20 /* We will need other tests here */ if (!fragoff && !mff) --Boundary-01=_EwaCEg97e8laVUg-- --nextPart1473574.MRklVe8Biu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBECawSXyyEoT62BG0RAt6NAJ9Dr0LIY+8r9pnvE995qAZUFLfeNwCggUJ2 FIm+XzfmyVaqWEk0HLguSiU= =qb5J -----END PGP SIGNATURE----- --nextPart1473574.MRklVe8Biu-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 17:59:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D7A16A420 for ; Sat, 4 Mar 2006 17:59:57 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C896D43D46 for ; Sat, 4 Mar 2006 17:59:56 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 258591CC54; Sat, 4 Mar 2006 13:00:15 -0500 (EST) Date: Sat, 4 Mar 2006 13:00:15 -0500 From: Adam McDougall To: Max Laier Message-ID: <20060304180014.GB63144@egr.msu.edu> References: <20060304142802.GA63144@egr.msu.edu> <4409A975.1080108@thedarkside.nl> <200603041602.42599.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603041602.42599.max@love2party.net> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Pieter de Boer Subject: Re: PR kern/93849 IP checksum broken by pf no-df over bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 17:59:57 -0000 On Sat, Mar 04, 2006 at 04:02:26PM +0100, Max Laier wrote: On Saturday 04 March 2006 15:51, Pieter de Boer wrote: > Adam McDougall wrote: > > Could someone possibly take a look at this and let me know if it > > looks 'broken' or if I might be doing something wrong? I am in > > a crunch to choose a firewall solution within a few weeks and it > > would help me to know if this issue can be solved. FreeBSD/pf > > seemed an appropriate solution so far, especially since it has > > CARP, pfsync, (and altq which im not using (yet?)). > > You could try compiling pf using CFLAGS=-O instead of -O2. This fixed a > checksum problem I had. That probably was an entirely different issue, > but perhaps it does help.. Can you try this patch and report back instead. Thanks and sorry for the delay. Other than the double (( causing a compile error, it works! Thanks. I verified that the DF bit is clear on the other side and that the checksum changed, and is correct. From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 18:00:38 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 352D916A420 for ; Sat, 4 Mar 2006 18:00:38 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA7D143D46 for ; Sat, 4 Mar 2006 18:00:37 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 93A9D1CC54; Sat, 4 Mar 2006 13:00:56 -0500 (EST) Date: Sat, 4 Mar 2006 13:00:56 -0500 From: Adam McDougall To: Pieter de Boer Message-ID: <20060304180056.GC63144@egr.msu.edu> References: <20060304142802.GA63144@egr.msu.edu> <4409A975.1080108@thedarkside.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4409A975.1080108@thedarkside.nl> User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: PR kern/93849 IP checksum broken by pf no-df over bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 18:00:38 -0000 On Sat, Mar 04, 2006 at 03:51:33PM +0100, Pieter de Boer wrote: Adam McDougall wrote: >Could someone possibly take a look at this and let me know if it >looks 'broken' or if I might be doing something wrong? I am in >a crunch to choose a firewall solution within a few weeks and it >would help me to know if this issue can be solved. FreeBSD/pf >seemed an appropriate solution so far, especially since it has >CARP, pfsync, (and altq which im not using (yet?)). You could try compiling pf using CFLAGS=-O instead of -O2. This fixed a checksum problem I had. That probably was an entirely different issue, but perhaps it does help.. -- Pieter I tried that a few days ago when I saw mention of it for sparc64, but that did not help. The patch fixed it though. From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 19:13:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8431916A420 for ; Sat, 4 Mar 2006 19:13:23 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A2743D7F for ; Sat, 4 Mar 2006 19:13:19 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k24JD7JY001017 for ; Sat, 4 Mar 2006 22:13:07 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k24JD7Av001016 for freebsd-net@freebsd.org; Sat, 4 Mar 2006 22:13:07 +0300 (MSK) (envelope-from yar) Date: Sat, 4 Mar 2006 22:13:06 +0300 From: Yar Tikhiy To: freebsd-net@freebsd.org Message-ID: <20060304191306.GA600@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: BIND incompatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 19:13:23 -0000 Hi there, Just want to remind about a problem I've finally run into myself. There has been a lot of gossip on it, but next to no tech details. Namely, BIND8 will go nuts and spit out tons of error messages per second if its forwarder happens to be BIND9 and "forwarders only" is not in effect. The error message reads: sysquery: no addrs found for root NS I saw that after two my DNS servers had been upgraded today along their respective branches, 4-STABLE and 6-STABLE, which had involved no changes to named.conf or named.root. Has anybody got links to tech details why the trouble happens? Sorry, today I had little time for debugging and tcpdumping, just had to make sure it all worked by the end of the day :-) -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 21:09:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3607016A441 for ; Sat, 4 Mar 2006 21:09:19 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4216443D45 for ; Sat, 4 Mar 2006 21:09:18 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k24L9FHN003902; Sun, 5 Mar 2006 00:09:16 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k24L9F0c003901; Sun, 5 Mar 2006 00:09:15 +0300 (MSK) (envelope-from yar) Date: Sun, 5 Mar 2006 00:09:14 +0300 From: Yar Tikhiy To: "S.I" Message-ID: <20060304210914.GC3304@comp.chem.msu.su> References: <20060301105332.9f9a0b41.piston@otel.net> <20060303101040.208d35bb.piston@otel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060303101040.208d35bb.piston@otel.net> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: ipprecedence ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 21:09:19 -0000 On Fri, Mar 03, 2006 at 10:10:40AM +0200, S.I wrote: > Thanks for your reply i know this info from google. > The situation is I have a router with many vlans and i want to change > the ipprecedence for some networks as I don't want to check hosts in static table because > this check is too slowly for ingoing ( 40000p/s ):) for other routers behind him.This example with setsockopt(2) may be is useing for local packets?I know some kind high level switches or routers can doing that but are more expensive :). Indeed, setsockopt(2) can only control the IP precedence of packets generated by sockets opened locally, on this host. Correct me if I'm wrong, but the functionality offered, e.g., by cisco routers: route-map XX match set ip precedence XX isn't in FreeBSD. It can be implemented as a hack to ipfw or pf, but there is no general framework ready for use. When making the hack, don't forget to recompute the IP checksum after modifying the IP precedence field. > Regards > S.I > > On Wed, 1 Mar 2006 10:53:32 +0200 > "S.I" wrote: > > > How Can I set ipprecedence flag on FreeBSD? > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 21:15:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5560C16A420 for ; Sat, 4 Mar 2006 21:15:36 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A930B43D45 for ; Sat, 4 Mar 2006 21:15:33 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k24LFTFB003976; Sun, 5 Mar 2006 00:15:29 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k24LFRwF003971; Sun, 5 Mar 2006 00:15:27 +0300 (MSK) (envelope-from yar) Date: Sun, 5 Mar 2006 00:15:27 +0300 From: Yar Tikhiy To: Christopher McGee Message-ID: <20060304211526.GD3304@comp.chem.msu.su> References: <440876F1.6050804@xecu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440876F1.6050804@xecu.net> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Carp on vlan with em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 21:15:36 -0000 On Fri, Mar 03, 2006 at 12:03:45PM -0500, Christopher McGee wrote: > Carp, vlans, and em is still not supported in 5.4 release, but I have > read about a patch that works. Can anyone point me in the right direction. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=25292+0+/usr/local/www/db/text/2005/freebsd-net/20050424.freebsd-net+raw -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Mar 4 23:15:06 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15CC16A44A for ; Sat, 4 Mar 2006 23:15:06 +0000 (GMT) (envelope-from security@yourdot-mail.com) Received: from jupiter.nswebhost.com (jupiter.nswebhost.com [66.246.218.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED0743D46 for ; Sat, 4 Mar 2006 23:15:06 +0000 (GMT) (envelope-from security@yourdot-mail.com) Received: from 55-228.dial.nortenet.pt ([212.13.55.228]:34852 helo=[192.168.1.11]) by jupiter.nswebhost.com with esmtpa (Exim 4.52) id 1FFfwZ-0000NM-OQ for net@freebsd.org; Sat, 04 Mar 2006 18:13:48 -0500 Message-ID: <440A1F71.7060107@yourdot-mail.com> Date: Sat, 04 Mar 2006 23:14:57 +0000 From: "Carlos Silva, yourdot-internet.com" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - jupiter.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - yourdot-mail.com X-Source: X-Source-Args: X-Source-Dir: Cc: Subject: make error :| X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 23:15:06 -0000 Hi, i have upgraded my ports with cvsup and when installing samba i have the following error: " ... Building for libtool-1.5.22_2 ..... Making all in doc make: don't know how to make libtool14.texi. Stop. ***Error Code 1 .... " someone have any idea? best regards, carlos silva, http://www.yourdot-services.com/