What's the protocol behind the "Responder"?

robin-fo

Well-known member
Hi everyone

As some of you might be aware, most classic Mac systems with running AppleTalk stack advertise themselves using their model names ( System 7.1 and earlier ) or a generic name like " Power Macintosh" in an NBP lookup. The corresponding socket (mostly socket numbers like 252 or 253) responds to ATP requests (e.g. with user bytes 0x00000001 and no payload) with some binary data and strings containing detailed operating system version information.

An application which sends request to this socket is e.g. Apple Inter•Poll.

Is there any documentation which describes this protocol?

Bildschirmfoto 2023-01-20 um 00.35.34.png
 

robin-fo

Well-known member
Not to derail, but I just noticed your avatar. Is that a mermaid Mac? :)
YES! 🤩 (I’m so glad somebody found out 😅) It‘s based upon the traditional figure of the double tailed mermaid on which for example also the Starbucks Coffee logo is based. The hands were also inspired by the logo of a local brewery. I drew everything using Adobe Illustrator 10 running on MacOS 9. The Mac, hands and the LocalTalk box are traced from different photos.

I also made an ASCII art version:
C:
/*
 *              ____________________
 *             |   ______________   |
 * ==-         |  |              |  |         -==
 *     \       |  |    *    *    |  |       /
 *      |      |  |       L      |  |      |
 *     __.     |  |   \______/   |  |     .__
 *     == \____|  |______________|  |____/ ==
 *     ==-_____|                    |_____-==
 *    /        |====================|       \
 *    |        |                   |        |
 *    |        |____________________|        |
 *     \        |__________________|        /
 *     \               _||_               /
 *      \             |    |             /
 *        \           | __ |           /
 *          \          J  J          /
 *            \        |  |        /
 *              \--___/    \___--/
 *
 */
 

gcp

Well-known member
YES! 🤩 (I’m so glad somebody found out 😅) It‘s based upon the traditional figure of the double tailed mermaid on which for example also the Starbucks Coffee logo is based. The hands were also inspired by the logo of a local brewery. I drew everything using Adobe Illustrator 10 running on MacOS 9. The Mac, hands and the LocalTalk box are traced from different photos.

I also made an ASCII art version:
That is all awesome :)
 

robin-fo

Well-known member
Here is what I have been able to reverse engineer so far:

The bytes following the AppleTalk driver version are still somewhat mysterious.. After very long analysis of Responder responses from many Macintosh/OS/Software combinations, I found out that the third byte of the ATP payload is the ROM version of the Mac (as returned by the Gestalt Manager 'romv'). The following byte is even more interesting: With version 1.0 of the Responder extension, this is the model identifier of the Mac. With later versions, this is the model identifier incremented by 1 on most Macs. This is likely due to the "insertion" of a "Macintosh XL Plus" (probably a Lisa with MacWorks Plus) into the series of Macintosh models. The following bytes are still rather obscure, but appear to relate to the Mac model or responder version.

Towards the end of the packet, there are two more obscure bytes which appear to relate to the installed AppleShare (Client?) version. Maybe this is a 16-bit integer, a zero-length pascal string or just two separate bytes, but the first appears to be always 0 and the second some kind of version number or enumeration. But depending on this value, there is a further pascal string following with the short version string of the AppleShare Client extension installed on the system.

Possible meanings of 16-bit (?) AppleShare version:

0x00 AppleShared not installed (no string follows)
0x01...0x09: Undefined,
0x??: AppleShare version 1.0
0x0A: AppleShare version 1.1
0x0B: AppleShare version 2.0 Pre-Release
0x0C: ?? Pascal string follows (seen on System 7.1)
0x0E: ?? Pascal string follows (seen with AppleShare D1 3.8.8, Mac OS 9)


SIP.png

For anyone willing to assist to decode the unknown bytes at the beginning of the response packet, here are some examples with the strings omitted:
Mac Plus: 75 04 01 e0 7f ff 00 00 (System US-6.0.4, Responder 1.0.0) Mac Plus: 75 05 01 e0 7f ff 01 00 (System 6.0.5, Responder 1.1.1) Mac Plus: 75 05 01 e0 7f ff 01 00 (System US-6.0.4, Responder 1.1.1) Mac Plus: 75 05 01 e0 7f ff 01 01 (System SD1-6.0.8, Responder 1.1.1) Mac SE: 76 06 01 e4 7f ff 01 00 (System 6.0.5, Responder 1.1.1) Mac SE: 76 06 01 e4 7f ff 01 01 (System SD1-6.0.8, Responder 1.1.1) Mac SE: 76 06 01 e4 7f ff 02 01 (System SD1-6.0.8, Responder 2.0.3) Mac SE: 76 06 01 c4 7f ff 01 00 (System US-6.0.8, Responder 1.1.1) Mac II: 78 07 01 fc 3f ff 01 00 (System 6.0.5, Responder 1.1.1) Mac II: 78 07 01 fc 3f ff 02 01 (System 7.1.1) Mac SE/30: 78 0a 01 fc 3f ff 02 01 (System D1-7.1, Responder 2.0.4) Quadra 700:7c 17 01 fc 3f ff 02 0a (Mac OS 8.1, Reponder 2.0.4, AppleTalk 60.3) Quadra 800:7c 24 01 fc 3f ff 02 0a (System 7.1) CC: 7c 32 01 fc 3f ff 02 01 (System D1-7.6.1, Responder 2.0.4) PM 8550: 7d 45 01 ec 3f ff 02 0a (Mac OS 9.2.2, Responder 2.0.4) PM 9500: 7d 44 01 ec 3f ff 02 0a (Mac OS 8.0, Reponder 2.0.4) iMac G4: 7d 97 01 6d 3f ff 02 0a (Mac OS 9.2.2, Responder 2.0.3!, AppleTalk 61.0)




Here is a full packet received from a Macintosh SE, recorded using Wireshark. The ATP response packet (including user bytes) is shaded blue:

Bildschirmfoto 2023-07-22 um 16.59.14.png

The first four bytes 01 00 00 10 are the ATP user bytes. The first byte indicates a SIP/Responder response packet. The third and fourth tell the version of the Responder INIT or protocol version (in later versions of the Macintosh System Software, the Responder was integrated into other system extensions). In our case the version bytes are 00 10, indicating version 1.0 (?). With version 2.0.4, it would be 02 04.

The first two bytes following the four ATP user bytes indicate the AppleTalk driver version. In our case 00 30 indicates version 48.

76 is the ROM revision of the Macintosh SE

05 is its model identifier (With later revisions of the Responder, this byte would be 0x06)
 

robin-fo

Well-known member
Found this interesting struct in a file called adsp.h within the XNU kernel. Has anybody got a clue what ResponderLevel and ResponderLink could be? The GS/OS source code still calls these status bytes…

Could ResponderLink be the associated networking interface number? ResponderLevel is often 0x01 or 0x02 (0x00 for earliest versions of the Responder extension), maybe a hint to the AppleTalk phase? View attachment 83632
 

Attachments

  • IMG_4170.jpeg
    IMG_4170.jpeg
    886 KB · Views: 14

cheesestraws

Well-known member
OK, so I think I know what's going on, vaguely, in byte 4 after the appletalk version, the one labelled HdwrConfig in adsp.h.

It's the hwCfgFlags value, though bizarrely (at least if we take https://github.com/elliotnunn/super...j.1994-02-09/Internal/Asm/UniversalEqu.a#L696 as canonical), the bits are actually backwards.

Bit 7 - SCSI port present
Bit 6 - New clock chip present
Bit 5 - xPRAM valid
Bit 4 - FPU present
Bit 3 - MMU present
Bit 2 - ADB present
Bit 1 - Running A/UX
Bit 0 - Has Power Manager

Looking at the values you gave above makes sense:
  • The Plus (e0) has SCSI, the new clock chip, and xPRAM (which came in on the Plus). But it does not have ADB (bit 2).
  • The SE (e4, let's ignore c4 for the moment) has SCSI, the new clock chip, xPRAM and ADB (bit 2). The other SE, with value c4, looks like it had unwell xPRAM - is it batteryless or just had its PRAM reset?
  • Your II (fc) has nearly everything - FPU and MMU (does it?) but it isn't running A/UX and it doesn't have the power manager.
  • The other 68k macs in the list basically have everything too.
  • The PM 8550/9500 are interesting (ec); they have everything except the FPU. The 68k emulation doesn't pretend to have an FPU in these machines, AFAIK, and I'm assuming that's why that isn't showing up here. I doubt anyone bothered to fix that bit of Responder.
  • The iMac G4 is a nice control, because it's of the generation where legacy stuff went away and we indeed see a lot fewer bits set (6d). There is no SCSI, we do have new-style clock and xPRAM (although by this point calling it 'new' is a bit of a joke). We do not have an FPU, because the 68k emulator does not provide one. It's a little odd that it reports ADB present, though admittedly that bit isn't defined that the *port* is present, but it does claim to have the power manager. You could check this by looking at 'powr' in the Gestalt.
What do you think?
 
Last edited:
Top