Hi Matthew,
> 1. Why does your dump claim there are packets with bad checksums? This
> looks like an issue with the TCP/IP stack on either client or server or
> both, or maybe incorrect decoding/verification of the checksums by
> ethereal, or the network connectivity is *really* bad and that isn't being
> corrected at the transport layer (or some other layer) for some reason. I
> think this should be investigated.
I dumped the traffic of a successful "local" commit and it shows "checksum
incorrect" for each packet sent by the client. I dumped it on the client, so
there is no interference with the network. Thus, i suppose it is some
Ethereal bug, would you agree?
Can it be that checksum computation is done on hardware and the software
beforehand just fills it with random bytes?
> Could it be that when you access the repository remotely, you do so using
> some gateway or firewall or something which you don't use in other
> circumstances, and that gateway or whatever is corrupting the packets so
> that their checksums don't match?
We have a packetshaper in between dropping packets depending on the load.
But this should be transparent to Apache / SVN isn't it?
> If you use PPP or a VPN or something when connecting from your 'remote
> sites', I would expect that thing to do its own error correction, so the
> eventual decapsulated TCP/IP over Ethernet traffic on your LAN that you
> captured and emailed should have correct checksums. And it doesn't.
We have no PPP or VPN but a couple of switches and other stuff. I am about
to find out details.
> If the checksums are bad too often, it would make sense for the receiving
> end's TCP/IP stack to despair and reset the connection.
> 2. From looking at some Apache 2 source linked from Google's results page
> for 'could not get next bucket brigade', it looks like that error is
> printed when the DAV module cannot read the client's request data,
> probably because the TCP connection was reset. So I think it's just a
> symptom of the previous problem, not in itself a problem, so it should be
> ignored.
So in the end it would be good to see what the server receives and not what
the client sends. I try to get that asap.
Unfortunately, the remote host is hard to access and i therefore cannot
easily reproduce the error :(
> HTH,
Thanks,
Klaus
>
> --matt
>
> Matthew Sanderson
> Senior Programmer (UNIX)
> TCG Information Systems Pty Ltd
> Sydney, Australia
> matthew@formtrap.com
> http://www.formtrap.com/
> +61 (02) 8303 2407
>
> On Tue, 12 Jul 2005, Klaus Fehlker wrote:
>
> > > --- Ursprüngliche Nachricht ---
> > > Von: kfogel@collab.net
> > > An: "Klaus Fehlker" <lythie_ng@gmx.net>
> > > Kopie: users@subversion.tigris.org
> > > Betreff: Re: What causes "Connection reset by peer" errors?
> > > Datum: 11 Jul 2005 10:27:33 -0500
> > >
> > > "Klaus Fehlker" <lythie_ng@gmx.net> writes:
> > > > sorry to bother you with this again but i am still stuck. Can
> somebody
> > > say
> > > > if this is the right mailing list or is it rather a problem of
> Apache,
> > > or
> > > > even our network? As the subject says i have no idea what causes
> this
> > > > "connection reset by peer" error.
> > > >
> > > > Any hint that brings me further is very much welcome!
> > >
> > > This is just a wild guess, possibly totally wrong, but have you tried
> > > playing with the 'http-timeout' parameter in your
> > > ~/.subversion/servers configuration file?
> >
> > Hm, haven't tried it, yet, but could a bad client configuration make the
> > server send Resets?
> > What is SVN's usual behavior when the server sends a reset? Do you know
> what
> > can cause a server sending a reset?
> >
> > Klaus
> >
> > > > > -----Original Message-----
> > > > > From: Klaus Fehlker [mailto:lythie_ng@gmx.net]
> > > > > Sent: Mittwoch, 29. Juni 2005 18:13
> > > > > To: users@subversion.tigris.org
> > > > > Subject: What causes "Connection reset by peer" errors?
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have problems using my repository from certain locations. I use
> > > Apache
> > > > > 2.0.54 with Subversion 1.1.4 on server-side and 1.2.0 on
> client-side.
> > > I
> > > > > use
> > > > > it from within the LAN as well as from remote sites with a poor
> > > network
> > > > > connection.
> > > > >
> > > > > Unfortunately, large commits from the remote site sometimes break
> with
> > > the
> > > > > message "Connection reset by peer". The Apache logs tell that the
> > > server
> > > > > could not get the next buckade brigade - whatever that means?!
> > > > >
> > > > > I suspect it to be some kind of network error but do not really
> know
> > > how
> > > > > to
> > > > > make sure. There is no proxy in between.
> > > > >
> > > > > Below i appended the network traffic dumped with Ethereal
> > > (165.72.165.25 =
> > > > > server). In frame 236629 the client sents a DELETE
> > > *somethingcryptical*
> > > > > but
> > > > > the commit only consists of adds. Does that have to do with the
> error?
> > > > >
> > > > > Many thinks for any help,
> > > > > Klaus
> > > > >
> > > > > From Apache error log:
> > > > > [Tue Jun 28 17:05:17 2005] [info] [client 2.33.109.115] Access
> > > granted:
> > > > > 'kFehlker' PUT
> > > > >
> NPS-Application:/NPS0.1_trunk/infrastructure/tools/TMS-development-
> > > > >
> environment/envdev/eclipse/plugins/org.eclipse.debug.ui_3.0.1/dtui.jar
> > > > > [Tue Jun 28 17:05:20 2005] [error] [client 2.33.109.115]
> > > (104)Connection
> > > > > reset by peer: Could not get next bucket brigade [500, #0]
> > > > > [Tue Jun 28 17:05:20 2005] [info] (32)Broken pipe:
> core_output_filter:
> > > > > writing data to the network
> > > > > [Tue Jun 28 17:05:20 2005] [debug] mod_auth_ldap.c(337): [client
> > > > > 2.33.109.115] [20767] auth_ldap authenticate: using URL
> > > > > ldap://ldap.dhl.com:389/o=dhl.com
> > > > > [Tue Jun 28 17:05:20 2005] [debug] mod_auth_ldap.c(411): [client
> > > > > 2.33.109.115] [20767] auth_ldap authenticate: accepting kFehlker
> > > > > [Tue Jun 28 17:05:20 2005] [info] [client 2.33.109.115] Access
> > > granted:
> > > > > 'kFehlker' DELETE NPS-Application:
> > > > >
[..]
--
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 13 16:35:56 2005