Hello, I am having some trouble with some users connecting to my ngIRCd server - this only seems to affect some users.
Here's an extract from my log:
Apr 28 10:46:39 jupiter ngircd[1600]: Accepted connection 13 from 58.160.178.xxx:54009 on socket 10. Apr 28 10:46:39 jupiter ngircd[14258]: Can't resolve "CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au": Name or service not known Apr 28 10:46:39 jupiter ngircd[14258]: Possible forgery: 58.160.178.xxxresolved to CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au (which has no ip address) Apr 28 10:46:39 jupiter ngircd[1600]: New TLSv1 connection using cipher AES128-SHA on socket 13. Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" registered (connection 13). Apr 28 10:46:39 jupiter ngircd[1600]: Write buffer overflow (connection 13, size 4036 byte)! Apr 28 10:46:39 jupiter ngircd[1600]: Shutting down connection 13 (Write buffer overflow!) with 58.160.178.xxx:54009 ... Apr 28 10:46:39 jupiter ngircd[1600]: SSL connection 13 shutting down ... Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" unregistered (connection 13): Write buffer overflow! Apr 28 10:46:39 jupiter ngircd[1600]: Connection 13 with 58.160.178.xxx:54009 closed (in: 0.0k, out: 11.9k).
My interpretation of the log is that the client is exceeding ngIRCd's buffer size - can this parameter be tuned, or is this a misbehaving (outside of RFC) client?
Terry.
Hi Terry!
On Thu, 28 Apr 2011 11:10:39 +0930, Terry Baume wrote:
I am having some trouble with some users connecting to my ngIRCd server - this only seems to affect some users.
Here's an extract from my log:
Apr 28 10:46:39 jupiter ngircd[1600]: Accepted connection 13 from 58.160.178.xxx:54009 on socket 10. Apr 28 10:46:39 jupiter ngircd[14258]: Can't resolve "CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au": Name or service not known Apr 28 10:46:39 jupiter ngircd[14258]: Possible forgery: 58.160.178.xxxresolved to CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au (which has no ip address) Apr 28 10:46:39 jupiter ngircd[1600]: New TLSv1 connection using cipher AES128-SHA on socket 13. Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" registered (connection 13). Apr 28 10:46:39 jupiter ngircd[1600]: Write buffer overflow (connection 13, size 4036 byte)! Apr 28 10:46:39 jupiter ngircd[1600]: Shutting down connection 13 (Write buffer overflow!) with 58.160.178.xxx:54009 ... Apr 28 10:46:39 jupiter ngircd[1600]: SSL connection 13 shutting down ... Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" unregistered (connection 13): Write buffer overflow! Apr 28 10:46:39 jupiter ngircd[1600]: Connection 13 with 58.160.178.xxx:54009 closed (in: 0.0k, out: 11.9k).
My interpretation of the log is that the client is exceeding ngIRCd's buffer size - can this parameter be tuned, or is this a misbehaving (outside of RFC) client?
"Write buffer overflow" basically means that ngIRCd wan't to send more data back to the client than it can store in its "output buffers".
Which version of ngIRCd are you using?
We enhanced the buffer sizes and write-out logic in our current development branch, see GIT commits 477224be5c0 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=477224be5c0) and f732c7117e5 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=f732c7117e5); the description of the latter patch is:
commit f732c7117e5a4b74b47c4594470506dcb2773760 Author: Alexander Barton alex@barton.de Date: Sat Feb 12 23:24:56 2011 +0100
Make write buffers bigger, but flush early
This patch - makes the server write buffer bigger: 64k, - makes the regular write buffer bigger: 32k, - tries to flush the write buffer starting at 4K.
Before this patch, a client got disconnected if the buffer flushing at 4k failed, now regular clients can store up to 32k and servers up 64k even if flushing is not possible at the moment (e.g. on slow links).
Can you re-test with the current development version? You can check it out using GIT (see http://ngircd.barton.de/doc/GIT.txt for details); or you can use a current tarball which can be found here: ftp://ftp.berlios.de/pub/ngircd/ngircd-17.1~98-g1cb2f57.tar.gz
Regards Alex
Hi Alex, Thanks for your speedy response!
I'm currently running ngIRCd 17.1 - great to hear there was a recent commit related to this behavior. I will pull the current dev branch from git shortly, retest & let you know how it goes. :-)
Cheers, Terry.
Alexander Barton wrote:
Hi Terry!
On Thu, 28 Apr 2011 11:10:39 +0930, Terry Baume wrote:
I am having some trouble with some users connecting to my ngIRCd server - this only seems to affect some users.
Here's an extract from my log:
Apr 28 10:46:39 jupiter ngircd[1600]: Accepted connection 13 from 58.160.178.xxx:54009 on socket 10. Apr 28 10:46:39 jupiter ngircd[14258]: Can't resolve "CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au": Name or service not known Apr 28 10:46:39 jupiter ngircd[14258]: Possible forgery: 58.160.178.xxxresolved to CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au (which has no ip address) Apr 28 10:46:39 jupiter ngircd[1600]: New TLSv1 connection using cipher AES128-SHA on socket 13. Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" registered (connection 13). Apr 28 10:46:39 jupiter ngircd[1600]: Write buffer overflow (connection 13, size 4036 byte)! Apr 28 10:46:39 jupiter ngircd[1600]: Shutting down connection 13 (Write buffer overflow!) with 58.160.178.xxx:54009 ... Apr 28 10:46:39 jupiter ngircd[1600]: SSL connection 13 shutting down ... Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" unregistered (connection 13): Write buffer overflow! Apr 28 10:46:39 jupiter ngircd[1600]: Connection 13 with 58.160.178.xxx:54009 closed (in: 0.0k, out: 11.9k).
My interpretation of the log is that the client is exceeding ngIRCd's buffer size - can this parameter be tuned, or is this a misbehaving (outside of RFC) client?
"Write buffer overflow" basically means that ngIRCd wan't to send more data back to the client than it can store in its "output buffers".
Which version of ngIRCd are you using?
We enhanced the buffer sizes and write-out logic in our current development branch, see GIT commits 477224be5c0 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=477224be5c0) and f732c7117e5 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=f732c7117e5); the description of the latter patch is:
commit f732c7117e5a4b74b47c4594470506dcb2773760 Author: Alexander Barton alex@barton.de Date: Sat Feb 12 23:24:56 2011 +0100
Make write buffers bigger, but flush early This patch - makes the server write buffer bigger: 64k, - makes the regular write buffer bigger: 32k, - tries to flush the write buffer starting at 4K. Before this patch, a client got disconnected if the bufferflushing at 4k failed, now regular clients can store up to 32k and servers up 64k even if flushing is not possible at the moment (e.g. on slow links).
Can you re-test with the current development version? You can check it out using GIT (see http://ngircd.barton.de/doc/GIT.txt for details); or you can use a current tarball which can be found here: ftp://ftp.berlios.de/pub/ngircd/ngircd-17.1~98-g1cb2f57.tar.gz
Regards Alex
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de http://arthur.barton.de/mailman/listinfo/ngircd-ml
Hi Alex, Have built from the dev branch & the issue looks to be resolved, will keep an eye on the git repository for updates from now on.
Many thanks to you and your contributors for your work on ngIRCd & great support. :-)
Terry.
Terry Baume wrote:
Hi Alex, Thanks for your speedy response!
I'm currently running ngIRCd 17.1 - great to hear there was a recent commit related to this behavior. I will pull the current dev branch from git shortly, retest & let you know how it goes. :-)
Cheers, Terry.
Alexander Barton wrote:
Hi Terry!
On Thu, 28 Apr 2011 11:10:39 +0930, Terry Baume wrote:
I am having some trouble with some users connecting to my ngIRCd server - this only seems to affect some users.
Here's an extract from my log:
Apr 28 10:46:39 jupiter ngircd[1600]: Accepted connection 13 from 58.160.178.xxx:54009 on socket 10. Apr 28 10:46:39 jupiter ngircd[14258]: Can't resolve "CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au": Name or service not known Apr 28 10:46:39 jupiter ngircd[14258]: Possible forgery: 58.160.178.xxxresolved to CPE-58-160-178-xxx.hbqy1.fli.bigpond.net.au (which has no ip address) Apr 28 10:46:39 jupiter ngircd[1600]: New TLSv1 connection using cipher AES128-SHA on socket 13. Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" registered (connection 13). Apr 28 10:46:39 jupiter ngircd[1600]: Write buffer overflow (connection 13, size 4036 byte)! Apr 28 10:46:39 jupiter ngircd[1600]: Shutting down connection 13 (Write buffer overflow!) with 58.160.178.xxx:54009 ... Apr 28 10:46:39 jupiter ngircd[1600]: SSL connection 13 shutting down ... Apr 28 10:46:39 jupiter ngircd[1600]: User "Skiitz!~.@58.160.178.xxx" unregistered (connection 13): Write buffer overflow! Apr 28 10:46:39 jupiter ngircd[1600]: Connection 13 with 58.160.178.xxx:54009 closed (in: 0.0k, out: 11.9k).
My interpretation of the log is that the client is exceeding ngIRCd's buffer size - can this parameter be tuned, or is this a misbehaving (outside of RFC) client?
"Write buffer overflow" basically means that ngIRCd wan't to send more data back to the client than it can store in its "output buffers".
Which version of ngIRCd are you using?
We enhanced the buffer sizes and write-out logic in our current development branch, see GIT commits 477224be5c0 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=477224be5c0) and f732c7117e5 (http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=f732c7117e5); the description of the latter patch is:
commit f732c7117e5a4b74b47c4594470506dcb2773760 Author: Alexander Barton alex@barton.de Date: Sat Feb 12 23:24:56 2011 +0100
Make write buffers bigger, but flush early This patch - makes the server write buffer bigger: 64k, - makes the regular write buffer bigger: 32k, - tries to flush the write buffer starting at 4K. Before this patch, a client got disconnected if the bufferflushing at 4k failed, now regular clients can store up to 32k and servers up 64k even if flushing is not possible at the moment (e.g. on slow links).
Can you re-test with the current development version? You can check it out using GIT (see http://ngircd.barton.de/doc/GIT.txt for details); or you can use a current tarball which can be found here: ftp://ftp.berlios.de/pub/ngircd/ngircd-17.1~98-g1cb2f57.tar.gz
Regards Alex
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de http://arthur.barton.de/mailman/listinfo/ngircd-ml
ngIRCd Mailing List: ngIRCd-ML@arthur.barton.de http://arthur.barton.de/mailman/listinfo/ngircd-ml
-
Alexander Barton -
Terry Baume