View Issue Details

IDProjectCategoryView StatusLast Update
0005799unrealircdpublic2020-12-29 12:50
Reporterseverinmueller Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformunixOSUbuntuOS Version20.04 LTS
Product Version5.0.7 
Fixed in Version5.0.8-rc1 
Summary0005799: Messages from Services are omitted after 8 lines
DescriptionWhen 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 ReproduceHave 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
Tagsflood, services, throttling
3rd party modules

Activities

severinmueller

2020-12-29 08:09

reporter  

services.png (612,361 bytes)

k4be

2020-12-29 08:42

developer   ~0021857

This is likely caused by service bots missing one of the +So umodes. Please paste "/whois chanserv" output.

syzop

2020-12-29 08:47

administrator   ~0021858

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.

severinmueller

2020-12-29 08:53

reporter   ~0021859

WHOIS output for Chanserv:

* [Chanserv] (services@reefmaster.ch): 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.

syzop

2020-12-29 09:09

administrator   ~0021861

Last edited: 2020-12-29 09:09

View 2 revisions

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) ?

syzop

2020-12-29 09:13

administrator   ~0021862

And I agree with k4be that your services should have usermode +o (oper).

severinmueller

2020-12-29 09:53

reporter   ~0021864

Setting usermode +o to services actually did the trick. Now all messages get through.

syzop

2020-12-29 10:01

administrator   ~0021865

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.

syzop

2020-12-29 12:50

administrator   ~0021866

Fixed in https://github.com/unrealircd/unrealircd/commit/04a45e8b8346fce1815dbb5bf56ac29b6ca40c6f -- thanks for the report!

commit 04a45e8b8346fce1815dbb5bf56ac29b6ca40c6f (HEAD -> unreal50, origin/unreal50)
Author: Bram Matthys <syzop@vulnscan.org>
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

Issue History

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 View Revisions
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