openssh unix dev - Aug 2003 - Reg. openssh-3.51p1/packet.c (function packet_send2())

Hi, 
Will really appreciate for any comments on the below:

1. According to draft-ietf-secsh-transport-16.txt (section 4), each packet 
must be of the following format:

uint32    packet_length
byte      padding_length
byte[n1]  payload; n1 = packet_length - padding_length - 1
byte[n2]  random padding; n2 = padding_length
byte[m]   mac (message authentication code); m = mac_length

However, since i wanted to verify this, I put some debugging code in 
openssh-3.51p1/packet.c (function packet_send2()), which can be accessed 
at http://mia.ece.uic.edu/cgi-bin/lxr/http/source/packet.c?v=openssh-3.5p1#L619.

I conducted some tests by sending PPP packets and found out that the 
tranport layer (i think) just appends an extra 14 bytes to the begining of 
the PPP frame. The first 4 bytes of these are used to put in the 
packet_length and the next 1 byte is used to put in the padding_length.
However the rest 9 bytes remain unused.. 

Question: 
1. Is this observation correct? Or am i missiing a point here.
2. If it is correct, then is there a new ietf draft that reflects this 
change.
3. Any comments are welcome.

Thanks
shashank 


Below is an example output:

1. The PPP frame (len = 136) in the below example starts and ends on 
character "0x7e". (No character stuffing is in effect). You can see
that the packet is
appended with the first 14 bytes. 
plain:     
0000 0000 005e 0000 0000 0000 0088 7eff
0300 2145 0000 8000 0040 0040 11bb 89c0
a8fe c8c0 a8fe c994 7194 7000 6cf5 4000
0000 02c6 2e31 3f11 4d07 0053 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 53c6 8c7e

2. To calculate padding bytes, the code uses the length of the above 
packet (i.e. 136 + 14 = 150) and calculates (8 - (150 % 8) = 2). Since 
this is less than 4 bytes, it adds another 8 bytes of padding to allow 10 
bytes of pading.

2. The packet length is correctly calculated as 0x9c (=156), and the 
padding  length is correctly calculated as 0x0a (=10) in the below output.

send: len 160 (includes padlen 10)
0000 009c 0a5e 0000 0000 0000 0088 7eff
0300 2145 0000 8000 0040 0040 11bb 89c0
a8fe c8c0 a8fe c994 7194 7000 6cf5 4000
0000 02c6 2e31 3f11 4d07 0053 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 5353 5353 5353 5353 5353 5353 5353
5353 53c6 8c7e 7e24 ef79 f0fe 1a95 a450

hi, what is all this ppp talk about?

why don't you just recompile packet.c
with PACKET_DEBUG? what exactly is the problem?