From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 15:29:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69B51065674 for ; Wed, 23 Jul 2008 15:29:55 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9186B8FC1A for ; Wed, 23 Jul 2008 15:29:55 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from barbar.netasq.com (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 6219C226D6; Wed, 23 Jul 2008 17:29:54 +0200 (CEST) Message-ID: <48874E63.7070603@netasq.com> Date: Wed, 23 Jul 2008 17:29:39 +0200 From: Damien Deville User-Agent: Thunderbird 2.0.0.14 (X11/20080610) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <4886474D.5030300@samoylyk.sumy.ua> <48864B6C.9030404@samoylyk.sumy.ua> <4886DE83.5080100@netasq.com> <48874C7C.5070402@samoylyk.sumy.ua> In-Reply-To: <48874C7C.5070402@samoylyk.sumy.ua> Content-Type: multipart/mixed; boundary="------------090808070204070709050008" Cc: freebsd-net@freebsd.org Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: damien.deville@netasq.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:29:55 -0000 This is a multi-part message in MIME format. --------------090808070204070709050008 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Hi, after some more tests here is what i came to (patch provided is for freebsd 6.3 but can be adapted for other versions): it is a dirty hack and might not be the right solution but it is working in the case i described earlier and i hope it will help discussing the issue. It seems that the process that block read all entries available in the PF_ROUTE socket, do not find the one it is looking for and ends blocked on the PF_ROUTE socket as no more entries are available after reading and entry with rtm->rtm_pid == 0 and rtm->rtm_seq == 0. Damien Oleksandr Samoylyk wrote: > Damien Deville wrote: >> Hi, >> >> we are facing a similar issue with arp blocked in sbwait state. >> >> Here is a way to reproduce it: >> - add a bunch of arp entries in your arp table (best is around 255 >> entries). >> - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') >> >> Both processes will be in concurence to access the table. One process >> will successfully nuke all entries of the arp table, the other one >> will be blocked in rtmsg function on the read while executing a >> RTM_GET or RTM_DELETE command after some time. By instrumenting arp we >> noticed that it happened when both process access to the same entry. >> >> Here is a backtrace of the blocked arp on FreeBSD 7.0 >> >> (gdb) bt >> #0 0x28158f81 in read () from /lib/libc.so.7 >> #1 0x08049091 in rtmsg () >> #2 0x08049b44 in delete () >> #3 0x0804a1fd in nuke_entry () >> #4 0x08049a77 in search () >> #5 0x08049e75 in main () >> >> I can reproduce this on FreeBSD 4.11, 6.2 and 6.3, and FreeBSD 7.0. > > Any workaround so far? > -- Damien Deville R&D engineer damien.deville@netasq.com http://www.netasq.com NETASQ - We secure IT --------------090808070204070709050008 Content-Type: text/plain; name="arp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arp.diff" --- arp.c.orig 2006-10-21 07:43:29.000000000 +0200 +++ arp.c 2008-07-23 10:41:44.000000000 +0200 @@ -706,17 +706,28 @@ l = rtm->rtm_msglen; rtm->rtm_seq = ++seq; rtm->rtm_type = cmd; if ((rlen = write(s, (char *)&m_rtmsg, l)) < 0) { if (errno != ESRCH || cmd != RTM_DELETE) { warn("writing to routing socket"); return (NULL); } } do { l = read(s, (char *)&m_rtmsg, sizeof(m_rtmsg)); + if ( l > 0 && rtm->rtm_seq == 0 && rtm->rtm_pid == 0 ) + return (NULL); /* something weird happened */ } while (l > 0 && (rtm->rtm_seq != seq || rtm->rtm_pid != pid)); if (l < 0) warn("read from routing socket"); return (rtm); } --------------090808070204070709050008--