Opened 5 years ago

Last modified 5 years ago

#15896 new patch

Handle messages larger than IRC_INITIAL_BUFSIZE

Reported by: ctaveras Owned by: elb
Milestone: Component: IRC
Version: 2.10.8 Keywords: SSL inspircd packets gnutls openssl
Cc: elb, Stmeter

Attachments (1)

irc.patch (2.8 KB) - added by ctaveras 5 years ago.
Attaching patch to irc.c

Download all attachments as: .zip

Change History (6)

comment:1 Changed 5 years ago by Robby

Any reason you didn't attach it to the existing ticket? :)

comment:2 Changed 5 years ago by ctaveras

I was following these instructions:

Perhaps I was following them a little too closely? From the instructions, it seems like new patches require a new ticket categorized as "patch" and not "new defect".

comment:3 Changed 5 years ago by Robby

Ticket types can be changed. Maybe that Wiki page needs to changed to take existing tickets into account.

Not to worry. :-)

comment:4 Changed 5 years ago by QuLogic

You probably want to limit inbuf to some large, but not unreasonable value. Also, the while (1) seems troublesome. On a fast enough connection, it would probably block the UI.

Changed 5 years ago by ctaveras

Attaching patch to irc.c

comment:5 Changed 5 years ago by ctaveras

I've uploaded a new patch taking into account QuLogic's feedback. But it's conceivable that an IRC server with a sufficiently large MOTD could trigger the same behavior, which makes this commit a stop-gap measure. What we really need is a way to ensure the input callback gets called on the next iteration of the loop even if the socket isn't drained of pending data on the current iteration. Perhaps something as simple as scheduling it from the callback itself? I haven't had time to look at it further.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!