From owner-freebsd-stable@FreeBSD.ORG Fri Jul 7 21:18:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46CC716A4DE; Fri, 7 Jul 2006 21:18:46 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD07543D45; Fri, 7 Jul 2006 21:18:45 +0000 (GMT) (envelope-from freebsd@hub.org) Received: from localhost (wm.hub.org [200.46.204.128]) by hub.org (Postfix) with ESMTP id AC7F1290C3A; Fri, 7 Jul 2006 18:18:41 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 75087-07; Fri, 7 Jul 2006 21:18:44 +0000 (UTC) Received: from ganymede.hub.org (blk-222-80-186.eastlink.ca [24.222.80.186]) by hub.org (Postfix) with ESMTP id 0B484290C29; Fri, 7 Jul 2006 18:18:41 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1027) id 7FCA64825E; Fri, 7 Jul 2006 18:18:46 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 7AD6847D6D; Fri, 7 Jul 2006 18:18:46 -0300 (ADT) Date: Fri, 7 Jul 2006 18:18:46 -0300 (ADT) From: User Freebsd To: Atanas In-Reply-To: <44AEB0CB.5060102@asd.aplus.net> Message-ID: <20060707181750.O1171@ganymede.hub.org> References: <20060629083130.X1229@ganymede.hub.org> <44A4A02A.9060802@thebeastie.org> <20060630012615.Q1103@ganymede.hub.org> <44A57B71.6020201@asd.aplus.net> <20060701035416.GC54876@cdnetworks.co.kr> <44AC6793.2070608@asd.aplus.net> <20060706021444.GA76865@cdnetworks.co.kr> <44AD7297.7080605@asd.aplus.net> <20060707010341.GD82406@cdnetworks.co.kr> <44ADC2ED.4070904@asd.aplus.net> <20060707040838.GE82406@cdnetworks.co.kr> <20060707151640.D51390@fledge.watson.org> <44AEB0CB.5060102@asd.aplus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pyun YongHyeon , Peter Jeremy , Robert Watson , Michael Vince , freebsd-stable@FreeBSD.org Subject: Re: em device hangs on ifconfig alias ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 21:18:46 -0000 On Fri, 7 Jul 2006, Atanas wrote: > Robert Watson said the following on 7/7/06 7:17 AM: >>> > I just left a "tcpdump -n arp host 10.10.64.40" on a third machine > >>> sniffing around and tested all em module versions I had (the stock 6.1, > >>> 6-STABLE and 6-STABLE with your patch), but got silence on all three: >>> >>> That's odd. I've tested it on CURRENT and I could see the ARP packet. Are >>> you sure you patched correctly? If so I have to build a RELENG_6 machine >>> and give it try. >> >> Is it possible you're seeing an interaction between the reset generated as >> part of IP address changing, and the time it takes to negotiate link? It's >> possible that the arp packets are being eaten during the link negotiation, >> so for systems negotiating quickly (or not at all) then the arp packet is >> seen on other hosts, and otherwise not... >> > Looks like this is exactly what happens. > > I was able to see it by running two tcpdump instances - one on the EM machine > running in background and another running elsewhere on the same subnet. > > So on the EM machine the arp packet actually gets generated by em(4) and > caught by the tcpdump running there: > > EM# tcpdump -n arp and ether src 00:04:23:b5:1b:ff & > EM# > EM# ifconfig em1 inet alias 10.10.64.40 > EM# 11:28:37.178946 arp who-has 10.10.64.40 tell 10.10.64.40 > EM# > > But it doesn't reach the other tcpdump instance running on another host. It > seems that the arp packet gets killed before leaving the EM machine, due to > the card initialization or something else. > > I tried sending it manually with arping, just to make sure both tcpdumps > operate properly and yes, the packet got delivered to both. > > I think that I have patched, built and loaded the em(4) kernel module > correctly. After applying the patch there were no rejects, before building > the module I intentionally appended " (patched)" to its version string in > if_em.c, and could see that in dmesg every time I loaded the module: > em1: Is it possible that we're going at this issue backwards? It isn't the lack of ARP packet going out that is causing the problems with moving IPs, but that delay that we're seeing when aliasing a new IP on the stack? The ARP packet *is* being attempted, but is timing out before the re-init is completing? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664