[tcpdump-workers] more testing emails
I'm sorry for the troubles. We are still getting continuous attempts to send email subscribe (DDoS) spam via HTTP, even though mailman2 is gone, and the links are are 404, but the script kiddies continue. fail2ban is doing some things, needs further tuning. But overall, it's just annoying. ___ 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
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
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
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
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
