View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005799 | unreal | ircd | public | 2020-12-29 08:09 | 2020-12-29 12:50 |
| Reporter | severinmueller | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | unix | OS | Ubuntu | OS Version | 20.04 LTS |
| Product Version | 5.0.7 | ||||
| Fixed in Version | 5.0.8-rc1 | ||||
| Summary | 0005799: Messages from Services are omitted after 8 lines | ||||
| Description | When services send multiple messages to a user fast (e.g. a list of some sort) the messages seem to get omitted after the 8th or 9th message. Even with the NOFAKELAG option, this occurs for all classes. | ||||
| Steps To Reproduce | Have services or servers send multiple messagas (10+) in a short amount of time | ||||
| Additional Information | - Issue wasn't present in 3.2 - Used multiple clients to rule out client throttling, including HexChat, XChat and a 15 year old mIRC version; all deliver the same results - Tried multiple sendq and recvq settings - no effect | ||||
| Tags | flood, services, throttling | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
This is likely caused by service bots missing one of the +So umodes. Please paste "/whois chanserv" output. |
|
|
I have my doubts about a problem on our end, as other services and servers send hundreds of messages per second just fine. Let's go with neutral proof, a packet capture. Sot logging from your end or our end, but a TCP/IP packet capture by a 3rd party tool. Two options here... for proof I would want option B, but you can also do a quick check first with option A. This assumes you use a plaintext server connection by the way and not SSL/TLS. OPTION A: 1) As root run ngrep on a different console: ngrep -d lo -W byline '' 'port XXXX' NOTE: Change 'lo' to another interface if that is not the one where your services<-->ircd connection is on (eg, if it is not on loopback it might be 'eth0' instead) NOTE: Change XXXX to the port that the services<-->ircd connection is on (eg: 6667) NOTE: The '' 'port XXXX' is not a typo. Yes there needs to be two double quotes without content, followed by a space, followed by the 'port XXXX'. 2) Then reproduce your problem, so without any delay/throttling 3) Take a look at your ngrep console to make sure no packets are missing. If you only see like message 1-7 instead of message 1-30 then that is proof that your program is actually only sending message 1-7. If you see all 1-30 messages then that is proof that it is being sent to UnrealIRCd. OPTION B: 1) Run the following as root on a different console: tcpdump -n -i lo -w capture.pcap port XXXX NOTE: Change 'lo' to another interface if that is not the one where your services<-->ircd connection is on (eg, if it is not on loopback it might be 'eth0' instead) NOTE: Change XXXX to the port that the services<-->ircd connection is on (eg: 6667) 2) Then reproduce your problem, so without any delay/throttling 3) Wait a few seconds extra and then press CTRL+C on the tcpdump console. 4) Upload the 'capture.pcap' as a comment on this bug, be sure to tick the 'private' box on the comment to make it a private comment. |
|
|
WHOIS output for Chanserv: * [Chanserv] ([email protected]): Reefmaster Channel Services * [Chanserv] is using modes +dqS * [Chanserv] is connecting from *@reefmaster.ch * [Chanserv] services.reefmaster.ch :[services.reefmaster.ch] Reefmaster IRC Services * [Chanserv] is a Network Service * [chanserv] End of WHOIS list. |
|
|
And what happens if after this services send a response to another user? In other words: if you run run "AOP #cservice LIST" from one user, and then run.. i don't know... "HELP" from another client to services. It would be interesting to see if then the latter is delivered the second user, how quickly, and if that has an impact on the former. Etc. => Can you do that and attach that using option B (tcpdump) ? |
|
|
And I agree with k4be that your services should have usermode +o (oper). |
|
|
Setting usermode +o to services actually did the trick. Now all messages get through. |
|
|
Ah, that's an easy solution :D I will keep the bug open because, even though you likely run into trouble without user mode +o in other areas in services, the lack of umode +o should not cause this behavior. So I will check and presumably fix it. Thanks for the report. |
|
|
Fixed in https://github.com/unrealircd/unrealircd/commit/04a45e8b8346fce1815dbb5bf56ac29b6ca40c6f -- thanks for the report! commit 04a45e8b8346fce1815dbb5bf56ac29b6ca40c6f (HEAD -> unreal50, origin/unreal50) Author: Bram Matthys <[email protected]> Date: Tue Dec 29 12:44:54 2020 +0100 Fix targetfloodprot module not exempting U-Lines (only matters if not +o). It is highly recommended that services pseudo users all have +o since there are likely many places where ULines don't bypass a restriction while opers do. But still, this particular issue has been fixed, it caused unexplained loss of messages which looked rather mysterious. Reported by severinmueller in https://bugs.unrealircd.org/view.php?id=5799 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-12-29 08:09 | severinmueller | New Issue | |
| 2020-12-29 08:09 | severinmueller | Tag Attached: flood | |
| 2020-12-29 08:09 | severinmueller | Tag Attached: Qihoo360 CodeSafe Static Analysis | |
| 2020-12-29 08:09 | severinmueller | Tag Attached: services | |
| 2020-12-29 08:09 | severinmueller | Tag Attached: throttling | |
| 2020-12-29 08:09 | severinmueller | File Added: services.png | |
| 2020-12-29 08:42 | k4be | Note Added: 0021857 | |
| 2020-12-29 08:47 | syzop | Note Added: 0021858 | |
| 2020-12-29 08:53 | severinmueller | Note Added: 0021859 | |
| 2020-12-29 09:09 | syzop | Note Added: 0021861 | |
| 2020-12-29 09:09 | syzop | Note Edited: 0021861 | |
| 2020-12-29 09:13 | syzop | Note Added: 0021862 | |
| 2020-12-29 09:53 | severinmueller | Note Added: 0021864 | |
| 2020-12-29 10:01 | syzop | Note Added: 0021865 | |
| 2020-12-29 10:01 | syzop | Status | new => acknowledged |
| 2020-12-29 10:01 | syzop | Tag Detached: Qihoo360 CodeSafe Static Analysis | |
| 2020-12-29 12:50 | syzop | Assigned To | => syzop |
| 2020-12-29 12:50 | syzop | Status | acknowledged => resolved |
| 2020-12-29 12:50 | syzop | Resolution | open => fixed |
| 2020-12-29 12:50 | syzop | Fixed in Version | => 5.0.8-rc1 |
| 2020-12-29 12:50 | syzop | Note Added: 0021866 |
