Re: Dummynet Broke fragmets in 5.x and 6.x
This problem exist in 5.x and 6.x implementations i wrote the email to luiggi for this problem but no answer yet , there is a problem with fragmented traffic that going throut pipes, dummynet whithout a problem change the ids of the framents and with this prevent reassembling of the fragments , this is true not only for icmp udp icmp its true for all ip traffic. br, CCNP Atanas Yankov Network Administrator AngelSoft Ltd. Alvaro Saurin wrote: On 5 Dec 2005, at 14:41, Spadge wrote: Alvaro Saurin wrote: The problem comes here: if I 'ping' between these two machines, everything is fine, but if I 'ping' with a packet size of, ie, 2000, no packets arrive at the receiver. Does it have to do with fragmented packets? Do I have to include any other rule for dealing with fragments? 65100 00 deny log logamount 5000 ip from any to any frag Does this not effectively kill all frags? Are your unreceived packets showing up in the log? And if not, are you sure that it's BSD4 that's losing them, and not ubuntu3? Here's how my firewall handles frags: # Allow IP fragments to pass through /sbin/ipfw add pass all from any to any frag You may also want to set up something similar to handle ICMP. I've not used dummynet pipes in ages, I wonder if setting a larger queue would help with my disconnect problems, or whether I really do just need to give up and reinstall the entire OS. Thank you, you're right, but adding something like 'pass all from any to any frag' does not put the IICMP packets through the dummynet pipe. I am not specially interested in 'ping's, but it happens the same for UDP traffic... The problem is that, if I put ICMP/UDP/etc traffic through a pipe, it doesn't work when packets are fragmented. And letting fragments out of the pipe does not improve things... Any idea? Thanks. Alvaro ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange timeout error returned by kevent() in 6.0
On Thu, 1 Dec 2005, Igor Sysoev wrote: On Thu, 1 Sep 2005, Igor Sysoev wrote: On Thu, 1 Sep 2005, Igor Sysoev wrote: I found strange timeout errors returned by kevent() in 6.0 using my http server named nginx. The nginx's run on three machines: two 4.10-RELEASE and one 6.0-BETA3. All machines serve the same content (simple cluster) and each handles about 200 requests/second. On 6.0 sometimes (2 or 3 times per hour) in the daytime kevent() returns EV_EOF in flags and ETIMEDOUT in fflags, nevertheless: 1) nginx does not set any kernel timeout for sockets; 2) the total request time for such failed requests is small, 30 and so seconds. I have changed code to ignore the ETIMEDOUT error returned by kevent() and found that subsequent sendfile() returned the ENOTCONN. By the way, why sendfile() may return ENOTCONN ? I saw this error code on 4.x too. Recently I've found that kevent() in FreeBSD 5.4 may return wrong the ETIMEDOUT too. Also I've found that recv() on FreeBSD 6.0 may return wrong ETIMEDOUT error for socket that has no any kernel timeout. It seems this ETIMEDOUT error masks another error. It's seems that this ETIMEDOUT is caused by a retransmit failure, when data were retransmited 12 times with backoff timeout. The whole timeout is small, 30-50 seconds, because the initial RTO is very small: 5-10 ms. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange timeout error returned by kevent() in 6.0
Igor Sysoev wrote this message on Thu, Sep 01, 2005 at 18:26 +0400: > On Thu, 1 Sep 2005, Igor Sysoev wrote: > > >I found strange timeout errors returned by kevent() in 6.0 using > >my http server named nginx. The nginx's run on three machines: > >two 4.10-RELEASE and one 6.0-BETA3. All machines serve the same > >content (simple cluster) and each handles about 200 requests/second. > > > >On 6.0 sometimes (2 or 3 times per hour) in the daytime kevent() > >returns EV_EOF in flags and ETIMEDOUT in fflags, nevertheless: > > > >1) nginx does not set any kernel timeout for sockets; > >2) the total request time for such failed requests is small, 30 and so > >seconds. > > I have changed code to ignore the ETIMEDOUT error returned by kevent() > and found that subsequent sendfile() returned the ENOTCONN. > > By the way, why sendfile() may return ENOTCONN ? > I saw this error code on 4.x too. The reason that you are seeing ETIMEDOUT/ENOTCONN is that the connection probably ETIMEDOUT (aka timed out)... and so is ENOTCONN (no longer connected).. can you also do a read or a write to the socket successfully? and sendfile(3) says: ERRORS [...] [ENOTCONN] The s argument points to an unconnected socket. and a glance at tcp(4) says: ERRORS [...] [ETIMEDOUT]when a connection was dropped due to excessive retransmissions; There's the answers... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange timeout error returned by kevent() in 6.0
On Tue, 6 Dec 2005, John-Mark Gurney wrote: Igor Sysoev wrote this message on Thu, Sep 01, 2005 at 18:26 +0400: On Thu, 1 Sep 2005, Igor Sysoev wrote: I found strange timeout errors returned by kevent() in 6.0 using my http server named nginx. The nginx's run on three machines: two 4.10-RELEASE and one 6.0-BETA3. All machines serve the same content (simple cluster) and each handles about 200 requests/second. On 6.0 sometimes (2 or 3 times per hour) in the daytime kevent() returns EV_EOF in flags and ETIMEDOUT in fflags, nevertheless: 1) nginx does not set any kernel timeout for sockets; 2) the total request time for such failed requests is small, 30 and so seconds. I have changed code to ignore the ETIMEDOUT error returned by kevent() and found that subsequent sendfile() returned the ENOTCONN. By the way, why sendfile() may return ENOTCONN ? I saw this error code on 4.x too. The reason that you are seeing ETIMEDOUT/ENOTCONN is that the connection probably ETIMEDOUT (aka timed out)... and so is ENOTCONN (no longer connected).. can you also do a read or a write to the socket successfully? At least recv() returns ETIMEDOUT. I could not test write() right now. and sendfile(3) says: ERRORS [...] [ENOTCONN] The s argument points to an unconnected socket. and a glance at tcp(4) says: ERRORS [...] [ETIMEDOUT]when a connection was dropped due to excessive retransmissions; There's the answers... Yes, it seems that ETIMEDOUT is retransmission failure. I've seen it in experiment. The strangeness is that I did not see this error on 4.10. Only on 6.0 and recenty on 4.11. May be I will upgrade cluster machine from 4.10 to 4.11 to see changes. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
