adam/znc
1
0 Fork 0
mirror of https://github.com/znc/znc.git synced 2026-10-31 01:32:02 +01:00
Code Issues 362 Packages Projects Releases Wiki Activity

Receiving DCC Transfers Fail explicitly with iroffer-dinoex #193

New Issue
Closed
opened 2026-10-05 04:03:32 +02:00 by adam · 6 comments
adam commented 2026-10-05 04:03:32 +02:00
Owner
Copy link
Copy source

It appears that under certain circumstances, DCC transfers from bots running iroffer-dinoex will explictly fail when being used through ZNC, but when connecting directly to the server, it will work for those bots. When the transfer fails, it appears as a malformed DCC request (according to Hexchat, what I use).

For example, on a bot that fails:
You send the dcc request.
Hexchat barks at the response it gets, showing this in the main window:
-[AnimeTL]Imouto- ** Sending you pack #842 ("[CR] AKB0048 - Next Stage - 02 [1280x720].mkv"), which is 323MB. (resume supported)

  • Received a malformed DCC request from [AnimeTL]Imouto.
  • Contents of packet: DCC SEND "[CR] 3235023813 37063 0

The Raw Log of hexchat will show this:

:[AnimeTL]Imouto!~desktop@XDCC.Anime.TL NOTICE Aoi-chan :** Sending you pack #842 ("[CR] AKB0048 - Next Stage - 02 [1280x720].mkv"), which is 323MB. (resume supported)
:[AnimeTL]Imouto!~desktop@XDCC.Anime.TL PRIVMSG Aoi-chan :DCC SEND "[CR] 3235023813 37063 0

However, on a working bot, you'll get this response:
Main Window:

Ginpachi-Sensei< xdcc send 4

  • Ginpachi-Sensei has offered [UTW]Accel_World-03[h264-720p][F2385A07].mkv (413054931 bytes)
  • DCC RECV connection established to Ginpachi-Sensei [192.210.139.197:52747]

With this in the main log:

:Ginpachi-Sensei!~Gin@oshiete.ginpachi.sensei PRIVMSG Aoi-chan :DCC SEND [UTW]Accel_World-03[h264-720p][F2385A07].mkv 3235023813 52747 413054931

Is this something with ZNC that causes it to choke, or would this be more of a Hexchat thing. I'm imagining it's ZNC because i can directly connect to the server without ZNC and it works, but WITH znc it doesn't work.

It appears that under certain circumstances, DCC transfers from bots running iroffer-dinoex will explictly fail when being used through ZNC, but when connecting directly to the server, it will work for those bots. When the transfer fails, it appears as a malformed DCC request (according to Hexchat, what I use). For example, on a bot that fails: You send the dcc request. Hexchat barks at the response it gets, showing this in the main window: -[AnimeTL]Imouto- *\* Sending you pack #842 ("[CR] AKB0048 - Next Stage - 02 [1280x720].mkv"), which is 323MB. (resume supported) - Received a malformed DCC request from [AnimeTL]Imouto. - Contents of packet: DCC SEND "[CR] 3235023813 37063 0 The Raw Log of hexchat will show this: > > :[AnimeTL]Imouto!~desktop@XDCC.Anime.TL NOTICE Aoi-chan :*\* Sending you pack #842 ("[CR] AKB0048 - Next Stage - 02 [1280x720].mkv"), which is 323MB. (resume supported) > > :[AnimeTL]Imouto!~desktop@XDCC.Anime.TL PRIVMSG Aoi-chan :DCC SEND "[CR] 3235023813 37063 0 However, on a working bot, you'll get this response: Main Window: > Ginpachi-Sensei< xdcc send 4 > - Ginpachi-Sensei has offered [UTW]_Accel_World_-_03_[h264-720p][F2385A07].mkv (413054931 bytes) > - DCC RECV connection established to Ginpachi-Sensei [192.210.139.197:52747] With this in the main log: > > :Ginpachi-Sensei!~Gin@oshiete.ginpachi.sensei PRIVMSG Aoi-chan :DCC SEND [UTW]_Accel_World_-_03_[h264-720p][F2385A07].mkv 3235023813 52747 413054931 Is this something with ZNC that causes it to choke, or would this be more of a Hexchat thing. I'm imagining it's ZNC because i can directly connect to the server without ZNC and it works, but WITH znc it doesn't work. <!-- github-sync-id:10137685 -->
adam closed this issue 2026-10-05 04:03:32 +02:00
adam commented 2026-10-05 04:03:33 +02:00
Author
Owner
Copy link
Copy source

bouncedcc module is off?

bouncedcc module is off? <!-- github-comment-id:12474105 -->
adam commented 2026-10-05 04:03:34 +02:00
Author
Owner
Copy link
Copy source

bouncedcc was on. With bouncedcc off, it appears to receive correctly.

bouncedcc was on. With bouncedcc off, it appears to receive correctly. <!-- github-comment-id:12506654 -->
adam commented 2026-10-05 04:03:34 +02:00
Author
Owner
Copy link
Copy source

[UTW]_Accel_World_-_03_[h264-720p][F2385A07].mkv and [CR] AKB0048 - Next Stage - 02 [1280x720].mkv look like different files for me... One has spaces in filename, another doesn't have them.
Also... Do specs on DCC exist, where rules for filename with spaces are defined?

`[UTW]_Accel_World_-_03_[h264-720p][F2385A07].mkv` and `[CR] AKB0048 - Next Stage - 02 [1280x720].mkv` look like different files for me... One has spaces in filename, another doesn't have them. Also... Do specs on DCC exist, where rules for filename with spaces are defined? <!-- github-comment-id:12511803 -->
adam commented 2026-10-05 04:03:35 +02:00
Author
Owner
Copy link
Copy source

I don't know if there is a specification for DCC, but I found that the bots (iroffer and UPP atleast, I haven't tested SysReset yet) that send files with spaces in the filename encapsulate it with double quotes ("). Examples:
iroffer

PRIVMSG FlowerPot :xdcc send -1
:FlowerPot!flower@in.a.pot PRIVMSG JohnFlower :DCC SEND flowerpot.txt 633032586 43352 12571
:FlowerPot!flower@in.a.pot NOTICE JohnFlower :** Transfer Completed (12 kB, 0.631 sec, 19.5 kB/sec)

PRIVMSG FlowerPot :xdcc send 1
:FlowerPot!flower@in.a.pot NOTICE JohnFlower :* Sending you pack #1 ("[ANE] Kara no Kyoukai - 1 - Overlooking View [BDRip 1080p x264 FLAC].mkv"), which is 4.7GB. (resume supported)
:FlowerPot!flower@in.a.pot PRIVMSG JohnFlower :DCC SEND "[ANE] Kara no Kyoukai - 1 - Overlooking View [BDRip 1080p x264 FLAC].mkv" 633032586 58724 4996404698
:FlowerPot!flower@in.a.pot NOTICE JohnFlower :* Closing Connection: Unable to transfer data (Broken pipe)

UPP

:SakuraKinomoto!sakura@[redacted] NOTICE JohnFlower :DCC Send v1.5-r3sys.zip ([redacted]) :SakuraKinomoto!sakura@[redacted] PRIVMSG JohnFlower :DCC SEND v1.5-r3sys.zip 1191777349 63509 203255

:SakuraKinomoto!sakura@[redacted] NOTICE JohnFlower :DCC Send Black Butler II - 04 [x264-AC3-DVD][Sakura][C-W][22D08B96].mkv ([redacted]) :SakuraKinomoto!sakura@[redacted] PRIVMSG JohnFlower :DCC SEND "Black Butler II - 04 [x264-AC3-DVD][Sakura][C-W][22D08B96].mkv" 1191777349 63510 279428751

Tested with Hexchat~

I don't know if there is a specification for DCC, but I found that the bots (iroffer and UPP atleast, I haven't tested SysReset yet) that send files with spaces in the filename encapsulate it with double quotes ("). Examples: iroffer > PRIVMSG FlowerPot :xdcc send -1 > :FlowerPot!flower@in.a.pot PRIVMSG JohnFlower :DCC SEND flowerpot.txt 633032586 43352 12571 > :FlowerPot!flower@in.a.pot NOTICE JohnFlower :*\* Transfer Completed (12 kB, 0.631 sec, 19.5 kB/sec) > > PRIVMSG FlowerPot :xdcc send 1 > :FlowerPot!flower@in.a.pot NOTICE JohnFlower :*\* Sending you pack #1 ("[ANE] Kara no Kyoukai - 1 - Overlooking View [BDRip 1080p x264 FLAC].mkv"), which is 4.7GB. (resume supported) > :FlowerPot!flower@in.a.pot PRIVMSG JohnFlower :DCC SEND "[ANE] Kara no Kyoukai - 1 - Overlooking View [BDRip 1080p x264 FLAC].mkv" 633032586 58724 4996404698 > :FlowerPot!flower@in.a.pot NOTICE JohnFlower :*\* Closing Connection: Unable to transfer data (Broken pipe) UPP > :Sakura`Kinomoto!sakura@[redacted] NOTICE JohnFlower :DCC Send v1.5-r3sys.zip ([redacted]) > :Sakura`Kinomoto!sakura@[redacted] PRIVMSG JohnFlower :DCC SEND v1.5-r3sys.zip 1191777349 63509 203255 > > :Sakura`Kinomoto!sakura@[redacted] NOTICE JohnFlower :DCC Send Black Butler II - 04 [x264-AC3-DVD][Sakura][C-W][22D08B96].mkv ([redacted]) > :Sakura`Kinomoto!sakura@[redacted] PRIVMSG JohnFlower :DCC SEND "Black Butler II - 04 [x264-AC3-DVD][Sakura][C-W][22D08B96].mkv" 1191777349 63510 279428751 Tested with Hexchat~ <!-- github-comment-id:31494716 -->
adam commented 2026-10-05 04:03:36 +02:00
Author
Owner
Copy link
Copy source

I can confirm this bug too. The problem lies with how the code handles parsing the input file name. It uses CString::Token() which splits up the string at spaces. This is wrong for the quoted-filename cases mentioned above.

The offending lines are line 164 and 219 in https://github.com/znc/znc/blob/master/modules/bouncedcc.cpp

Unfortunately I don't have the experience in cpp to fix this myself though it seems a trivial task for the devs.

I can confirm this bug too. The problem lies with how the code handles parsing the input file name. It uses CString::Token() which splits up the string at spaces. This is wrong for the quoted-filename cases mentioned above. The offending lines are line 164 and 219 in https://github.com/znc/znc/blob/master/modules/bouncedcc.cpp Unfortunately I don't have the experience in cpp to fix this myself though it seems a trivial task for the devs. <!-- github-comment-id:42143084 -->
adam commented 2026-10-05 04:03:36 +02:00
Author
Owner
Copy link
Copy source

Thanks, kobuki! Just did a quick test, works perfectly~

Thanks, kobuki! Just did a quick test, works perfectly~ <!-- github-comment-id:43483989 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#193