[tcpdump-workers] Re: TCP Header Flags

2023-02-27 Thread Denis Ovsienko
On Mon, 27 Feb 2023 03:31:27 +0100
Francois-Xavier Le Bail  wrote:

> There are already some doc/site with bad use of "tcp-psh" instead of
> "tcp-push" like: https://packetlife.net/media/library/12/tcpdump.pdf

The author has been notified about the error.

> https://github.com/the-tcpdump-group/tcpdump/issues/846

This indeed had happened.  Would it be correct to say only once in a
long time?

> https://github.com/tcpdump-examples/how-to-use-tcpdump

The fragment titled "Isolate TCP PSH flags." along with many others
is an old copy from https://danielmiessler.com/study/tcpdump/ and the
original document now says "tcp-push".

> https://blog.codefarm.me/2018/12/29/tcpdump-examples/

Another old copy from https://danielmiessler.com/study/tcpdump/.

> https://twitter.com/dc9221/status/1254154374143754241/photo/1

The above is a series of screenshots of
https://packetlife.net/media/library/12/tcpdump.pdf with the copyright
replaced with somebody else's.  See also
https://packetlife.net/blog/2016/mar/9/dont-be-discouraged-plagiarists/

> https://github.com/marciopocebon/TCPDUMP-1

Another old copy from https://danielmiessler.com/study/tcpdump/.

> ...
> Thus, the problem already exists in reverse.

It has been this way for 32 years, so let's either fix this properly
with backward compatibility notes, or not at all.  And in any case,
with a clear understanding which is the right thing.

-- 
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[tcpdump-workers] Re: TCP Header Flags

2023-02-26 Thread Francois-Xavier Le Bail
On 26/02/2023 22:45, Denis Ovsienko wrote:
> On Sun, 26 Feb 2023 15:46:56 +0100
> Francois-Xavier Le Bail  wrote:
> 
> [...]
 I wonder if there would be any other incurred future maintenance.  
>>
>> The proposed patch is:
>>
>> diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
>> index 10aeb42d..864cd238 100644
>> --- a/pcap-filter.manmisc.in
>> +++ b/pcap-filter.manmisc.in
>> @@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are
>> available: .BR \%icmp6-multicastrouterterm .
>>  .IP
>>  The following TCP flags field values are available: \fBtcp-fin\fP,
>> -\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
>> +\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
>>  \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
>>  \fBtcp-cwr\fP.
>>  .LP
>> diff --git a/scanner.l b/scanner.l
>> index 85fe395a..7cc39f77 100644
>> --- a/scanner.l
>> +++ b/scanner.l
>> @@ -475,6 +475,7 @@ tcp-fin { yylval->h = 0x01;
>> return NUM; } tcp-syn{ yylval->h = 0x02;
>> return NUM; } tcp-rst{ yylval->h = 0x04;
>> return NUM; } tcp-push   { yylval->h = 0x08; return NUM; }
>> +tcp-psh{ yylval->h = 0x08; return NUM; }
>>  tcp-ack{ yylval->h = 0x10; return NUM; }
>>  tcp-urg{ yylval->h = 0x20; return NUM; }
>>  tcp-ece{ yylval->h = 0x40; return NUM; }
>>
>> (the tcpdump man page will need an update too.)
> 
> Obviously, the change would be easy to make.  But what comes to my mind
> is next 5 or 10 years of answering the same question: "Why tcp-psh is in
> the man page/my new book/stackoverflow/whatever and it works in my
> development environment, but some production servers reject the syntax?
> These are on a very expensive long term support contract, so everything
> is supposed just to work, right?  Right?"

There are already some doc/site with bad use of "tcp-psh" instead of "tcp-push" 
like:
https://packetlife.net/media/library/12/tcpdump.pdf
https://github.com/the-tcpdump-group/tcpdump/issues/846
https://github.com/tcpdump-examples/how-to-use-tcpdump
https://blog.codefarm.me/2018/12/29/tcpdump-examples/
https://twitter.com/dc9221/status/1254154374143754241/photo/1
https://github.com/marciopocebon/TCPDUMP-1
...
Thus, the problem already exists in reverse.

___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[tcpdump-workers] Re: TCP Header Flags

2023-02-26 Thread Denis Ovsienko
On Sun, 26 Feb 2023 15:46:56 +0100
Francois-Xavier Le Bail  wrote:

[...]
> >> I wonder if there would be any other incurred future maintenance.  
> 
> The proposed patch is:
> 
> diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
> index 10aeb42d..864cd238 100644
> --- a/pcap-filter.manmisc.in
> +++ b/pcap-filter.manmisc.in
> @@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are
> available: .BR \%icmp6-multicastrouterterm .
>  .IP
>  The following TCP flags field values are available: \fBtcp-fin\fP,
> -\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
> +\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
>  \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
>  \fBtcp-cwr\fP.
>  .LP
> diff --git a/scanner.l b/scanner.l
> index 85fe395a..7cc39f77 100644
> --- a/scanner.l
> +++ b/scanner.l
> @@ -475,6 +475,7 @@ tcp-fin { yylval->h = 0x01;
> return NUM; } tcp-syn{ yylval->h = 0x02;
> return NUM; } tcp-rst{ yylval->h = 0x04;
> return NUM; } tcp-push   { yylval->h = 0x08; return NUM; }
> +tcp-psh{ yylval->h = 0x08; return NUM; }
>  tcp-ack{ yylval->h = 0x10; return NUM; }
>  tcp-urg{ yylval->h = 0x20; return NUM; }
>  tcp-ece{ yylval->h = 0x40; return NUM; }
> 
> (the tcpdump man page will need an update too.)

Obviously, the change would be easy to make.  But what comes to my mind
is next 5 or 10 years of answering the same question: "Why tcp-psh is in
the man page/my new book/stackoverflow/whatever and it works in my
development environment, but some production servers reject the syntax?
These are on a very expensive long term support contract, so everything
is supposed just to work, right?  Right?"

You could argue that there would be a note in the "backward
compatibility" section, but I could argue that only a fraction of users
ever reads any documentation that comes directly with the software.  It
would be better to have some other problems solved before looking at
this discrepancy again.

Specifically, I wonder if it would be practicable to process all
remaining longjmp() backlog in the next few months.  The script reports
35 not yet converted files ranging from 110 to 2755 CLOC each.

-- 
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[tcpdump-workers] Re: TCP Header Flags

2023-02-26 Thread Francois-Xavier Le Bail
On 19/02/2023 13:34, Francois-Xavier Le Bail wrote:
> On 18/02/2023 21:51, Denis Ovsienko wrote:
>> On Sat, 18 Feb 2023 17:06:29 +0100
>> Francois-Xavier Le Bail  wrote:
>>
>>> Hello,
>>>
>>> https://www.rfc-editor.org/rfc/rfc9293 states:
>>> "Control bits:
>>>
>>> The control bits are also known as "flags". Assignment is managed
>>> by IANA from the "TCP Header Flags" registry [62]. The currently
>>> assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN."
>>>
>>> (All on three characters.)
>>>
>>> To be in sync with it, we could use 'tcp-psh' in addition to
>>> 'tcp-push' in libpcap scanner.l, and in pcap-filter.7 and tcpdump.1
>>> man pages.
>>
>> That's an interesting point.  Adding "tcp-psh" would certainly restore
>> consistency with the registry on one hand.  On the other, for backward
>> compatibility reasons "tcp-push" would have to remain a valid alias for
>> who knows how many years.
> 
> We could keep "tcp-push" indefinitely...
> 
>> I wonder if there would be any other incurred future maintenance.

The proposed patch is:

diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
index 10aeb42d..864cd238 100644
--- a/pcap-filter.manmisc.in
+++ b/pcap-filter.manmisc.in
@@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are available:
 .BR \%icmp6-multicastrouterterm .
 .IP
 The following TCP flags field values are available: \fBtcp-fin\fP,
-\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
+\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
 \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
 \fBtcp-cwr\fP.
 .LP
diff --git a/scanner.l b/scanner.l
index 85fe395a..7cc39f77 100644
--- a/scanner.l
+++ b/scanner.l
@@ -475,6 +475,7 @@ tcp-fin { yylval->h = 0x01; return NUM; 
}
 tcp-syn{ yylval->h = 0x02; return NUM; }
 tcp-rst{ yylval->h = 0x04; return NUM; }
 tcp-push   { yylval->h = 0x08; return NUM; }
+tcp-psh{ yylval->h = 0x08; return NUM; }
 tcp-ack{ yylval->h = 0x10; return NUM; }
 tcp-urg{ yylval->h = 0x20; return NUM; }
 tcp-ece{ yylval->h = 0x40; return NUM; }

(the tcpdump man page will need an update too.)
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[tcpdump-workers] Re: TCP Header Flags

2023-02-26 Thread Francois-Xavier Le Bail
On 19/02/2023 13:34, Francois-Xavier Le Bail wrote:
> On 18/02/2023 21:51, Denis Ovsienko wrote:
>> On Sat, 18 Feb 2023 17:06:29 +0100
>> Francois-Xavier Le Bail  wrote:
>>
>>> Hello,
>>>
>>> https://www.rfc-editor.org/rfc/rfc9293 states:
>>> "Control bits:
>>>
>>> The control bits are also known as "flags". Assignment is managed
>>> by IANA from the "TCP Header Flags" registry [62]. The currently
>>> assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN."
>>>
>>> (All on three characters.)
>>>
>>> To be in sync with it, we could use 'tcp-psh' in addition to
>>> 'tcp-push' in libpcap scanner.l, and in pcap-filter.7 and tcpdump.1
>>> man pages.
>>
>> That's an interesting point.  Adding "tcp-psh" would certainly restore
>> consistency with the registry on one hand.  On the other, for backward
>> compatibility reasons "tcp-push" would have to remain a valid alias for
>> who knows how many years.
> 
> We could keep "tcp-push" indefinitely...
> 
>> I wonder if there would be any other incurred future maintenance.

The proposed patch is:

diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
index 10aeb42d..864cd238 100644
--- a/pcap-filter.manmisc.in
+++ b/pcap-filter.manmisc.in
@@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are available:
 .BR \%icmp6-multicastrouterterm .
 .IP
 The following TCP flags field values are available: \fBtcp-fin\fP,
-\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
+\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
 \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
 \fBtcp-cwr\fP.
 .LP
diff --git a/scanner.l b/scanner.l
index 85fe395a..7cc39f77 100644
--- a/scanner.l
+++ b/scanner.l
@@ -475,6 +475,7 @@ tcp-fin { yylval->h = 0x01; return NUM; 
}
 tcp-syn{ yylval->h = 0x02; return NUM; }
 tcp-rst{ yylval->h = 0x04; return NUM; }
 tcp-push   { yylval->h = 0x08; return NUM; }
+tcp-psh{ yylval->h = 0x08; return NUM; }
 tcp-ack{ yylval->h = 0x10; return NUM; }
 tcp-urg{ yylval->h = 0x20; return NUM; }
 tcp-ece{ yylval->h = 0x40; return NUM; }

(the tcpdump man page will need an update too.)
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[tcpdump-workers] Re: TCP Header Flags

2023-02-19 Thread Francois-Xavier Le Bail
On 18/02/2023 21:51, Denis Ovsienko wrote:
> On Sat, 18 Feb 2023 17:06:29 +0100
> Francois-Xavier Le Bail  wrote:
> 
>> Hello,
>>
>> https://www.rfc-editor.org/rfc/rfc9293 states:
>> "Control bits:
>>
>> The control bits are also known as "flags". Assignment is managed
>> by IANA from the "TCP Header Flags" registry [62]. The currently
>> assigned control bits are CWR, ECE, URG, ACK, PSH, RST, SYN, and FIN."
>>
>> (All on three characters.)
>>
>> To be in sync with it, we could use 'tcp-psh' in addition to
>> 'tcp-push' in libpcap scanner.l, and in pcap-filter.7 and tcpdump.1
>> man pages.
> 
> That's an interesting point.  Adding "tcp-psh" would certainly restore
> consistency with the registry on one hand.  On the other, for backward
> compatibility reasons "tcp-push" would have to remain a valid alias for
> who knows how many years.

We could keep "tcp-push" indefinitely...

> I wonder if there would be any other incurred future maintenance.
> 
> The fact tcpdump(1) prose says "PUSH" instead of "PSH" may be related
> to the origin of this discrepancy.  Perhaps this is the only part that
> can be fixed immediately without unwanted side effects.

There is not even consistency in the tcpdump man page (PUSH and PSH):
$ git grep -En '\<(PSH|PUSH)\>' tcpdump.1.in
tcpdump.1.in:1322:F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E 
(ECN-Echo) or
tcpdump.1.in:1389:The PUSH flag is set in the packet.
tcpdump.1.in:1415:.I CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
tcpdump.1.in:1486:left, so the PSH bit is bit number 3, while the URG bit is 
number 5.


___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s