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