Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Jul 2006 12:06:51 -0700
From:      Atanas <atanas@asd.aplus.net>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        Pyun YongHyeon <pyunyh@gmail.com>, Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-stable@FreeBSD.org, Michael Vince <mv@thebeastie.org>, User Freebsd <freebsd@hub.org>
Subject:   Re: em device hangs on ifconfig alias ...
Message-ID:  <44AEB0CB.5060102@asd.aplus.net>
In-Reply-To: <20060707151640.D51390@fledge.watson.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched)>

Regards,
Atanas




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AEB0CB.5060102>