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.
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.
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.
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 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?
Does it break compatibility with any mailer? You didn't mention any specific example.
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".
[...]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 ===
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.
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.
Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" +
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.
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.
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.
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
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.
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.
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.
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.
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 103 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 74:15:03 |
| Calls: | 157 |
| Files: | 6 |
| Messages: | 110,473 |