Title: AFP decodes
While decoding some netatalk traffic, I noticed that the decode of a MacOS X AFP login packet, when it's using the "Cleartxt Passwd" UAM, is not decoding the user password properly. Note that in the AFP doc, the password must be pre-padded with nulls to start on an even byte, and must be padded out to eight bytes. Here's the doc:
http://developer.apple.com/techpubs/macosx/Networking/AFP/Chapter_1/File_Server_Security.html#CHBHBGDD
The raw packet data meets this requirement, and the password starts on an odd byte, so it starts with a zero byte. Ethereal decodes it as an empty string, because it appears to be assuming the string is zero terminated.
Here's what I am seeing. Note that this packet is correct, according to the protocol description.
Screen appearance:
UAM: Cleartxt Passwd
User: macuser
Password:
Data (1 byte)
Raw:
10 43 .C
6c 65 61 72 74 78 74 20 70 61 73 73 77 72 64 07 leartxt passwrd.
6d 61 63 75 73 65 72 00 70 61 73 73 77 6f 72 64 macuser. password
(packet ends after 'd' in password)
When the "Password" line is highlighted in the packet decode window, only the zero before the password text is highlighted in the raw data window.
A trace containing the above packet (packet number 7) is attached.
---
Andrew C. Esh mail:Andrew.Esh@xxxxxxxxxxx
Tricord Systems, Inc.
2905 Northwest Blvd., Suite 20 763-557-9005 (main)
Plymouth, MN 55441-2644 USA 763-551-6418 (direct)
http://www.tricord.com - Tricord Home Page
Attachment:
trace200210231658.pcap
Description: Binary data
