Date: Wed, 23 Jul 2008 17:29:39 +0200 From: Damien Deville <damien.deville@netasq.com> To: Oleksandr Samoylyk <oleksandr@samoylyk.sumy.ua> Cc: freebsd-net@freebsd.org Subject: Re: proxy-arp & mpd Message-ID: <48874E63.7070603@netasq.com> In-Reply-To: <48874C7C.5070402@samoylyk.sumy.ua> References: <4886474D.5030300@samoylyk.sumy.ua> <48864B6C.9030404@samoylyk.sumy.ua> <4886DE83.5080100@netasq.com> <48874C7C.5070402@samoylyk.sumy.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48874E63.7070603>