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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
