Re: Idle connections via accept_filter(9)
Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket-so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). From uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it available * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren pgpszDVfjjajb.pgp Description: PGP signature
Re: net.inet.ip.forwarding is mysteriously set to 0
Hi On 27/04/2015 06:41, Julian Elischer wrote: Basically all the setup scripts in /etc/rc.d (andaother setup scripts in /etc and /usr/local/etc) all source /etc/rc.conf and it's friends (defaults etc.) if any of thse scripts gets called (for example by devd when it notices a new interface), then the entire chain of dependencies related to that chain will be run **according to how the config files tell it to run* * and not how the current sysctls are set. if you think about it, this must be the case as htey need to change the sysctls as part of their operation. maybe we should have a script to do what you want and also uses sysrc(8) to make it permanent. I don't think this is a major problem to be honest. The issue I had back in January is that the behaviour changed with an upgrade to 10.1 from 8.something as the interaction with devd wasn't well known. I don't know how this can be dealt with unless we have a load of special-cases that log warnings when, for example, forwarding is enabled in sysctl.conf but there isn't a gateway_enable in rc.conf. That sounds like a messy solution to be honest. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 199716] em doesn't increment adapter-rx_overruns in msix mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 Mark Linimon lini...@freebsd.org changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Idle connections via accept_filter(9)
ask alfred? :) -a On 27 April 2015 at 02:22, hiren panchasara hi...@strugglingcoder.info wrote: Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket-so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). From uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it available * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Idle connections via accept_filter(9)
On 04/27/15 at 09:10P, Adrian Chadd wrote: ask alfred? :) Thanks! CCing him. -a On 27 April 2015 at 02:22, hiren panchasara hi...@strugglingcoder.info wrote: Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket-so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). From uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it available * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org pgptii7UJmfdc.pgp Description: PGP signature
Re: Idle connections via accept_filter(9)
This is over 15 years old. I currently don't know of a great solution to this problem. Might make sense to create a timer that runs and refs the socket that will occasionally fire and cleanse out the old connections. Shouldn't be that hard to do. Sent from my iPhone On Apr 27, 2015, at 9:19 AM, hiren panchasara hi...@strugglingcoder.info wrote: On 04/27/15 at 09:10P, Adrian Chadd wrote: ask alfred? :) Thanks! CCing him. -a On 27 April 2015 at 02:22, hiren panchasara hi...@strugglingcoder.info wrote: Wanted to see if someone with understanding of accept_filter can comment. cheers, Hiren On 04/09/15 at 09:08P, hiren panchasara wrote: If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket-so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). From uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it available * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 180065] [netinet6] [patch] Multicast loopback to own host broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180065 Mark Felder f...@freebsd.org changed: What|Removed |Added CC||a...@freebsd.org, ||f...@freebsd.org, ||gleb...@freebsd.org --- Comment #2 from Mark Felder f...@freebsd.org --- ae, glebius -- you seem to be active in IPv6 / multicast somewhat recently I was alerted via Twitter that a user has been applying this patch for a few years. Is it still relevant? If so, can you help get this into the tree? It doesn't seem to apply cleanly to head a the moment -- perhaps due to your recent multicast work Thanks!! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Calculating ACK arrival time
Hello, What would be the best (and easiest) way to calculate the arrival time (the time period that the ACK travels from receiver to sender of the ACK'ed data) for a NewReno ACK message? Can the h_ertt module be used to do it? Thank you in advance! Best Regards, Karlis ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[Bug 180065] [netinet6] [patch] Multicast loopback to own host broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180065 Andrey V. Elsukov a...@freebsd.org changed: What|Removed |Added Assignee|freebsd-net@FreeBSD.org |a...@freebsd.org --- Comment #3 from Andrey V. Elsukov a...@freebsd.org --- I'll take a look. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Idle connections via accept_filter(9)
On 04/27/15 at 09:39P, Alfred Perlstein wrote: This is over 15 years old. I currently don't know of a great solution to this problem. Might make sense to create a timer that runs and refs the socket that will occasionally fire and cleanse out the old connections. Shouldn't be that hard to do. Yeah, just wanted to make sure I wasn't missing anything obvious. Thanks for your input. :-) Cheers, Hiren pgpvm8IXbfAq3.pgp Description: PGP signature
