From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 17:50:27 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176DA16A421 for ; Wed, 31 Oct 2007 17:50:27 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id E32A513C481 for ; Wed, 31 Oct 2007 17:50:26 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l9VGpAH9028371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Oct 2007 09:51:10 -0700 X-Auth-Received: from [127.0.0.1] (cs213-46.fsmodem.washington.edu [140.142.173.47]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id l9VGp3hv005739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 09:51:06 -0700 Message-ID: <4728B256.5080005@u.washington.edu> Date: Wed, 31 Oct 2007 09:50:30 -0700 From: Garrett Cooper User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Judge References: <20071019182349.J97691@odysseus.silby.com> <47194EA1.8000402@u.washington.edu> <20071019212012.C97691@odysseus.silby.com> <47202922.3070700@u.washington.edu> <47209570.20609@tomjudge.com> <4723330A.7070803@u.washington.edu> In-Reply-To: <4723330A.7070803@u.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.10.31.93000 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Cc: net@freebsd.org Subject: Re: Marvell chipsets on 8-CURRENT and XP x64 won't talk with one another 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, 31 Oct 2007 17:50:27 -0000 Garrett Cooper wrote: > Tom Judge wrote: >> Garrett Cooper wrote: >>> Mike Silbersack wrote: >>>> >>>> On Fri, 19 Oct 2007, Garrett Cooper wrote: >>>> >>>>>> Just to clarify, how are the two hooked together? Is it over >>>>>> gigabit switch, a 10mbps hub, or directly cabled together? >>>>>> >>>>>> -Mike >>>>> >>>>> Sure. They're both connected over a gigabit switch, but the >>>>> Windows driver's kind of sketchy because it keeps on switching >>>>> between 100MBit and 1GBit. I haven't really paid that much >>>>> attention to what speed the FreeBSD msk driver is registering at. >>>>> -Garrett >>>> >>>> Ah ha! >>>> >>>> I had the flopping between 100mbps and 1gbps problem with some >>>> Intel cards once - some of the machines in the lab were fine, >>>> others kept switching back and forth. We eventually narrowed it >>>> down to the cables we had hand-made; some of them just weren't up >>>> to snuff, and the NIC apparently decided that it had to go back >>>> down to 100. >>>> >>>> I think you should switch your gigabit switch out for a 100mbps >>>> switch and see if the network becomes more reliable. >>>> >>>> -Mike >>> >>> I think I've discovered what the issue is. I believe the problem >>> lies in the fact that the FreeBSD Marvell chipset driver (msk) isn't >>> up to speed with the Gigabit transferring on my particular >>> chipset(s). That's why transfers were most likely working with my >>> laptop (Apple with 100MBit Broadcom) vs my desktop (Asus MB with >>> another Marvell chipset driver) and another laptop (Dell laptop with >>> Broadcom Gigabit). >>> How do I tell ifconfig via rc.conf to downgrade the max speed to >>> 100MBit duplex? >>> Thanks, >>> -Garrett >> >> You would need to hard code the interface configuration on the switch >> and box. This is only possible if you have a managed switch and the >> methods on the switch are manufacturer and model dependent. >> >> On FreeBSD however it is trivial for example "ifconfig em0 media >> 100baseTX mediaopt full-duplex". >> >> This will disable speed negotiation and therefore must be configured >> at both ends of the link. >> >> Tom > > Well, this is interesting. I used a crappy switch (100MBit SOHO > switch), in place of my Netgear non-managed gigabit switch, and the > same thing occurred on the XP x64 machine. > > I may have forgotten to mention that at one time both machines were > running XP variants of some sort (x64 and x86), and they worked > perfectly fine with one another >_>... > > Here's some additional info: > > optimus# arp -a > ? (192.168.0.1) at (incomplete) on msk0 [ethernet] # Dummy gateway > ? (192.168.0.42) at 00:11:24:2f:15:bc on msk0 [ethernet] # iBook > (broadcom adapter) > ? (192.168.0.47) at 00:1a:92:d2:f7:f6 on msk0 [ethernet] # Win XP x64 > machine > ? (192.168.0.255) at ff:ff:ff:ff:ff:ff on msk0 permanent [ethernet] > optimus# ifconfig msk0 > msk0: flags=8843 metric 0 mtu > 1500 > options=9a > ether 00:1b:fc:45:9b:5c > inet 192.168.0.45 netmask 0xffffff00 broadcast 255.255.255.0 > media: Ethernet autoselect (100baseTX ) > status: active > ifconfig_msk0="inet 192.168.0.45 broadcast 255.255.255.0" > # media 100baseTX mediaopt full-duplex" > defaultrouter="192.168.0.1" > optimus# netstat -nr > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.0.1 UGS 0 0 msk0 > 127.0.0.1 127.0.0.1 UH 0 12 lo0 > 192.168.0.0/24 link#1 UC 0 0 msk0 > 192.168.0.1 link#1 UHLW 2 0 msk0 > 192.168.0.42 00:11:24:2f:15:bc UHLW 1 179 msk0 > 1028 > 192.168.0.47 00:1a:92:d2:f7:f6 UHLW 1 21 msk0 > 1162 > 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWb 1 49 msk0 > > arp and everything's show the correct information on the XP end, even > after I removed the 'dummy gateway' on both machines.. > > Next course of action? Snort? tcpdump? > > Thanks, > -Garrett I'm running tcpdump on my Mac and I noted a lot of 'bad checksums' (0x081c was the official error in all cases), then consulted the msk driver. It appears that there's a bug with Yukon II chipsets with the hardware checksumming and I wonder whether or not the chipset that I have is affected by this issue as well. I'll provide my chipset/model info in my next reply (can't access it from this PC). -Garrett