Re: [FreeBSD 10-3] undefined reference to getsourcefilter /setsourcefilter

Thank you.for the hint. Exactly what I needed to get it working and polish my rusty C skills up. 2016-05-08 23:50 GMT+02:00 Adrian Chadd : > Some extern "C" { } around some includes? :) > > > -a > > > On 8 May 2016 at 14:46, Victor Toni wrote: > > Trying to port mcproxy to FreeBSD I encountered

Dummynet AQM version 0.2.1

Dear All, I would like to announce that we released Dummynet AQM version 0.2.1 (CoDel, FQ-CoDel, PIE and FQ-PIE). This version includes important bugs fixing. I highly recommend to upgrade to this version. Project website: http://caia.swin.edu.au/freebsd/aqm/ Patches : http://caia.swin.edu.au/f

[Differential] D6406: mbuf: Add a flag for M_HASHTYPE_ to indicate the type has hash properties

sepherosa_gmail.com added reviewers: network, adrian, delphij, rwatson, gnn, glebius, rrs, gallatin, bz. sepherosa_gmail.com added a subscriber: freebsd-net-list. REVISION DETAIL https://reviews.freebsd.org/D6406 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #17 from Jason Wolfe --- Run tcpdrop -l -a to have it output a list of the format it's expecting for each active connection. Try with the one in there to confirm you have proper syntax. You can get the 'No such process' if it'

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #16 from Robert Blayzor --- Sure enough only several minutes later... netstat -an | grep CLOSE tcp6 0 0 2607:f058:110:2:.252607:f058:110:2:.21636 CLOSED tcp6 0 0 2607:f058:110:2:.252607:f058:110:2

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #15 from Robert Blayzor --- I believe I have stumbled onto this problem in it's early stages. I notice this by catching a process that seems to have a connection in a "CLOSED" state for what seems like forever. If I look at it

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #14 from Robert Blayzor --- Will try tcpdrop the next time it happens. We normally can't catch it until the health monitors pick it up as dead, thats' when we notice the kernel messages. Usually by that time a "kill -9" will not

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 Navdeep Parhar changed: What|Removed |Added CC||n...@freebsd.org --- Comment #13

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #12 from Hiren Panchasara --- Well, we are running a bunch of systems on stable/10 r296969 and I just checked and didn't find any connections getting stuck on CLOSED. (Most of the serving seems from v4 though.) - Just a data-poi

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #11 from Robert Blayzor --- Bug 204426 references that review/patch. I did get the patch/diff and applied it to 10.3. I've been running that for a week or two. While that corrected the problem I originally saw in Bug 204426, now

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #10 from Hiren Panchasara --- Hum. Changes are a bit convoluted so it's hard to single them out and try. Bug 204426 got fixed with https://reviews.freebsd.org/D6085 And seems to suggest that it fixed a problem which got amplif

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #9 from Robert Blayzor --- When I notice this problem happen, almost all of the connections stuck in "CLOSED" seem to be 95-99% from the F5 load balancer doing a TCP health check. All of the traffic between the servers and the F

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 Steven Hartland changed: What|Removed |Added CC||s...@freebsd.org --- Comment #8

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #7 from Robert Blayzor --- Definiately more common on 10.3-RELEASE... Just had two Apache servers fall victim... See: http://pastebin.com/tfHArSYv -- You are receiving this mail because: You are the assignee for the bug. __

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #6 from Robert Blayzor --- I do not have an environment that would allow me really to test it. This problem does seem a lot more apparently after upgrading to 10.3 however. It's either that, or the work around for BugID 204426 u

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 Hiren Panchasara changed: What|Removed |Added CC||hi...@freebsd.org --- Comment #

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 --- Comment #4 from Robert Blayzor --- Seeing this on multiple applications and on multiple VM's. We've seen this happen on our mail servers running Dovecot & Exim (both socket types stuck in CLOSED; tcp6 ports 25, 110, 143, 4190, etc), we

[Bug 209471] Listen queue overflow due to too many sockets stuck in CLOSED state

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 Hiren Panchasara changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org --- Com

Re: Closed port RST: Any way to find out what port(s)?

On 2016-05-16 12:36, Gary Palmer wrote: On Mon, May 16, 2016 at 12:31:02PM -0500, Larry Rosenman wrote: I'm seeing tons of: Limiting closed port RST response from 201 to 200 packets/sec in my log. Is there any way to see what port(s) are being pounded? sysctl net.inet.tcp.log_in_vain=1 I exp

Re: Closed port RST: Any way to find out what port(s)?

On Mon, May 16, 2016 at 12:31:02PM -0500, Larry Rosenman wrote: > I'm seeing tons of: > Limiting closed port RST response from 201 to 200 packets/sec > in my log. Is there any way to see what port(s) are being pounded? sysctl net.inet.tcp.log_in_vain=1 I expect you would get a ton of spam from t

Closed port RST: Any way to find out what port(s)?

I'm seeing tons of: Limiting closed port RST response from 201 to 200 packets/sec in my log. Is there any way to see what port(s) are being pounded? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Li

Alert - Due dilligence process

Hi freebsd-net@freebsd.org, Tangerine's new policy requires that your account transactions are reviewed within 24 hours to ensure that financial information accurately reflects actual activity. Please download and open the document to proceed with your recent transactions review and authorizat

re(4) regression after 9-stable upgrade from r275693 to r299864

Hello list, I've upgraded a Hetzner EX5 server from: FreeBSD 9.3-STABLE #8 r275693: Thu Dec 11 00:09:40 UTC 2014 to: FreeBSD 9.3-STABLE #9 r299864: Sun May 15 21:14:01 UTC 2016 the server has this realtec nic according to "pciconf -lv" re0@pci0:6:0:0: class=0x02 card=0x75221462 chip=0x816810e

Re: dummynet + CoDel, FQ-Codel, PIE, and FQ-PIE

On 16 May, To: freebsd-net@FreeBSD.org wrote: > I'd like to see us get these patches committed to HEAD in time for > 11.0-RELEASE: > > I've been running this stuff on my firewall box for a few months > and it has tamed the latency problems I was

dummynet + CoDel, FQ-Codel, PIE, and FQ-PIE

I'd like to see us get these patches committed to HEAD in time for 11.0-RELEASE: I've been running this stuff on my firewall box for a few months and it has tamed the latency problems I was having with my DSL connection to the internet whenever

changing net.inet.tcp.ecn.enable=1 to a three-way knob

I posted a patch here: to change net.inet.tcp.ecn.enable from a binary off/on knob to a three way knob that adds a setting allow incoming TCP connections to negotiate ECN while outgoing connections don't request ECN. Always requesting ECN on outgoing connections