Packet Structure:

NN , NN , NNNN , NNNNNNNN , DATA
A  , B  , C    , D        , N or S depending on stage


A:

At first I thought it was some sort of re-transmit counter.  Now I think
it's the login stage counter (previously thought that was B, but now I see
that's wrong).  This seems to hold true, and would account for the much
larger values of A at the end of the login process.

B:

SUB-stage level **** This is probably the most likely explanation; I think
they have things like Stage X, Response/Communication Y.  I gather this
because Jay's dumps seem to have the same AA,BB codes for the successful
logins:

1: 01,01
2: 01,02
3: 02,03
4: 03,01
5: 03,02
6: 90,03
7: 99,03 (UDP)

These are exactly the same across dumps.  That's why I want some dumps of
failed logins.


C:

Always four 0's, I would assume at some point will probably be their own
CRC of the packet, either the packet itself or the data inside the TCP
packet.  No way to know, but most people that design and implement their
own protocols don't rely exclusively on the protocol and hardware layers
to do CRC checking, and since there is UDP involved, it's probably there
for consistency.

D:

8 char string (of numbers) indicating the length of the entire TCP packet,
in decimal.


Data sections (organized by stage:sublevel), based on successful login
---
01:01 (client -> server)
Data: 01,01,0000,xxxxxxxx, a(8), b(8), c(16), d(8),.

a = username
b = password
c = ip address
d = os

---
Response (Server -> Client):

TCP packet with zero len specified, but trails 6 bytes worth of garbage
(seemingly so, at least)

Probably indicates "data received", sort of like a custom ACK.

---
01:02 (server -> client)
Data: 01,02,0000,xxxxxxxx, a(8),.

a = username returned, probably indication of a successful login

---
Response (Client -> Server):

TCP packet with szero len specified, actually empty

Probably indicates "data received", sort of like a custom ACK.

---
02:03 (client -> server)
Data: 02,03,0000,xxxxxxxx, a(8), b(2), Cxb (32, 8)

a = os
b = number of fields to follow (gleaned from comp. w/ Jay's dump)

C: b[n] -> c(32), d(8)

c = some associated configuration file
d = c's version number

---
03:01 (server -> client)
Data: 03,01,0000,xxxxxxxx,.

Probably either an ACK, or an escalation to the next logion stage, or a
request for additional/another type of information.

---
03:02 (client -> server)
Data: 03,02,0000,xxxxxxxx,.

Response to sublevel 01; probably means "I have no more information", or
"I have no information associated with stage 03".

---
Response (server -> client):

TCP packet with zero len specified, with trailing garbage (6 bytes)

Again, probably a custom ACK.

---
90:03 (server -> client):
Data: 90,03,0000,xxxxxxxx,.

Probably logon stage escalation "90" might mean it successfully completed
whatever process is involved with activating your routing.

Read the stuff on Phil Karn's website about how it all actually works.
I'd bank on the wide range of unused codes as possible error response
codes to something in that whole chain of events not working.

Or maybe 90 is successful login, and 03 is a successful third (in a 3
stage process) stage completion.  Makes some sense.

---
Response (server -> client)

TCP FIN packet with trailing garbage (close connection)

---
Response (client -> server)

(2 packets) TCP ACK, TCP FIN  (close connection)

---
UDP response (client -> server)
99:03
Data: 99,03,0000,xxxxxxxx, a(8),.

a = ip address

------

Immediately following the UDP ping, TAS port 80 (NOT 8080!) is hit.  A
couple accesses are registered before the connection is torn down with an
RST TCP packet.  After that, it doesn't look like there's anything else.