[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