* nftables and connection tracking @ 2020-06-21 5:54 Marek Greško 2020-06-21 8:06 ` Florian Westphal 2020-06-22 12:06 ` Pablo Neira Ayuso 0 siblings, 2 replies; 14+ messages in thread From: Marek Greško @ 2020-06-21 5:54 UTC (permalink / raw) To: netfilter Hello, I have problem to get connection tracking work when using nftables. I have this setup on my fedora 32: table ip raw { chain PREROUTING { type filter hook prerouting priority raw; policy accept; meta l4proto udp udp dport 5060 # CT helper sip } chain OUTPUT { type filter hook output priority raw; policy accept; meta l4proto udp udp dport 5060 # CT helper sip } } /etc/modules-load.d/conntrack.conf: nf_conntrack_ftp nf_conntrack_sip nf_conntrack_h323 nf_conntrack_irc nf_conntrack_amanda nf_conntrack_netbios_ns nf_conntrack_netlink nf_conntrack_pptp nf_conntrack_tftp nf_conntrack_broadcast nf_conntrack_snmp nf_conntrack_sane nf_nat nf_nat_ftp nf_nat_sip nf_nat_h323 nf_nat_irc nf_nat_amanda nf_nat_pptp nf_nat_snmp_basic nf_nat_tftp but I get no sound. When using iptables, everything is working. Should this be configured diffrent way? Thanks. Marek ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-21 5:54 nftables and connection tracking Marek Greško @ 2020-06-21 8:06 ` Florian Westphal [not found] ` <CAChjPdQtKBGuUvdveCVc5kmhA+fgP4DUDNKhNd11KUVCKNUZLg@mail.gmail.com> 2020-06-22 12:06 ` Pablo Neira Ayuso 1 sibling, 1 reply; 14+ messages in thread From: Florian Westphal @ 2020-06-21 8:06 UTC (permalink / raw) To: Marek Greško; +Cc: netfilter Marek Gre¨ko <mgresko8@gmail.com> wrote: > I have problem to get connection tracking work when using nftables. I > have this setup on my fedora 32: > > table ip raw { > chain PREROUTING { > type filter hook prerouting priority raw; policy accept; > meta l4proto udp udp dport 5060 # CT helper sip > } > > chain OUTPUT { > type filter hook output priority raw; policy accept; > meta l4proto udp udp dport 5060 # CT helper sip > } These rules don't do anything (it matches udp 5060, but no action is given). I suspect this from xtables-translate, which did not understand the -j CT --helper sip rule. This needs something like: table ip raw { ct helper sip { type "sip" protocol udp } chain prerouting { meta l4proto udp udp dport 5060 ct helper set "sip" } # same for output } ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAChjPdQtKBGuUvdveCVc5kmhA+fgP4DUDNKhNd11KUVCKNUZLg@mail.gmail.com>]
[parent not found: <20200621090142.GL26990@breakpoint.cc>]
* Re: nftables and connection tracking [not found] ` <20200621090142.GL26990@breakpoint.cc> @ 2020-06-21 9:39 ` Marek Greško 2020-06-21 10:45 ` Florian Westphal 0 siblings, 1 reply; 14+ messages in thread From: Marek Greško @ 2020-06-21 9:39 UTC (permalink / raw) To: netfilter Hello, unfortunately the helper is not there: conntrack -L | grep sip -> no output It is strange, that if I use iptables-nft it is working. Some userspace problem? Marek 2020-06-21 11:01 GMT+02:00, Florian Westphal <fw@strlen.de>: > Marek Gre≈°ko <mgresko8@gmail.com> wrote: >> Hello, >> >> thanks for your help. Unfortunately, it does not work either. > > Please keep mailing list on CC. > >> table ip raw { >> ct helper sip { >> type "sip" protocol udp >> } >> >> ct helper ftp { >> type "ftp" protocol tcp >> } >> >> chain PREROUTING { >> type filter hook prerouting priority raw; policy accept; >> meta l4proto udp udp dport 5060 ct helper set "sip" >> meta l4proto tcp tcp dport 21 ct helper set "ftp" >> } >> >> chain OUTPUT { >> type filter hook output priority raw; policy accept; >> meta l4proto udp udp dport 5060 ct helper set "sip" >> meta l4proto tcp tcp dport 21 ct helper set "ftp" >> } >> } > > Looks good. > >> Still nothing. > > Hmm, give it worked with iptables it should work with nft too since > the tracker is the same code. > > Try 'conntrack -L' and check if the udp flow has a helper assigned. > You might need to flush the conntrack table to make it pick up the > tracker (assigning it only works at the start of the connection). > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-21 9:39 ` Marek Greško @ 2020-06-21 10:45 ` Florian Westphal 2020-06-21 11:33 ` Marek Greško 2020-07-01 20:01 ` Marek Greško 0 siblings, 2 replies; 14+ messages in thread From: Florian Westphal @ 2020-06-21 10:45 UTC (permalink / raw) To: Marek Greško; +Cc: netfilter Marek Gre¨ko <mgresko8@gmail.com> wrote: > Hello, > > unfortunately the helper is not there: > > conntrack -L | grep sip -> no output > > It is strange, that if I use iptables-nft it is working. Some userspace problem? No, looks more like a kernel bug to me, I will have a look on Monday. In mean time, you can work around this bug by removing the entire "ip raw" / "ct set" stuff. and then use: sysctl net.netfilter.nf_conntrack_helper=1 to re-enable the old auto-assign behaviour. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-21 10:45 ` Florian Westphal @ 2020-06-21 11:33 ` Marek Greško 2020-07-01 20:01 ` Marek Greško 1 sibling, 0 replies; 14+ messages in thread From: Marek Greško @ 2020-06-21 11:33 UTC (permalink / raw) To: Florian Westphal; +Cc: netfilter Hello, thanks for the sysctl tip. It is wokring. The iptables-nft does not configure the nftables kernel in the same way? Because I did not see the problem when using it. Marek 2020-06-21 12:45 GMT+02:00, Florian Westphal <fw@strlen.de>: > Marek Gre≈°ko <mgresko8@gmail.com> wrote: >> Hello, >> >> unfortunately the helper is not there: >> >> conntrack -L | grep sip -> no output >> >> It is strange, that if I use iptables-nft it is working. Some userspace >> problem? > > No, looks more like a kernel bug to me, I will have a look on > Monday. > > In mean time, you can work around this bug by removing the entire "ip > raw" / "ct set" stuff. > > and then use: > sysctl net.netfilter.nf_conntrack_helper=1 > > to re-enable the old auto-assign behaviour. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-21 10:45 ` Florian Westphal 2020-06-21 11:33 ` Marek Greško @ 2020-07-01 20:01 ` Marek Greško 2020-07-01 22:48 ` Florian Westphal 1 sibling, 1 reply; 14+ messages in thread From: Marek Greško @ 2020-07-01 20:01 UTC (permalink / raw) To: Florian Westphal; +Cc: netfilter Hi Florian, please is it a bug the rules did not work in the raw table or was it my configuration error? If it is a bug is it a bug of kernel or userspace? If it was my configuration error, should not be the rules moved to the filter table? How is it possible that using iptables-nft the rules are added to the raw table and it is working? Thanks Marek 2020-06-21 12:45 GMT+02:00, Florian Westphal <fw@strlen.de>: > Marek Gre≈°ko <mgresko8@gmail.com> wrote: >> Hello, >> >> unfortunately the helper is not there: >> >> conntrack -L | grep sip -> no output >> >> It is strange, that if I use iptables-nft it is working. Some userspace >> problem? > > No, looks more like a kernel bug to me, I will have a look on > Monday. > > In mean time, you can work around this bug by removing the entire "ip > raw" / "ct set" stuff. > > and then use: > sysctl net.netfilter.nf_conntrack_helper=1 > > to re-enable the old auto-assign behaviour. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-07-01 20:01 ` Marek Greško @ 2020-07-01 22:48 ` Florian Westphal 2020-07-02 19:33 ` Marek Greško 0 siblings, 1 reply; 14+ messages in thread From: Florian Westphal @ 2020-07-01 22:48 UTC (permalink / raw) To: Marek Greško; +Cc: Florian Westphal, netfilter Marek Gre¨ko <mgresko8@gmail.com> wrote: > please is it a bug the rules did not work in the raw table or was it > my configuration error? Config error. > How is it possible that using iptables-nft the rules are added to the > raw table and it is working? iptables-nft and fntables are not the same. -j CT works with 'connection tracking templates', but the nft equivalent sets the helper directly. So, for iptables (and iptables-nft), the rule needs to be executed before conntrack lookup. With nft it has to be done after conntrack lookup. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-07-01 22:48 ` Florian Westphal @ 2020-07-02 19:33 ` Marek Greško 2020-07-02 19:47 ` Pablo Neira Ayuso 0 siblings, 1 reply; 14+ messages in thread From: Marek Greško @ 2020-07-02 19:33 UTC (permalink / raw) To: Florian Westphal; +Cc: netfilter Great, thanks for explanation. Now I have two chains OUTPUT with priority filter. One in the table raw and second in the table filter (currently both of them with policy accept). Is that correct? What is the order of evaluation? The order it appears in config file? Should not one of the priorities be changed to (filter + 1) or the rules moved to the filter table? Thanks Marek 2020-07-02 0:48 GMT+02:00, Florian Westphal <fw@strlen.de>: > Marek Gre≈°ko <mgresko8@gmail.com> wrote: >> please is it a bug the rules did not work in the raw table or was it >> my configuration error? > > Config error. > >> How is it possible that using iptables-nft the rules are added to the >> raw table and it is working? > > iptables-nft and fntables are not the same. > -j CT works with 'connection tracking templates', > but the nft equivalent sets the helper directly. > > So, for iptables (and iptables-nft), the rule needs to be > executed before conntrack lookup. With nft it has to be done > after conntrack lookup. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-07-02 19:33 ` Marek Greško @ 2020-07-02 19:47 ` Pablo Neira Ayuso [not found] ` <CAChjPdQb5wUP7Qbz=D-0jg-YFC0cWgV4oPJQD9-G7evi3SupAw@mail.gmail.com> 0 siblings, 1 reply; 14+ messages in thread From: Pablo Neira Ayuso @ 2020-07-02 19:47 UTC (permalink / raw) To: Marek Greško; +Cc: Florian Westphal, netfilter On Thu, Jul 02, 2020 at 09:33:41PM +0200, Marek GreÅ¡ko wrote: > Great, thanks for explanation. > > Now I have two chains OUTPUT with priority filter. One in the table > raw and second in the table filter (currently both of them with policy > accept). Is that correct? What is the order of evaluation? The order > it appears in config file? Should not one of the priorities be changed > to (filter + 1) or the rules moved to the filter table? Move them to the "filter" table, no need to define a new chain. Chains are somewhat expensives: one of the good things about nftables is that you can define the chains that you need. Chains whose priority is filter (0) see packets with the conntrack information. Anything from priority -200 onwards (INT_MAX) have access to the conntrack information. Priorities from INT_MIN to -199 see no conntrack information (what it used to be the "raw" table semantics). In nftables, tables have no specific semantics anymore, it's the chain priority that specifies what semantics apply to your basechain. Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAChjPdQb5wUP7Qbz=D-0jg-YFC0cWgV4oPJQD9-G7evi3SupAw@mail.gmail.com>]
[parent not found: <YUk8dCSHCUcKn+Xy@salvia>]
[parent not found: <CAChjPdREO=jtTNGc32H3mv+Zv8AHKbujb_a8=tkwC0+b2sbVCQ@mail.gmail.com>]
* Fwd: nftables and connection tracking [not found] ` <CAChjPdREO=jtTNGc32H3mv+Zv8AHKbujb_a8=tkwC0+b2sbVCQ@mail.gmail.com> @ 2021-09-24 5:21 ` Marek Greško 2021-09-24 7:19 ` Daniel 0 siblings, 1 reply; 14+ messages in thread From: Marek Greško @ 2021-09-24 5:21 UTC (permalink / raw) To: netfilter Sorry, repost to the mailing list. Marek ---------- Forwarded message ---------- From: Marek Greško <mgresko8@gmail.com> Date: Thu, 23 Sep 2021 20:05:33 +0200 Subject: Re: nftables and connection tracking To: Pablo Neira Ayuso <pablo@netfilter.org> Hello, no rule is blocking traffic. There is no match for rule so the udp drops. If I add accept rule as a last rule of the INPUT chain, it works. I tried conntrack -F without any progress. The conntrack -L expect shows some local sip phone 5060 connections and sip provider connection. No nat phones here. Even after reboot when it is working after reboot there is nothing about natted phones, Yes debugging would be probably the best, could you tell me how to debug it? I had never such firewall problems for 25 years history. I did not try to revert to iptables yet. To be honest, I do not expect it to be a configuration problem, but one never knows. Thanks Marek 2021-09-21 3:59 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>: > On Thu, Sep 16, 2021 at 10:32:01PM +0200, Marek Greško wrote: >> Hello, >> >> I would like to make the revival of this thread. My current >> configuration looks like this: >> >> table ip filter { >> ct helper sip { >> type "sip" protocol udp >> l3proto ip >> } >> >> chain PREROUTING { >> type filter hook prerouting priority filter; policy accept; >> udp port 5060 ct helper set "sip" >> } >> >> chain INPUT { >> ... >> ct state invalid drop >> ct state related accept >> ct state established accept >> ... >> iifname "ppp0" jump i-inet >> } >> >> chain OUTPUT { >> type filter hook output priority filter; policy accept; >> udp port 5060 ct helper set "sip" >> ... >> } >> >> chain i-inet { >> ... >> udp port 5060 jump r-sip >> ... >> } >> >> chain r-sip { >> ip saddr 192.0.2.0/24 accept >> } >> } >> >> table ip mangle { >> chain PREROUTING { >> type filter hook prerouting priority mangle; policy accept; >> ... >> udp sport 5060 ip dscp set 0x04 >> } >> >> chain OUTPUT { >> type route hook output priority mangle; policy accept; >> ... >> udp dport 5060 ip dscp set 0x04 >> ... >> } >> } >> >> table ip6 filter { >> ct helper sip { >> type "sip" protocol udp >> l3proto ip6 >> } >> >> ... pretty the same, but I have no ipv6 internet connectivity, so >> this should not match ... >> >> } >> >> I run the nftables locally on the asterisk server. The phones located >> on the local lan are working ok. But the remote phones behind nat are >> experiencing intermittent problems. After several days of working >> there is suddenly no audio. We with some guys on the asterisk list >> have found out it is a nftables problem. But I am not sure whether it >> is configuration problem or a bug. >> >> The problem is that when the rtp stream is built the stream incoming >> to asterisk is blocked by nftables > > What rule is blocking the traffic? > >> and thus asterisk never learns the >> public ip of the remote phone and is sending rtp stream to it's >> internal address. So there is no audio in either direction. When I >> enable rtp udp port range to pass to the asterisk it works. After >> blocking again it stops working. To resolve the problem for several >> days I found out that rebooting of the remote router resolves the >> issue. > > Did you try 'conntrack -F' instead of rebooting to flush the conntrack > table? What does 'conntrack -L expect' shows? > >> I have one successful resolving by rebooting the asterisk >> server the problematic nftables is running on. The proble arises again >> in several days. The problem is too frequent to be accepted, but too >> rare to be debugged. I have not tried the trick with sysctl above, >> yet. >> >> Do you think this could be a configuration problem? > > Even if it's a configuration problem, debugging the ruleset would be > needed. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Fwd: nftables and connection tracking 2021-09-24 5:21 ` Fwd: " Marek Greško @ 2021-09-24 7:19 ` Daniel 0 siblings, 0 replies; 14+ messages in thread From: Daniel @ 2021-09-24 7:19 UTC (permalink / raw) To: netfilter Hello, For the list information, on Asterisk list we asked Marek to open UDP RTP range ports but he don't want (security reason are his words). We run few Asterik servers with nftables, various versions, and never run any problem. And we are from far not alone with such setup. Le 24/09/2021 à 07:21, Marek Greško a écrit : > Sorry, repost to the mailing list. > > Marek > > ---------- Forwarded message ---------- > From: Marek Greško <mgresko8@gmail.com> > Date: Thu, 23 Sep 2021 20:05:33 +0200 > Subject: Re: nftables and connection tracking > To: Pablo Neira Ayuso <pablo@netfilter.org> > > Hello, > > no rule is blocking traffic. There is no match for rule so the udp > drops. If I add accept rule as a last rule of the INPUT chain, it > works. > > I tried conntrack -F without any progress. > The conntrack -L expect shows some local sip phone 5060 connections > and sip provider connection. No nat phones here. Even after reboot > when it is working after reboot there is nothing about natted phones, > > Yes debugging would be probably the best, could you tell me how to > debug it? I had never such firewall problems for 25 years history. I > did not try to revert to iptables yet. > > To be honest, I do not expect it to be a configuration problem, but > one never knows. > > Thanks > > Marek > > > 2021-09-21 3:59 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>: >> On Thu, Sep 16, 2021 at 10:32:01PM +0200, Marek Greško wrote: >>> Hello, >>> >>> I would like to make the revival of this thread. My current >>> configuration looks like this: >>> >>> table ip filter { >>> ct helper sip { >>> type "sip" protocol udp >>> l3proto ip >>> } >>> >>> chain PREROUTING { >>> type filter hook prerouting priority filter; policy accept; >>> udp port 5060 ct helper set "sip" >>> } >>> >>> chain INPUT { >>> ... >>> ct state invalid drop >>> ct state related accept >>> ct state established accept >>> ... >>> iifname "ppp0" jump i-inet >>> } >>> >>> chain OUTPUT { >>> type filter hook output priority filter; policy accept; >>> udp port 5060 ct helper set "sip" >>> ... >>> } >>> >>> chain i-inet { >>> ... >>> udp port 5060 jump r-sip >>> ... >>> } >>> >>> chain r-sip { >>> ip saddr 192.0.2.0/24 accept >>> } >>> } >>> >>> table ip mangle { >>> chain PREROUTING { >>> type filter hook prerouting priority mangle; policy accept; >>> ... >>> udp sport 5060 ip dscp set 0x04 >>> } >>> >>> chain OUTPUT { >>> type route hook output priority mangle; policy accept; >>> ... >>> udp dport 5060 ip dscp set 0x04 >>> ... >>> } >>> } >>> >>> table ip6 filter { >>> ct helper sip { >>> type "sip" protocol udp >>> l3proto ip6 >>> } >>> >>> ... pretty the same, but I have no ipv6 internet connectivity, so >>> this should not match ... >>> >>> } >>> >>> I run the nftables locally on the asterisk server. The phones located >>> on the local lan are working ok. But the remote phones behind nat are >>> experiencing intermittent problems. After several days of working >>> there is suddenly no audio. We with some guys on the asterisk list >>> have found out it is a nftables problem. But I am not sure whether it >>> is configuration problem or a bug. >>> >>> The problem is that when the rtp stream is built the stream incoming >>> to asterisk is blocked by nftables >> What rule is blocking the traffic? >> >>> and thus asterisk never learns the >>> public ip of the remote phone and is sending rtp stream to it's >>> internal address. So there is no audio in either direction. When I >>> enable rtp udp port range to pass to the asterisk it works. After >>> blocking again it stops working. To resolve the problem for several >>> days I found out that rebooting of the remote router resolves the >>> issue. >> Did you try 'conntrack -F' instead of rebooting to flush the conntrack >> table? What does 'conntrack -L expect' shows? >> >>> I have one successful resolving by rebooting the asterisk >>> server the problematic nftables is running on. The proble arises again >>> in several days. The problem is too frequent to be accepted, but too >>> rare to be debugged. I have not tried the trick with sysctl above, >>> yet. >>> >>> Do you think this could be a configuration problem? >> Even if it's a configuration problem, debugging the ruleset would be >> needed. >> -- Daniel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-21 5:54 nftables and connection tracking Marek Greško 2020-06-21 8:06 ` Florian Westphal @ 2020-06-22 12:06 ` Pablo Neira Ayuso 2020-06-22 17:18 ` Marek Greško 1 sibling, 1 reply; 14+ messages in thread From: Pablo Neira Ayuso @ 2020-06-22 12:06 UTC (permalink / raw) To: Marek Greško; +Cc: netfilter On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek GreÅ¡ko wrote: > Hello, > > I have problem to get connection tracking work when using nftables. I > have this setup on my fedora 32: > > table ip raw { > chain PREROUTING { > type filter hook prerouting priority raw; policy accept; Could you try from the filter (0) priority instead ? type filter hook prerouting priority filter; policy accept; Thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-22 12:06 ` Pablo Neira Ayuso @ 2020-06-22 17:18 ` Marek Greško 2020-06-22 21:35 ` Marek Greško 0 siblings, 1 reply; 14+ messages in thread From: Marek Greško @ 2020-06-22 17:18 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter Hello, after changing priority it is working. It was a configuration error or a bug? Marek 2020-06-22 14:06 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>: > On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek GreÅ¡ko wrote: >> Hello, >> >> I have problem to get connection tracking work when using nftables. I >> have this setup on my fedora 32: >> >> table ip raw { >> chain PREROUTING { >> type filter hook prerouting priority raw; policy accept; > > Could you try from the filter (0) priority instead ? > > type filter hook prerouting priority filter; policy > accept; > > Thanks. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: nftables and connection tracking 2020-06-22 17:18 ` Marek Greško @ 2020-06-22 21:35 ` Marek Greško 0 siblings, 0 replies; 14+ messages in thread From: Marek Greško @ 2020-06-22 21:35 UTC (permalink / raw) To: Pablo Neira Ayuso; +Cc: netfilter Hello Florian, I am just thinking about what I did now when I changed the priority to filter. For prerouting it is clear, since there is no other chain with hook prerouting. But for output there is another one in the table filter. Which one is proceeded first if they are the same priority? what is they have conflicting policy? If the first one is drop, the second chain will not proceed if not allowed in the first one? If these priorities should be filter would not it be making more sense to move the rules to the chains in the table filter? Marek 2020-06-22 19:18 GMT+02:00, Marek Greško <mgresko8@gmail.com>: > Hello, > > after changing priority it is working. It was a configuration error or a > bug? > > Marek > > > 2020-06-22 14:06 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>: >> On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek Greško wrote: >>> Hello, >>> >>> I have problem to get connection tracking work when using nftables. I >>> have this setup on my fedora 32: >>> >>> table ip raw { >>> chain PREROUTING { >>> type filter hook prerouting priority raw; policy accept; >> >> Could you try from the filter (0) priority instead ? >> >> type filter hook prerouting priority filter; policy >> accept; >> >> Thanks. >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-09-24 7:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-21 5:54 nftables and connection tracking Marek Greško 2020-06-21 8:06 ` Florian Westphal [not found] ` <CAChjPdQtKBGuUvdveCVc5kmhA+fgP4DUDNKhNd11KUVCKNUZLg@mail.gmail.com> [not found] ` <20200621090142.GL26990@breakpoint.cc> 2020-06-21 9:39 ` Marek Greško 2020-06-21 10:45 ` Florian Westphal 2020-06-21 11:33 ` Marek Greško 2020-07-01 20:01 ` Marek Greško 2020-07-01 22:48 ` Florian Westphal 2020-07-02 19:33 ` Marek Greško 2020-07-02 19:47 ` Pablo Neira Ayuso [not found] ` <CAChjPdQb5wUP7Qbz=D-0jg-YFC0cWgV4oPJQD9-G7evi3SupAw@mail.gmail.com> [not found] ` <YUk8dCSHCUcKn+Xy@salvia> [not found] ` <CAChjPdREO=jtTNGc32H3mv+Zv8AHKbujb_a8=tkwC0+b2sbVCQ@mail.gmail.com> 2021-09-24 5:21 ` Fwd: " Marek Greško 2021-09-24 7:19 ` Daniel 2020-06-22 12:06 ` Pablo Neira Ayuso 2020-06-22 17:18 ` Marek Greško 2020-06-22 21:35 ` Marek Greško
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.