SO_LINGER + shutdown(2)

I was somewhat surprised to see that calling shutdown(SHUT_WR) on a TCP socket with SO_LINGER set {.l_onoff = 1, .l_linger = 0} does not in fact flush the send queue orderly, but immediately RST's the connection. I realize this is an issue for the Dept. of deep TCP arcanæ and not something to be

Re: Signal sensitivity problem with if_rum

On 5/1/09, Gustau Perez wrote: > > Hi, > > I think this is right place to post, if it is not, please let me know. > >I'm experiencing problems with two different devices using if_rum. > One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC > > The first one is about sensi

LOR in ip6_output() and MLDv2

Hi all, There is a Lock Order Reversal in ip6_output(), which is triggered by the MLDv2 code. What's the best way to resolve? IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of it -- ip6_output() will take an exclusive lock by way of in6_setscope(), which is needed as

Re: SO_LINGER + shutdown(2)

On May 1, 2009, at 6:11 AM, Poul-Henning Kamp wrote: I was somewhat surprised to see that calling shutdown(SHUT_WR) on a TCP socket with SO_LINGER set {.l_onoff = 1, .l_linger = 0} does not in fact flush the send queue orderly, but immediately RST's the connection. I realize this is an issue

Request feedback on IPv6 multicast listen on ::

During the MLDv2 refactoring, I removed some old KAME code which supports the ability to listen to *all* multicast groups. It isn't clear to me whether this code was still in use, and I couldn't find information about it in the normative RFCs (2292, 3542) for IPv6 stack implementation. This ca

Slow local TCP transfers on -CURRENT

I've been seeing this for a few months now on -CURRENT. TCP transfers to local IP addresses (but not 127.0.0.1) are incredibly slow. Transfer from localhost: # scp "r...@127.0.0.1:/boot/kernel/kernel" . kernel 100 %

Re: Signal sensitivity problem with if_rum

There is several places where bbp17 is changed. Editing the code looking for calls to the function rum_bbp_write, I've been able to find where bbp17 is changed at init. Changing rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14 doesn't seem to affect its behaviou

Re: Interrupts + Polling mode (similar to Linux's NAPI)

--- On Thu, 4/30/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cord...@yahoo.com > Cc: "FreeBSD Net" > Date: Thursday, April 30, 2009, 11:51 AM > 2009/4/30 Barney Cordoba : > > Its one of the sad truths of FreeBS

Attn: Beneficiary....

Anti-Terrorist and Monitory Crimes Division. Federal Bureau Of Investigation. Attn: Beneficiary, This is to Officially Inform you that it has come to our notice and we have thoroughly investigated by the help of our Intelligence Monitoring Network System that you are having a Legal Transacti

Re: Signal sensitivity problem with if_rum

On 5/1/09, Gustau Perez wrote: > >> There is several places where bbp17 is changed. >> >> > >Editing the code looking for calls to the function rum_bbp_write, > I've been able to find where bbp17 is changed at init. Changing > rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or

Re: Request feedback on IPv6 multicast listen on ::

At Fri, 01 May 2009 18:33:50 +0100, Bruce Simpson wrote: > During the MLDv2 refactoring, I removed some old KAME code which > supports the ability to listen to *all* multicast groups. > It isn't clear to me whether this code was still in use, and I couldn't > find information about it in the no

Re: Interrupts + Polling mode (similar to Linux's NAPI)

2009/5/2 Barney Cordoba : > I think its unlikely that a commercial implementation is going to > be of much use generally, as with a mutex based OS you're going to > have to do heavy specialization to get the results  you want. For > example a web server, transparent firewall and router would requi