• Unixtime in M_GOT frames

    From Andrew Leary@1:320/219 to All on Mon Nov 4 06:13:49 2019
    Hello everybody!

    I have recently noticed that some versions of BinkD are listing a 64-bit value for the Unixtime sent in M_GOT frames acknowledging received files. This, of course, can cause issues for mailers that are expecting a 32-bit value. FTS-1026.001 (Binkp/1.0 protocol specification) does not specify the size of this field.

    I can see the value of switching to a 64-bit Unixtime; it will solve the upcoming year 2038 problem. However, if it breaks compatibility with other existing Binkp mailers, we should implement some mechanism to only enable this feature if the remote mailer explicitly supports it. This could be done with an M_NUL OPT frame sent by mailers that support 64-bit Unixtimes.

    ie: M_NUL OPT TIME64

    Until this frame is received from the remote, it should be assumed that the remote does NOT support 64-bit Unixtimes, and all Unixtimes sent should be 32-bit.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Michiel van der Vlist@2:280/5555 to Andrew Leary on Mon Nov 4 13:26:13 2019
    Hello Andrew,

    On Monday November 04 2019 06:13, you wrote to All:

    ie: M_NUL OPT TIME64

    Until this frame is received from the remote, it should be assumed
    that the remote does NOT support 64-bit Unixtimes, and all Unixtimes
    sent should be 32-bit.

    Secunded.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20170303
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Dumas Walker@1:2320/105 to MICHIEL VAN DER VLIST on Mon Nov 4 17:00:00 2019
    Hello Andrew,
    On Monday November 04 2019 06:13, you wrote to All:

    ie: M_NUL OPT TIME64

    Until this frame is received from the remote, it should be assumed
    that the remote does NOT support 64-bit Unixtimes, and all Unixtimes sent should be 32-bit.

    Secunded.

    Thirded. :)

    Mike


    * SLMR 2.1a * Why do we have training bras? What can we teach them?
    --- SBBSecho 3.07-Linux
    * Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)
  • From Oli@2:280/464.47 to Andrew Leary on Fri Nov 8 08:39:48 2019
    I have recently noticed that some versions of BinkD are listing a
    64-bit value for the Unixtime sent in M_GOT frames acknowledging
    received files.

    Which versions do this and what bit width is used with the M_FILE command?

    This, of course, can cause issues for mailers that
    are expecting a 32-bit value. FTS-1026.001 (Binkp/1.0 protocol specification) does not specify the size of this field.

    I can see the value of switching to a 64-bit Unixtime; it will solve
    the upcoming year 2038 problem. However, if it breaks compatibility
    with other existing Binkp mailers, we should implement some mechanism
    to only enable this feature if the remote mailer explicitly supports
    it.

    Does it break compatibility with any mailer? You didn't mention any specific example.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Oli@2:280/464.47 to Andrew Leary on Fri Nov 8 10:01:51 2019
    Hello everybody!

    I have recently noticed that some versions of BinkD are listing a
    64-bit value for the Unixtime sent in M_GOT frames acknowledging
    received files. This, of course, can cause issues for mailers that
    are expecting a 32-bit value. FTS-1026.001 (Binkp/1.0 protocol specification) does not specify the size of this field.

    After reading the specs and using tcpdump to have a look at the data that is transmitted, I'm not sure what you are talking about. I only see the time in plain ASCII like "1573202153".


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Andrew Leary@1:320/219 to Oli on Sat Nov 9 07:04:08 2019
    Hello Oli!

    08 Nov 19 08:39, you wrote to me:

    I have recently noticed that some versions of BinkD are listing a
    64-bit value for the Unixtime sent in M_GOT frames acknowledging
    received files.

    Which versions do this and what bit width is used with the M_FILE
    command?

    Here is the log from an example session:

    === Cut ===
    09-Nov-2019 05:40:20 mbcico[11948] MBCICO v1.0.7.13
    09-Nov-2019 05:40:20 mbcico[11948] Cmd: mbcico f126.n1.z21.fsxnet
    + 09-Nov-2019 05:40:20 mbcico[11948] Options: Call WaZOO EMSI Freqs Zmodem ZedZap Hydra PLZ GZ/BZ2 NoNR CRC
    + 09-Nov-2019 05:40:20 mbcico[11948] Calling 21:1/126@fsxnet (HappyLand BBS, phone (null))
    + 09-Nov-2019 05:40:20 mbcico[11948] Open TCP connection to "magickabbs.com:24554"
    + 09-Nov-2019 05:40:21 mbcico[11948] Trying IPv4 103.43.75.189 port 24554
    + 09-Nov-2019 05:40:21 mbcico[11948] Established IBN/TCP IPv4 connection with 103.43.75.189, port 24554
    + 09-Nov-2019 05:40:21 mbcico[11948] GeoIP location: Australia, AU OC
    + 09-Nov-2019 05:40:21 mbcico[11948] Start outbound Binkp session with 21:1/126@fsxnet
    + 09-Nov-2019 05:40:21 mbcico[11948] Binkp: start session
    + 09-Nov-2019 05:40:21 mbcico[11948] Binkp: node 21:1/126@fsxnet
    + 09-Nov-2019 05:40:22 mbcico[11948] Options : CRAM-MD5-9258b98853ea366d0a156189662da0ee
    + 09-Nov-2019 05:40:22 mbcico[11948] System : HappyLand
    + 09-Nov-2019 05:40:22 mbcico[11948] Sysop : apam
    + 09-Nov-2019 05:40:22 mbcico[11948] Location: Toowoomba, QLD
    + 09-Nov-2019 05:40:22 mbcico[11948] Flags : 115200,TCP,BINKP
    + 09-Nov-2019 05:40:22 mbcico[11948] Time : Sat, 9 Nov 2019 20:40:21 +1000 + 09-Nov-2019 05:40:22 mbcico[11948] Uses : binkd/1.1a-99/Linux binkp/1.1
    + 09-Nov-2019 05:40:22 mbcico[11948] address : 21:1/126@fsxnet
    + 09-Nov-2019 05:40:22 mbcico[11948] address : 77:3/103@scinet
    + 09-Nov-2019 05:40:22 mbcico[11948] Options : EXTCMD GZ
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: EXTCMD is active
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: GZ compression active
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: MD5 unprotected session
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: mail 0, files 21096 bytes
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: send "/opt/mbse/var/inbound/zip/SIOREG.ZIP" as "SIOREG.ZIP"
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: size 21096 bytes, dated Nov 25 17:31:44, comp No
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: OK 21096 bytes sent in 0.006 seconds (3433.594 Kb/s)
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120"
    + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: unexpected M_GOT "SIOREG.ZIP"
    === Cut ===

    I need to add logging of the sent M_FILE messages to confirm that mbcico is sending a 32-bit value in the M_FILE. You can see that the remote (binkd 1.1a-99/Linux) is sending a 64-bit value for the Unixtime in the M_GOT frame.

    I suspect this is dependent on the particular Linux distribution in use and if the __WORDSIZE_TIME64_COMPAT32 is defined when compiling the system's glibc.

    Does it break compatibility with any mailer? You didn't mention any specific example.

    mbcico (the mailer included with MBSE BBS) rejects the M_GOT with the 64-bit value and ends up trying to send the file again in the next session. I suspect that ifcico (which mbcico was based on) will do the same, although I haven't tested it yet.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Andrew Leary@1:320/219 to Oli on Sat Nov 9 08:16:42 2019
    Hello Oli!

    08 Nov 19 10:01, you wrote to me:

    After reading the specs and using tcpdump to have a look at the data
    that is transmitted, I'm not sure what you are talking about. I only
    see the time in plain ASCII like "1573202153".

    See my previous message for an example with the problem.

    Andrew


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Oli@2:280/464.47 to Andrew Leary on Sat Nov 9 14:32:23 2019
    I have recently noticed that some versions of BinkD are listing
    a 64-bit value for the Unixtime sent in M_GOT frames
    acknowledging received files.

    Which versions do this and what bit width is used with the M_FILE
    command?

    Here is the log from an example session:

    === Cut ===
    09-Nov-2019 05:40:20 mbcico[11948] MBCICO v1.0.7.13
    09-Nov-2019 05:40:20 mbcico[11948] Cmd: mbcico f126.n1.z21.fsxnet
    [...]
    Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" + 09-Nov-2019 05:40:22 mbcico[11948] Binkp: unexpected M_GOT "SIOREG.ZIP"
    === Cut ===

    That is an interesting unix timestamp, which doesn't fit into a 64-bit signed integer.

    18446744073453975120 / 2 -> November 16, 219250464

    Even if this were in nanoseconds it would be a date far in the future:
    July 21, 2554

    I need to add logging of the sent M_FILE messages to confirm that
    mbcico is sending a 32-bit value in the M_FILE. You can see that the remote (binkd 1.1a-99/Linux) is sending a 64-bit value for the
    Unixtime in the M_GOT frame.

    Looks like a bug to me that needs fixing. Are you sure that binkd sends this number?

    Does it break compatibility with any mailer? You didn't mention
    any specific example.

    mbcico (the mailer included with MBSE BBS) rejects the M_GOT with the 64-bit value and ends up trying to send the file again in the next session. I suspect that ifcico (which mbcico was based on) will do
    the same, although I haven't tested it yet.

    Every mailer should reject that M_GOT, the value doesn't make any sense.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Andrew Leary@1:320/219 to Oli on Sat Nov 9 17:04:08 2019
    Hello Oli!

    09 Nov 19 14:32, you wrote to me:

    Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" +

    That is an interesting unix timestamp, which doesn't fit into a 64-bit signed integer.

    I noticed that too. It definitely looks like someone is treating it as unsigned instead of signed.

    18446744073453975120 / 2 -> November 16, 219250464

    Even if this were in nanoseconds it would be a date far in the future: July 21, 2554

    I need to add logging of the sent M_FILE messages to confirm that
    mbcico is sending a 32-bit value in the M_FILE. You can see that
    the remote (binkd 1.1a-99/Linux) is sending a 64-bit value for
    the Unixtime in the M_GOT frame.

    I'll have to tcpdump the incoming packets to be sure, but I've never seen that happen with any other node.

    Looks like a bug to me that needs fixing. Are you sure that binkd
    sends this number?

    Definitely a bug somewhere; I just need to establish for sure whether it's in mbcico or binkd.

    Does it break compatibility with any mailer? You didn't mention
    any specific example.

    mbcico (the mailer included with MBSE BBS) rejects the M_GOT with
    the 64-bit value and ends up trying to send the file again in the
    next session. I suspect that ifcico (which mbcico was based on)
    will do the same, although I haven't tested it yet.

    Every mailer should reject that M_GOT, the value doesn't make any
    sense.

    Incidentally, I discovered that the timestamp of that file on disk was showing as November 25, 1961, so it should be a negative value. Converting the decimal to hex yields FFFF FFFF F0C4 3650, which in 2's complement notation is -255576496. A quick Unix time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC. Therefore, it appears that the value is a correct 64-bit Unixtime for the file timestamp as it was on disk.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Oli@2:280/464.47 to Andrew Leary on Sun Nov 10 09:35:19 2019
    Every mailer should reject that M_GOT, the value doesn't make any
    sense.

    Incidentally, I discovered that the timestamp of that file on disk was showing as November 25, 1961, so it should be a negative value.
    Converting the decimal to hex yields FFFF FFFF F0C4 3650, which in 2's complement notation is -255576496. A quick Unix time conversion
    results in Sat 25 Nov 1961 10:31:44 PM UTC. Therefore, it appears
    that the value is a correct 64-bit Unixtime for the file timestamp as
    it was on disk.

    I didn't expect that SIOREG.ZIP is that old ;-). It makes more sense now. The question is which of the two mailers doesn't handle the negative unix timestamp well.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Oli@2:280/464.47 to Andrew Leary on Sun Nov 10 10:04:24 2019
    mbcico (the mailer included with MBSE BBS) rejects the M_GOT
    with the 64-bit value and ends up trying to send the file again
    in the next session. I suspect that ifcico (which mbcico was
    based on) will do the same, although I haven't tested it yet.

    Every mailer should reject that M_GOT, the value doesn't make any
    sense.

    Incidentally, I discovered that the timestamp of that file on disk was showing as November 25, 1961, so it should be a negative value.
    Converting the decimal to hex yields FFFF FFFF F0C4 3650, which in 2's complement notation is -255576496. A quick Unix time conversion
    results in Sat 25 Nov 1961 10:31:44 PM UTC. Therefore, it appears
    that the value is a correct 64-bit Unixtime for the file timestamp as
    it was on disk.

    I polled your system with tcpdump running and sent a .pkt from 1966. It looks like a binkd bug to me:

    M_FILE 7eee1e8f.pkt 450 18446744073609551616 0

    instead of

    M_FILE 7eee1e8f.pkt 450 -100000000 0

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Oli@2:280/464.47 to Andrew Leary on Sun Nov 10 10:49:27 2019
    Incidentally, I discovered that the timestamp of that file on
    disk was showing as November 25, 1961, so it should be a negative
    value. Converting the decimal to hex yields FFFF FFFF F0C4 3650,
    which in 2's complement notation is -255576496. A quick Unix
    time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC.
    Therefore, it appears that the value is a correct 64-bit Unixtime
    for the file timestamp as it was on disk.

    I polled your system with tcpdump running and sent a .pkt from 1966.
    It looks like a binkd bug to me:

    M_FILE 7eee1e8f.pkt 450 18446744073609551616 0
    instead of
    M_FILE 7eee1e8f.pkt 450 -100000000 0

    The Binkp/1.0 spec (FTS-1026) says:

    In the basic implementation: size, unixtime and offset
    MUST be positive numbers or zero.

    What is the "basic implementation"? binkp/1.0 without any OPTs?
    binkp/1.1 allows a "-1" offset.

    The spec also states:
    File_size, unixtime and file_offset are decimal integers.
    Implementation note: mailer MUST check received string to
    prevent number overflow and skip file if overflow.

    What to do with the situation now? We have one implemenation that sends a negative unixtime and another implementation that returns a timestamp that is 584 biliion years in the future.

    I wish a negative unixtime were allowed by the specification in the first place.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Andrew Leary@1:320/219 to Oli on Sun Nov 10 04:16:58 2019
    Hello Oli!

    10 Nov 19 09:35, you wrote to me:

    Incidentally, I discovered that the timestamp of that file on
    disk was showing as November 25, 1961, so it should be a negative
    value. Converting the decimal to hex yields FFFF FFFF F0C4 3650,
    which in 2's complement notation is -255576496. A quick Unix
    time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC.
    Therefore, it appears that the value is a correct 64-bit Unixtime
    for the file timestamp as it was on disk.

    I didn't expect that SIOREG.ZIP is that old ;-). It makes more sense

    It's not. The file had a timestamp of 01-01-1998 on my OS/2 system; somehow the timestamp got grunged when I sent it over to the Linux machine using binkd 1.1a-99/OS2. I just tried sending it again, and the same timestamp corruption occurred.

    now. The question is which of the two mailers doesn't handle the
    negative unix timestamp well.

    Yes, and also the 64-bit vs. 32-bit question. I'll work on further testing today.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Oli@2:280/464.47 to Andrew Leary on Sun Nov 10 13:10:14 2019
    The file had a timestamp of 01-01-1998 on my OS/2 system;
    somehow the timestamp got grunged when I sent it over to the Linux
    machine using binkd 1.1a-99/OS2. I just tried sending it again, and
    the same timestamp corruption occurred.

    It's getting weirder ...

    now. The question is which of the two mailers doesn't handle the
    negative unix timestamp well.

    Yes, and also the 64-bit vs. 32-bit question. I'll work on further testing today.

    I don't see a 32-bit vs. 64-bit question at the binkp protocol level. It's just an ASCII string. Fun fact: FTS-1026 uses a number in the examples that cannot be encoded in 32-bit.

    M_FILE "config.sys 125 2476327846 100"

    2476327846 -> June 21, 2048 4:50:46 AM

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Kees van Eeten@2:280/5003.4 to Andrew Leary on Sat Nov 9 16:50:20 2019
    Hello Andrew!

    09 Nov 19 07:04, you wrote to Oli:

    Does it break compatibility with any mailer? You didn't mention any
    specific example.

    mbcico (the mailer included with MBSE BBS) rejects the M_GOT with the 64-bit value and ends up trying to send the file again in the next session. I suspect that ifcico (which mbcico was based on) will do the same, although I haven't tested it yet.

    There is no support for binkd in ifcico.

    Kees

    --- GoldED+/LNX 1.1.5--b20180707
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From mark lewis@1:3634/12.73 to Kees van Eeten on Mon Nov 11 19:42:58 2019

    On 2019 Nov 09 16:50:20, you wrote to Andrew Leary:

    mbcico (the mailer included with MBSE BBS) rejects the M_GOT with the
    64-bit value and ends up trying to send the file again in the next
    session. I suspect that ifcico (which mbcico was based on) will do
    the same, although I haven't tested it yet.

    There is no support for binkd in ifcico.

    i'm guessing you meant binkp, the protocol, and not binkd, the daemon/server ;)

    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.
    ... I sailed the ship all alone. I never think I'll make it home.
    ---
    * Origin: (1:3634/12.73)