Excellent!! Johnny, I'll take you over Wireshark any day!
So, I found the problem: the flag breakout routine actually works
just fine. However, in one place I properly called it with a
pointer to the flags (which is the calling convention I defined)
and but in another, I called it with the flags themselves and used
those flags as the pointer to the flags! Whoops...
Since this was a small value, it typically picked up the flags in
a register file (the first 16 memory locations are aliased to the
accumulators) or in very low memory where I don't store anything.
Sometimes it used the stack pointer which has negative number in
the left half word and I got some very interested results from
that. Sigh...
Not sure why I didn't fail completely with some sort of out-of-bounds addressing failure. Oh well, at least I know that using complete junk won't blow the flag display routine up...
On 11/29/22 8:32 PM, Johnny Billquist wrote:
Here is a packet capture of the data I got when I ran NFT to look at the directory entry for a file on MIM::
02:20:43.129061 IP mim.stupi.net.7721 > jocke.bqtnet.se.64001: Flags [.], seq 167:346, ack 227, win 5840, length 179
0x0000: 4500 00db 8c4e 0000 3206 af64 c06c ca4a E....N..2..d.l.J
0x0010: c0a8 010b 1e29 fa01 26cb dc81 1027 8a51 .....)..&....'.Q
0x0020: 5010 16d0 5947 0000 0e00 0000 8102 1504 P...YG..........
0x0030: 0d04 0004 015b 01ac 0280 1000 0000 8102 .....[..........
0x0040: 1504 0d04 0010 015b 01ac 0300 0001 8900 .......[........
0x0050: 0000 8102 1504 0d04 0060 015b 01ac 0200 .........`.[....
0x0060: 0f02 0608 0444 5531 3a0f 0207 0405 5b42 .....DU1:.....[B
0x0070: 5154 5d0f 020f 020d 4c4f 4749 4e2e 434d QT].....LOGIN.CM
0x0080: 443b 3130 3102 0216 cc80 7d02 0202 0500 D;101.....}.....
0x0090: 88cb 4540 0002 0500 0204 0020 0100 0d02 ..E@............
0x00a0: 270b 3231 2d41 5052 2d32 3220 3131 3a32 '.21-APR-22.11:2
0x00b0: 383a 3139 3231 2d41 5052 2d32 3220 3131 8:1921-APR-22.11
0x00c0: 3a32 383a 3230 0100 0e02 0e1f 065b 372c :28:20.......[7,
0x00d0: 3134 5d00 008b 028b 0206 00 14]........
This is using Multinet over TCP. And you have a couple of DAP packets in here. But the interesting one starts at offset 0x9E.
There you have 0d02 - 0d is 13, which is a date and time attributes extension message. 02 is then the flags. Length field present, and nothing more. Length field is 8 bits, and have the value 27(16), or 39 bytes. Then comes the DATMENU bitfield, which is 0b, or 01011. So we have CDT, RDT and RVN in the packet.
Then comes the dates:
CDT = 21-APR-22 11:28:19
RDT = 21-APR-22 11:28:20
RVN = 1
And that match perfectly with what the file actually have. Also worth noting that the packet length of 39 bytes seems very reasonable. Each date string is 18 bytes, so we have 18+18+2+1 for a total of 39.
Johnny
On 2022-11-30 02:16, Johnny Billquist wrote:
Yeah. That table match what I can see. And just to point out the obvious: the values are in octal.
And no, I cannot find anything that would affect that byte later.
Johnny
On 2022-11-30 02:14, Thomas DeBellis wrote:
Oh, I could certainly get bit 4 if I didn't do the decode properly (likely) or bumped into a bug (less likely). You know, got it .../wrong/...
Meanwhile, I just wanted to make absolutely _certain___ that I have my RSX bits straight. /IF/ reserved bit 4 were defined as, say, HF.RSV, would it be like the below? Is this table correct?
DAP
Bit RSX
Symbol PDP-11
Octal Comment
0 HF.STR 1 Stream ID bit in DAP header menu
1 HF.LEN 2 Length bit in DAP header menu
2 HF.XLN 4 Extended length bit in DAP header menu
3 HF.BIT 10 BITCNT bit in DAP header menu
4 HF.RSV 20 Reserved
5 HF.SYS 40 System specific field bit in DAP header menu
6 HF.SEG 100 Segmented msg bit in DAP header menu
I think what RSX is doing sounds completely straightforward and proper. I don't suppose there is anything that could decide to play with the flags byte downstream?
It's possible that I'm dumping flags in a message that doesn't have any flags. It looks like DAP allows this. On page 17, one finds
DAP messages can be truncated up to the point
of leaving only the TYPE field provided the
fields truncated are not needed or can be
defaulted. This is particularly useful with
the Acknowledge Message which reduces the ACK
to a one byte message.
so I'll see if I'm respecting that.
------------------------------------------------------------------------
On 11/29/22 7:42 PM, Johnny Billquist wrote:
I was reading through the code that creates the DAP message, and it starts off with clearing the byte, then it checks if the system supports multiple streams, and if so sets bit 0. Then it checks if a length should be included, and if so, bit 1 is set, and if the length is >255, then bit 2 is also set.
And that is literally all that is done to the flags byte. So I can't see how you would get a message from MIM where bit 4 is set.
Johnny
------------------------------------------------------------------------
On 2022-11-30 01:37, Thomas DeBellis wrote:
Hum... Let me noodle over that for a bit.
I think it's a completely reasonable position to assume that I've a mistake, wrong assumption or am using something in such a way that it does not want to be used... After all, the code is brand new; just written, Etc.
I'll have to put some more instrumentation in, Etc, Etc.
I don't imagine there is anything clever about MIM::DU1:[DECNET]TEST.DIS;1? Don't see why there would be...
------------------------------------------------------------------------
On 11/29/22 7:09 PM, Johnny Billquist wrote:
What I can tell is what I can see in the sources. And there I have this:
HF.STR=001 ; Stream ID bit in DAP header menu
HF.LEN=002 ; Length bit in DAP header menu
HF.XLN=004 ; Extended length bit in DAP header menu
HF.BIT=010 ; BITCNT bit in DAP header menu
HF.SYS=040 ; System specific field bit in DAP header menu
HF.SEG=100 ; Segmented msg bit in DAP header menu
HT.BIT is the thing you are seeing which is not there in the DAP 5.6 spec. I don't really know what it is about, but it's something the RSX DAP have defined anyway.
I can't find any use of it. Looking in the code, I don't even see that it would ever be set. So I wonder if you made some mistake in your decoding?
Johnny
------------------------------------------------------------------------
On 2022-11-29 18:41, Thomas DeBellis wrote:
I fixed the bit definition for Not Last Message of Segmented Message from bit 4 to 6 as per DAP V5.6 and properly defined bit 4 as the Reserved field. In other words, I am following Tops-10, which I believe to have the correct definitions. Then I finished the flag breakout logic and tested again some systems. The MIM:: result is of note, viz.:
[Parsing Name message] [Parsing Attributes message] [Allocated Receive buffer (Words=531. Len=2086.)] [Trimmed 381. words from receive buffer] [Received Date/time Attributes message (Flg=*RESV*,SYSPEC UFlg=1000 Cnt=560.)] [Parsing Date/time Attributes message] [Parsing File Protection Attributes message] [Parsing Name message] TEST.DIS;1;P775656 2 2560(8) 18-Nov-2013 01:18:27
So what's up with *RESV*? Is (reserved) bit 4 being used for something new (I.E., post DAP 5.6) now? If so, what? The UFlg is an octal field for bits that I don't know about. In this case, MIM:: is sending bit 9 high, which the PDP-10 (which is the opposite endian) sees as bit 26. What's that?
Just wondering if I'm seeing what I'm seeing here...
------------------------------------------------------------------------
On 11/27/22 12:34 AM, Thomas DeBellis wrote:
Whoops, I mistyped the PDP-10 bit definition for bit six; it's 1B*29* and not 1B/28/. Sigh...
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B29
I looked the Tops-10 DAP flags definitions (in SWIL.MAC); it looks like Tops-10 has it right and Tops-20 has it wrong, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream ID field present 1B35 DF$SID
1 LENGTH field present 1B34 DF$HLN
2 LEN256 field present 1B33 DF$HL2
3 BITCNT field present 1B32 DF$BCT
*4* *Reserved* *1B31* *DF$XX1*
5 SYSPEC field present 1B30 DF$SHX
*6* *More data coming* *1B29* *DF$MOR*
Johnny, can you send me the RSX DAP flag definitions when you get a minute?
------------------------------------------------------------------------
On 11/26/22 11:58 PM, Thomas DeBellis wrote:
I was writing a routine to break out DAP flag bits to aid debugging when I noticed a possible discrepancy between DAP V5.6 and Tops-20, viz:
DAP
Bit Bit Meaning PDP-10
Bit Tops-20
DAP Symbol
0 Stream Identification Field Present 1B35 HD$SID
1 Length Field Present 1B34 HD$LEN
2 Extended Length Field Present 1B33 HD$LN2
3 Bit Count Field Present 1B32 HD$BCT
4 Reserved 1B31 HD$SEG
5 System Specific Field Present 1B30
6 Not last message of segmented message 1B28
DAP V5.6 reserves bit 4 and defines bit 6 to flag that a segmented message is being sent and that this is not the last message. In other words, that there will be another message. Tops-20 is using bit 4 for this purpose and by rights it would appear that it should be using bit 6.
I will go see if I can't scare up what Tops-10 is doing, but I was wondering if anyone knew what other OS's are doing.
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se