[Swan-dev] sending raw bytes not logged since c5f6b12e9

[Paul Wouters]

On Tue, 12 Feb 2019, Antony Antony wrote:

> with the commit c5f6b12e9 pluto stopped logging sending raw bytes;
> with plutodebug=all.
>
> --- before c5f6b12e9
> | sending 792 bytes for reply packet for main_outI1 through eth1:500 to 192.1.2.23:500 (using #1)
> |   7f e3 ca f5  06 66 1e 28  00 00 00 00  00 00 00 00
> |   01 10 02 00  00 00 00 00  00 00 03 18  0d 00 02 84
>
> --- now, after c5f6b12e9
> | sending 792 bytes for reply packet for main_outI1 through eth1:500 to 192.1.2.23:500 (using #1)
> "westnet-eastnet" #1: IMPAIR: suppressing retransmits; scheduling timeout in 60 seconds
>
> However pluto still log raw received message, with plutodebug=all.
> | *received 144 bytes from 192.1.2.23:500 on eth1 (port=500)
> |   30 bc cf 3a  62 d7 0b ce  24 de 9e 80  d8 40 47 ea
> |   01 10 02 00  00 00 00 00  00 00 00 90  0d 00 00 38
>
> This confused me for a while.  My conclusion is c5f6b12e9 made it
> Too Much Information(TMI)

> I think sending raw bytes are not TMI.  may be it is a matter of taste.
> I open hear preferences, vote?

It should be the same for receive and send. I would like to see the 
"sending/received XXX bytes ...." message, byt I think the actual raw
bytes can be TMI.

> I use it in two cases.
> 1. It is very helpful in debugging interop issues.
> 2. Historic test runs, to compare sending raw bytes.

For our testcases, we really should have plutodebug=all,tmi

> My vote is to keep logging sending raw bytes with "plutodebug=all" before
> releasing 3.28.
>
> Anyone against making sending raw bytes part of plutodebug=all?
>
> However, if sending bytes are TMI I would start log TMI in test case.
> First I am off to figure out debug tmi syntax:) And I am wondering what else
> was lost due to TMI.

I agree testcases should have TMI

Paul