Subj : Blocking
To   : andrew clarke
From : Pavel Gulchouck
Date : Sun Nov 14 2021 10:16 pm

Hi andrew!

12 Nov 21, andrew clarke ==> Dallas Hinton:

 DH>> Binkd on Windows 10 32-bit. Is there a way to block a particular node
 DH>> from doing a file request? I've one node who keeps requesting a packet
 DH>> (that doesn't exist) and that causes Binkd to crash! :-(

 DH>> + 11 Nov 15:20:41 [1980] pwd protected session (MD5)
 DH>> + 11 Nov 15:20:41 [1980] sending c:\OUTBOUND\000f1d91.th0 as
 DH>> 000f1d91.th0 (165816) - 11 Nov 15:20:41 [1980] receiving 61e1ed3d.pkt
 DH>> (186 byte(s), off 0) ? 11 Nov 15:20:41 [1980] GET: remote requests
 DH>> seeking 000f1d91.th0 to 180224, file size I64u

 ac> I suspect turning off logging temporarily will prevent the crash.

 ac> ...

 ac> I don't have time to send a pull request, but for other developers reading this:

 ac> "I64u" is a printf-formatting bug. It should be "%I64u", which gets converted to the file size at runtime.

 ac> diff for protocol.c:

 ac> -        Log (1, "GET: remote requests seeking %s to %" PRIuMAX ", file size " PRIuMAX,
 ac> +        Log (1, "GET: remote requests seeking %s to %" PRIuMAX ", file size %" PRIuMAX,
 ac>               argv[0], (uintmax_t) offset, (uintmax_t) state->out.size);
 ac> -        msg_sendf(state, M_ERR, "Invalid M_GET violates binkp: offset " PRIuMAX " after end of file, file %s size " PRIuMAX,
 ac> +        msg_sendf(state, M_ERR, "Invalid M_GET violates binkp: offset %" PRIuMAX " after end of file, file %s size %" PRIuMAX,

Many thanks! The patch was applied.

 ac> Though this isn't the only place in the binkd code where this bug exists.

 ac> Obviously checking whether PRIuMAX is prefixed with "%" in every call to Log() or msg_sendf() etc is visually difficult and error-prone.

 ac> This should instead be fixed at the source, in sys.h:

 ac> -  #define PRIdMAX "I64i"
 ac> -  #define PRIuMAX "I64u"
 ac> +  #define PRIdMAX "%I64i"
 ac> +  #define PRIuMAX "%I64u"

 ac> Then change the .c files that reference these macros accordingly.

This way was choosen due to use of the format "%8" PRIuMAX in ftnq.c.
I'm not sure is it better to create another macro PRIuMAX8 or keep existing PRIdMAX without '%'.

              Lucky carrier,
                           Pavel
                           aka  gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
 * Origin: II:CDLXIII/LXVIII (2:463/68)

.