[Swan-dev] sending raw bytes not logged since c5f6b12e9
Antony Antony
antony at phenome.org
Tue Feb 12 14:20:16 UTC 2019
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?
I use it in two cases.
1. It is very helpful in debugging interop issues.
2. Historic test runs, to compare sending raw bytes.
In test runs it is something I often go back and check in test run history.
I can imagine on a busy server it could be an issue and would be considered
as TMI. Then I wonder why received bytes is not TMI yet.
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.
-antony
PS: eyballing the size difference less 3.5Kbytes.
21199 west.pluto.log.gz, before 24966 west.pluto.log.gz
More information about the Swan-dev
mailing list