Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Feb 2005 11:15:52 +0100
From:      "=?iso-8859-15?Q?Jos=E9?= M. =?iso-8859-15?Q?Fandi=F1o?=" <freebsd4@fadesa.es>
To:        freebsd-stable@freebsd.org
Subject:   Re: 50% of packets lost only on local interfaces
Message-ID:  <42073FD8.5CCA7EC5@fadesa.es>
References:  <41FE7524.7E907BE@fadesa.es><41FFC6FC.CF97314C@fadesa.es>

next in thread | previous in thread | raw e-mail | index | archive | help
"Jos=E9 M. Fandi=F1o" wrote:
> =

> Chris wrote:
> >
> > Have tested on 3 boxes.
> =

> yes, it's the intended operation and If I don't see it I don't
> believe it but it happens. I ever thought it would be possible.

Finally, I found the culprit:

CFLAGS=3D""     \  100% of the transmited traffic is received
COPTFLAGS=3D""  / =


CFLAGS=3D -pipe     \  50% of the transmited traffic is received
COPTFLAGS=3D -pipe  /

CFLAGS=3D -O -pipe     \  100% of the transmited traffic is received
COPTFLAGS=3D -O -pipe  /

> The weirdest is that it worked in 5.3-RELEASE and some time later,
> whilst I was tracking -stable, aplications began to fail local
> network conections. Simple tests with ping showed me as the kernel
> receive packets (tcpdump seems to see inbound packets) but ignores
> exacly 50% of them. This makes any sense to someone?
> =

> Following the proposed solution for kern/72022 I removed /usr/obj,
> all possible harmful options in make.conf and compiled world and
> a GENERIC kernel again without any luck.
> =

> > grep '^[^#]' /etc/make.conf
> CFLAGS=3D -pipe
> COPTFLAGS=3D -pipe
> NOPROFILE=3D      true    # Avoid compiling profiled libraries
> X_WINDOW_SYSTEM=3Dxorg
> PERL_VER=3D5.8.5
> PERL_VERSION=3D5.8.5
> PERL_ARCH=3Dmach
> NOPERL=3Dyo
> NO_PERL=3Dyo
> NO_PERL_WRAPPER=3Dyo
> SENDMAIL_CFLAGS=3D-I/usr/local/include -DSTARTTLS -DSASL=3D2 -DMILTER  =
-DLDAPMAP
> SENDMAIL_LDFLAGS=3D -L/usr/local/lib
> SENDMAIL_LDADD=3D-lsasl2 -lssl -lcrypto -lldap -llber
> =

> I'm lost here, any help will be welcome.
> =

> Regards,
> =

> > 5.3-STABLE compiled Jan 5th
> >
> > --- 127.0.0.1 ping statistics ---
> > 61 packets transmitted, 61 packets received, 0% packet loss
> > round-trip min/avg/max/stddev =3D 0.062/0.073/0.146/0.013 ms
> >
> > 5.3-STABLE amd64 build compiled Jan 29th
> >
> > --- 127.0.0.1 ping statistics ---
> > 60 packets transmitted, 60 packets received, 0% packet loss
> > round-trip min/avg/max/stddev =3D 0.024/0.030/0.048/0.005 ms
> >
> > 5.3-Release-P5
> >
> > --- 127.0.0.1 ping statistics ---
> > 60 packets transmitted, 60 packets received, 0% packet loss
> > round-trip min/avg/max/stddev =3D 0.057/0.089/0.167/0.017 ms
> >
> > On Mon, 31 Jan 2005 19:12:52 +0100, Jos=E9 M. Fandi=F1o <freebsd4@fad=
esa.es> wrote:
> > > Hello,
> > >
> > > It sounds weird but tcp/ip traffic directed to _local_ interfaces,
> > > and only _local_ interfaces, always cause 50% of packets lost. Of
> > > course there isn't packet filters activated.
> > >
> > > I'm running -stable (the last update was this past weekend)
> > >
> > > There is another report like this:
> > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3Dkern/72022
> > > but the suggested solution doesn't works in my case.
> > >
> > > ping to local interfaces get replies for 50% of the packets:
> > >
> > > > ping -c 512 127.0.0.1
> > > [snip]
> > > --- 127.0.0.1 ping statistics ---
> > > 512 packets transmitted, 257 packets received, 49% packet loss
> > > round-trip min/avg/max/stddev =3D 0.046/0.049/0.077/0.004 ms
> > >
> > > > ping -c 512 10.20.30.2
> > > [snip]
> > > --- 10.20.30.2 ping statistics ---
> > > 512 packets transmitted, 254 packets received, 50% packet loss
> > > round-trip min/avg/max/stddev =3D 0.017/0.049/0.071/0.004 ms
> > >
> > > Also running tcpdump on localhost shows as the kernel stop from
> > > responding to packets without an apparent motive.
> > >
> > > > tcpdump -n -i lo0
> > > tcpdump: verbose output suppressed, use -v or -vv for full protocol=
 decode
> > > listening on lo0, link-type NULL (BSD loopback), capture size 96 by=
tes
> > > [snip]
> > > 17:58:15.516451 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 76
> > > 17:58:15.516476 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 7=
6
> > > 17:58:16.517321 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 77
> > > 17:58:16.517347 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo reply seq 7=
7
> > > 17:58:17.518158 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 78
> > > 17:58:18.519042 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 79
> > > 17:58:19.519853 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 80
> > > 17:58:20.520698 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 81
> > > 17:58:21.521548 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 82
> > > 17:58:22.522392 IP 127.0.0.1 > 127.0.0.1: icmp 64: echo request seq=
 83
> > >
> > > more tests, to the lan router:
> > >
> > > > ping -c 500 10.20.30.6
> > > [snip]
> > > --- 10.20.30.6 ping statistics ---
> > > 500 packets transmitted, 500 packets received, 0% packet loss
> > > round-trip min/avg/max/stddev =3D 1.565/2.015/40.189/2.385 ms
> > >
> > > from the lan router:
> > >
> > > Router#ping
> > > Protocol [ip]:
> > > Target IP address: 10.20.30.2
> > > Repeat count [5]: 500
> > > Datagram size [100]:
> > > Timeout in seconds [2]:
> > > Extended commands [n]:
> > > Sweep range of sizes [n]:
> > > Type escape sequence to abort.
> > > Sending 500, 100-byte ICMP Echos to 10.20.30.2, timeout is 2 second=
s:
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!
> > > !!!!!!!!!!
> > > Success rate is 99 percent (498/500), round-trip min/avg/max =3D 1/=
2/12 ms
> > >
> > > I don't find any explanation for this, but I'd like to know if ther=
e is
> > > any solution?
> > >
> > > Thank you.
> > >
> > > I put the whole test (dmesg, make.conf, etc)in this URL so you can =
see
> > > all numbers.
> > > http://195.55.55.164/tests/FreeBSD/report.txt

-- =

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d- s+:+() a- C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w---
O+ M+ V- PS+ PE+ Y++ PGP+>+++ t+ 5 X+$ R- tv-- b+++ DI D++>+++
G++ e- h+(++) !r !z
------END GEEK CODE BLOCK------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42073FD8.5CCA7EC5>