PaddingField use only 0 as a padding

[getxsick]

It's OK for common issues but it deny to idea of UMPA where you can edit any bit you want.

Propably we should allow to use any padding value and "somehow" convert it for padding bits.

[getxsick]

anyway, and read again my own code and what realized is: value for PaddingField? is being used to set length of bits manually instead of generate necessary length.

so, if we wanna add possibility to change padding digit we should change a way to set length of bits.

personally, i'm not sure if it's worth. more important is to set length than what will padd it. but maybe i'm wrong. any suggestions by others?

[kosma]

Actually, I think the value should be used for padding, not for length.

My rationale is following: if we change the padding field length manually, UMPA and the network stack receiving the packet will disagree about where the header of the upper layer starts. As a result, that header will either have first few bytes missing (if the padding is too short) or will have garbage bytes added at the beginning (if the padding is too long):

Correct length:

+--------------+---------+----------+
|   IP header  | padding |TCP header|
+--------------+---------+----------+
                         ^ network stack looks for L4 header here

Padding too long:

+--------------+-----------+----------+
|   IP header  |  padding  |TCP header|
+--------------+-----------+----------+
                         ^ network stack looks for L4 header here

Padding too short:

+--------------+-------+----------+
|   IP header  |padding|TCP header|
+--------------+-------+----------+
                         ^ network stack looks for L4 header here

The result is essentially that we are are sending a broken L4 header, and that should be accomplished at Layer 4, not Layer 3. The situation is similar with TCP Options, but in that case it's the payload that gets truncated or gets garbage bytes added.

[getxsick]

go for it

[kosma]

Implemented in r5819.