You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On 2011-07-11 02:55:16 +0200, James Kirwill wrote:
In a network with multiple peered ngircds sometimes the server connection gets killed with a "Spoofed prefix" error message. The desired behaviour would be to kill the client on the server which appears to be spoofed to the other servers.
Even if the client is not killed, killing the server connection induces unwanted net splits and is not a good way to handle the problem.
One possible solutions would be to change line 327 in parse.c from
if (Client_NextHop(c) != client) {
to
if (Client_NextHop(c) != client && Client_Type(client) == CLIENT_USER) {
preventing the Conn_close on server and services connections.
On 2011-07-11 10:27:31 +0200, Alexander Barton wrote:
Isn't the question why a server (!) sends/forwards a user with invalid prefix to other servers in the first place at all?
Do you have a clue where this invalid prefix originates and why/how it is forwarded?
On 2011-07-11 11:32:28 +0200, James Kirwill wrote:
(In reply to comment # 1)
Isn't the question why a server (!) sends/forwards a user with invalid prefix
to other servers in the first place at all?
Do you have a clue where this invalid prefix originates and why/how it is
forwarded?
It seems to happen if a user (or same nick) was (or sometimes still is) logged in on two servers on the net. This happened even after server restarts. The prefix seems to be valid for both servers as long as they dont have a connection. Then, after the server-server connection is established, irc services issue a nick kill which is answered by ngircd as if there was no corresponding nick to kill. Then directly after that, the server-server connection is killed because of "Spoofed prefix".
On 2011-07-11 15:28:14 +0200, Alexander Barton wrote:
Is it possible for you to run ngIRCd in "sniffer mode" and get a trace of the IRC commands exchanged between the two servers? (This requires ngircd to be ./configure'd with "--enable-sniffer")
Would be very helpful to fully understand the problem!
Currently I don't see how this could happen, but will think about it ...
On 2011-07-19 10:34:09 +0200, Alexander Barton wrote:
Any news on this?
Up to today, I was not able to reproduce it ...
On 2011-07-19 16:06:18 +0200, Alexander Barton wrote:
Created attachment 48
Spoofed prefixes: close connection on non-server links only
Ok, now after some more thinking and testing I can imagine how this happens:
Server A connects to server B and sends its PASS and SERVER commands
Server A sends send the first part of lots of NICK, NJOIN, CHANINFO, ... commands
Server B receives PASS, SERVER etc. and sends its PASS and SERVER commands
Server B sends all his (few) NICK, NJOIN, CHANINFO, .. commands
Server B forwards a message for a client "NICK01" it knows to server A
Server A receives the (few) NICK, NJOIN, CHANINFO, and forwarded commands of B
Server A detects a Nick collission for "NICK01" and sends its KILL
Server A handles the forwarded message of the already KILL'ed nick
Server A thinks that this message is spoofed because of the no longer existing prefix.
So I think "spoofed prefixes" must be ignored on server-links, but the received command should be ignored as well.
Could you please check if the attached patch fixes the issue for you?
Thanks!
On 2011-07-19 16:09:19 +0200, Alexander Barton wrote:
Created attachment 49
Spoofed prefixes: close connection on non-server links only
Patch was broken, missing newlines … 2nd try …
On 2011-07-30 18:54:53 +0200, Alexander Barton wrote:
Any update on this bug report?
Does my patch fix your issue, James?
On 2011-08-09 07:27:33 +0200, James Kirwill wrote:
Hi Alex,
your patch fixes the issue. Now works without problems! No killed inter-server connections anymore. Thank you!
On 2011-08-09 10:22:24 +0200, Alexander Barton wrote:
Thanks for all your help in debugging in fixing this!
I merged the fixes in our "master" branch, they will be included in our next release.
(Report imported from Bugzilla #113)
Status CLOSED, severity major, in component Daemon.
Reported in version development on platform All.
Assigned to: Alexander Barton.
Original attachment names and IDs:
On 2011-07-11 02:55:16 +0200, James Kirwill wrote:
On 2011-07-11 10:27:31 +0200, Alexander Barton wrote:
On 2011-07-11 11:32:28 +0200, James Kirwill wrote:
On 2011-07-11 15:28:14 +0200, Alexander Barton wrote:
On 2011-07-19 10:34:09 +0200, Alexander Barton wrote:
On 2011-07-19 16:06:18 +0200, Alexander Barton wrote:
On 2011-07-19 16:09:19 +0200, Alexander Barton wrote:
On 2011-07-30 18:54:53 +0200, Alexander Barton wrote:
On 2011-08-09 07:27:33 +0200, James Kirwill wrote:
On 2011-08-09 10:22:24 +0200, Alexander Barton wrote:
The text was updated successfully, but these errors were encountered: