On Wed, 8 May 2024 10:20:05 +0800, Jason Wang wrote:
> On Tue, May 7, 2024 at 2:56 PM Heng Qi wrote:
> >
> > On Tue, 7 May 2024 14:24:19 +0800, Jason Wang wrote:
> > > On Fri, Apr 26, 2024 at 2:54 PM Heng Qi wrote:
> > > >
> > > > From: Xuan Zhuo
> > > >
> > > > As the spec
> > > > https://gi
On Tue, May 7, 2024 at 2:56 PM Heng Qi wrote:
>
> On Tue, 7 May 2024 14:24:19 +0800, Jason Wang wrote:
> > On Fri, Apr 26, 2024 at 2:54 PM Heng Qi wrote:
> > >
> > > From: Xuan Zhuo
> > >
> > > As the spec
> > > https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0
On Tue, 7 May 2024 14:24:19 +0800, Jason Wang wrote:
> On Fri, Apr 26, 2024 at 2:54 PM Heng Qi wrote:
> >
> > From: Xuan Zhuo
> >
> > As the spec
> > https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0064f82
> >
> > Based on the description provided in the above s
On Fri, Apr 26, 2024 at 2:54 PM Heng Qi wrote:
>
> From: Xuan Zhuo
>
> As the spec
> https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0064f82
>
> Based on the description provided in the above specification, we have
> enabled the virtio-net driver to support acqui
From: Xuan Zhuo
As the spec
https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0064f82
Based on the description provided in the above specification, we have
enabled the virtio-net driver to support acquiring some response
information from the device via the CVQ (Co
As the spec
https://github.com/oasis-tcs/virtio-spec/commit/42f389989823039724f95bbbd243291ab0064f82
Based on the description provided in the above specification, we have
enabled the virtio-net driver to support acquiring some response
information from the device via the CVQ (Control Virtqueue).
On Tue, 2021-04-13 at 17:51 -0400, Willem de Bruijn wrote:
> On Mon, Apr 12, 2021 at 5:25 PM Andreas Roeseler
> wrote:
> >
> > The current icmp_rcv function drops all unknown ICMP types,
> > including
> > ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Ec
On Mon, Apr 12, 2021 at 5:25 PM Andreas Roeseler
wrote:
>
> The current icmp_rcv function drops all unknown ICMP types, including
> ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages,
> we have
> to pass these packets to the ping_rcv function, which
The current icmp_rcv function drops all unknown ICMP types, including
ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages,
we have
to pass these packets to the ping_rcv function, which does not do any
other filtering and passes the packet to the designated socket.
Pass
> > including
> > > ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply
> > > messages, we have
> > > to pass these packets to the ping_rcv function, which does not do
> > > any
> > > other filtering and passes the packet to the des
On Mon, 2021-04-12 at 15:28 -0400, Willem de Bruijn wrote:
> On Mon, Apr 12, 2021 at 3:09 PM Andreas Roeseler
> wrote:
> >
> > The current icmp_rcv function drops all unknown ICMP types,
> > including
> > ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Ec
On Mon, Apr 12, 2021 at 3:09 PM Andreas Roeseler
wrote:
>
> The current icmp_rcv function drops all unknown ICMP types, including
> ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages,
> we have
> to pass these packets to the ping_rcv function, which
The current icmp_rcv function drops all unknown ICMP types, including
ICMP_EXT_ECHOREPLY (type 43). In order to parse Extended Echo Reply messages,
we have
to pass these packets to the ping_rcv function, which does not do any
other filtering and passes the packet to the designated socket.
Pass
ends up being sent to userspace.
>
> Fix that by using designated initializer that will clear all
> non-specified fields.
>
> [...]
Here is the summary with links:
- [net] openvswitch: fix send of uninitialized stack memory in ct limit reply
https://git.kernel.org/netdev/n
itch/conntrack.c
> > +++ b/net/openvswitch/conntrack.c
> > @@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct
> > nlattr *nla_zone_limit,
> > static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> >
tr
> *nla_zone_limit,
> static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
> struct sk_buff *reply)
> {
> - struct ovs_zone_limit zone_limit;
> -
> - zone_limit.zone_id = OVS_ZONE_LIMIT_DEFAULT
285 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -2032,10 +2032,10 @@ static int ovs_ct_limit_del_zone_limit(struct nlattr
*nla_zone_limit,
static int ovs_ct_limit_get_default_limit(struct ovs_ct_limit_info *info,
struct sk_buff *repl
Hello:
This series was applied to netdev/net.git (refs/heads/master):
On Thu, 25 Mar 2021 16:35:31 +0100 you wrote:
> Hi,
>
> The series fixes an issue were a shared ip_tunnel_info is modified when
> PMTU triggers an ICMP reply in vxlan and geneve, making following
> packets
On Thu, 25 Mar 2021 16:35:31 +0100
Antoine Tenart wrote:
> Hi,
>
> The series fixes an issue were a shared ip_tunnel_info is modified when
> PMTU triggers an ICMP reply in vxlan and geneve, making following
> packets in that flow to have a wrong destination address if the flow
When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing
When the interface is part of a bridge or an Open vSwitch port and a
packet exceed a PMTU estimate, an ICMP reply is sent to the sender. When
using the external mode (collect metadata) the source and destination
addresses are reversed, so that Open vSwitch can match the packet
against an existing
Hi,
The series fixes an issue were a shared ip_tunnel_info is modified when
PMTU triggers an ICMP reply in vxlan and geneve, making following
packets in that flow to have a wrong destination address if the flow
isn't updated. A detailled information is given in each of the two
commits.
Thi
I am Mr. Martin Collins Bank manager still waiting for your reply to
my many unanswered emails to you about the transfer
On Tue, 23 Feb 2021 09:05:47 -0300 Marcelo Ricardo Leitner wrote:
> On Tue, Feb 23, 2021 at 03:11:55PM +0800, we...@ucloud.cn wrote:
> > From: wenxu
> >
> > Add invalid and reply flags validate in the fl_validate_ct_state.
> > This makes the checking
On Tue, Feb 23, 2021 at 03:11:55PM +0800, we...@ucloud.cn wrote:
> From: wenxu
>
> Add invalid and reply flags validate in the fl_validate_ct_state.
> This makes the checking complete if compared to ovs'
> validate_ct_state().
>
> Signed-off-by: wenxu
Reviewed-by: Marcelo Ricardo Leitner
From: wenxu
Add invalid and reply flags validate in the fl_validate_ct_state.
This makes the checking complete if compared to ovs'
validate_ct_state().
Signed-off-by: wenxu
---
net/sched/cls_flower.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/net/sched/cls_flowe
On Mon, Feb 22, 2021 at 02:09:50PM +0800, we...@ucloud.cn wrote:
> From: wenxu
>
> Add invalid and reply flags validate in the fl_validate_ct_state.
This makes the checking complete if compared to ovs'
validate_ct_state().
...
> + if (state & TCA_FLOWER
--
Hello,
This is attorney Adrien Saif, the legal practitioner to Qatif Oil And Gas Group
of Companies.
Did you receive the proposal we sent to you via email days ago?
Best Regards,
Adrien Saif
From: wenxu
Add invalid and reply flags validate in the fl_validate_ct_state.
Signed-off-by: wenxu
---
net/sched/cls_flower.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 2409e52..18430db 100644
--- a/net/sched
This is a new async message that the firmware can send to check if it
can communicate with the driver. This is an added error detection
scheme that firmware can use if it suspects errors in the PCIe
interface. When the driver receives this async message, it will reply
back echoing some data in
On 2/2/21 5:24 AM, Paul Blakey wrote:
> Matches on conntrack rpl ct_state.
>
> Example:
> $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \
> ct_state +trk+est+rpl \
> action mirred egress redirect dev ens1f0_1
> $ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip
On Tue, 2 Feb 2021, Marcelo Ricardo Leitner wrote:
> On Wed, Jan 27, 2021 at 04:32:47PM +0200, Paul Blakey wrote:
> > Add support for matching on ct_state reply flag.
>
> Sorry for the late reply, missed the patchset here. (just noticed
> because of the iproute2 patch, th
On Tue, 2 Feb 2021, Marcelo Ricardo Leitner wrote:
> On Tue, Feb 02, 2021 at 02:24:42PM +0200, Paul Blakey wrote:
> > Matches on conntrack rpl ct_state.
> >
> > Example:
> > $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \
> > ct_state +trk+est+rpl \
> > action mirred
On Tue, Feb 02, 2021 at 02:24:42PM +0200, Paul Blakey wrote:
> Matches on conntrack rpl ct_state.
>
> Example:
> $ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \
> ct_state +trk+est+rpl \
> action mirred egress redirect dev ens1f0_1
> $ tc filter add dev ens1f0_1 ingress p
On Wed, Jan 27, 2021 at 04:32:47PM +0200, Paul Blakey wrote:
> Add support for matching on ct_state reply flag.
Sorry for the late reply, missed the patchset here. (just noticed
because of the iproute2 patch, thanks for the Cc in there)
Only one question though. Is it safe to assume that t
@@ -387,6 +387,8 @@ new - New connection.
.TP
est - Established connection.
.TP
+rpl - The packet is in the reply direction, meaning that it is in the opposite
direction from the packet that initiated the connection.
+.TP
inv - The state is invalid. The packet couldn't be associated to a conne
On Sat, Jan 30, 2021 at 05:24:52PM +0530, Aviraj CJ wrote:
> From: Hangbin Liu
>
> commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.
>
> Based on RFC 8200, Section 4.5 Fragment Header:
>
> - If the first fragment does not include all headers through an
> Upper-Layer header, then
From: Hangbin Liu
commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Wed, 27 Jan 2021 16:32:44 +0200 you wrote:
> This patchset adds software match support and offload of flower
> match ct_state reply flag (+/-rpl).
>
> The first patch adds the definition for the flag
From: Hangbin Liu
commit 2efdaaaf883a143061296467913c01aa1ff4b3ce upstream.
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code
Add match on the ct_state reply flag.
Example:
$ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \
ct_state +trk+est+rpl \
action mirred egress redirect dev ens1f0_1
$ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \
ct_state +trk+est-rpl \
action
Add support for matching on ct_state reply flag.
Example:
$ tc filter add dev ens1f0_0 ingress prio 1 chain 1 proto ip flower \
ct_state +trk+est+rpl \
action mirred egress redirect dev ens1f0_1
$ tc filter add dev ens1f0_1 ingress prio 1 chain 1 proto ip flower \
ct_state +trk+est-rpl
This patchset adds software match support and offload of flower
match ct_state reply flag (+/-rpl).
The first patch adds the definition for the flag and match to flower.
Second patch gives the direction of the connection to the offloading drivers via
ct_metadata flow offload action.
The last
I'm Dailborh R. from US. I picked interest in you and I would like to know
more about you and establish relationship with you. i will wait for
your response. thank you.
From: Guvenc Gulce
Refactor the netlink reply processing routine so that
it provides sub functions for specific parts of the processing.
Signed-off-by: Guvenc Gulce
Signed-off-by: Karsten Graul
---
net/smc/smc_diag.c | 218 +++--
1 file changed, 133
From: Guvenc Gulce
Refactor the netlink reply processing routine so that
it provides sub functions for specific parts of the processing.
Signed-off-by: Guvenc Gulce
Signed-off-by: Karsten Graul
---
net/smc/smc_diag.c | 218 +++--
1 file changed, 133
From: Guvenc Gulce
Refactor the netlink reply processing routine so that
it provides sub functions for specific parts of the processing.
Signed-off-by: Guvenc Gulce
Signed-off-by: Karsten Graul
---
net/smc/smc_diag.c | 218 +++--
1 file changed, 133
From: Guvenc Gulce
Refactor the netlink reply processing routine so that
it provides sub functions for specific parts of the processing.
Signed-off-by: Guvenc Gulce
Signed-off-by: Karsten Graul
---
net/smc/smc_diag.c | 218 +++--
1 file changed, 133
On Tue, 27 Oct 2020 20:33:11 +0800 Hangbin Liu wrote:
> When our Engineer run latest IPv6 Core Conformance test, test v6LC.1.3.6:
> First Fragment Doesn’t Contain All Headers[1] failed. The test purpose is to
> verify that the node(Linux for example) should properly process IPv6 packets
> that don’
On 30.10.2020 16:31, Willem de Bruijn wrote:
> On Tue, Oct 27, 2020 at 5:57 AM Hangbin Liu wrote:
>> On Tue, Oct 27, 2020 at 07:57:06AM +, Georg Kohmann (geokohma) wrote:
+ /* RFC 8200, Section 4.5 Fragment Header:
+* If the first fragment does not include all headers through a
On Tue, Oct 27, 2020 at 5:57 AM Hangbin Liu wrote:
>
> On Tue, Oct 27, 2020 at 07:57:06AM +, Georg Kohmann (geokohma) wrote:
> > > + /* RFC 8200, Section 4.5 Fragment Header:
> > > +* If the first fragment does not include all headers through an
> > > +* Upper-Layer header, then that
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 8 +++-
net/ipv6/reassembly.c | 33 -
3 files changed, 40 insertions(+), 2 deletions(-)
--
2.25.4
s (both 0) that might
>> change in the future.
> Thanks, I also didn't aware this scenario.
>
>> I suggest you only check that the offset is 0:
>> frag_off & htons(IP6_OFFSET)
> This will match all other fragment packets. RFC request we reply ICMP for the
> first fragment packet, Do you mean
>
> if (!frag_off & htons(IP6_OFFSET) && offset > skb->len)
Almost, add some parentheses:
if (!(frag_off & htons(IP6_OFFSET)) && offset > skb->len)
>
> Thanks
> Hangbin
off == htons(ip6_mf) && offset > skb->len) {
>
> This do not catch atomic fragments (fragmented packet with only one
> fragment). frag_off also contains two reserved bits (both 0) that might
> change in the future.
Thanks, I also didn't aware this scenario.
> I sugge
On 27.10.2020 03:28, Hangbin Liu wrote:
> Based on RFC 8200, Section 4.5 Fragment Header:
>
> - If the first fragment does not include all headers through an
> Upper-Layer header, then that fragment should be discarded and
> an ICMP Parameter Problem, Code 3, message should be sent to
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 8 +++-
net/ipv6/reassembly.c | 33 -
3 files changed, 40 insertions(+), 2 deletions(-)
--
2.25.4
fines the same with NEXTHDR_NONE. So ipv6_skip_exthdr() will
> return -1, and we will goto fail_hdr and send ICMP parameter error message.
>
> The question is if it's OK to reply a ICMP error for fragment + IPPROTO_NONE
> packet? For pure IPPROTO_NONE message, we should drop si
(nexthdr == IPPROTO_ICMPV6)
> > + offset += sizeof(struct icmp6hdr);
> > + else
> > + offset += 1;
>
> Maybe also check the special case IPPROTO_NONE?
IPPROTO_NONE defines the same with NEXTHDR_NONE. So ipv6_skip_exthdr() will
return -1, and we will
On 26.10.2020 08:29, Hangbin Liu wrote:
> Based on RFC 8200, Section 4.5 Fragment Header:
>
> - If the first fragment does not include all headers through an
> Upper-Layer header, then that fragment should be discarded and
> an ICMP Parameter Problem, Code 3, message should be sent to
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 8 +++-
net/ipv6/reassembly.c | 33 -
3 files changed, 40 insertions(+), 2 deletions(-)
--
2.25.4
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
On Fri, 23 Oct 2020 14:43:47 +0800 Hangbin Liu wrote:
> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
> index ec448b71bf9a..0bda77d7e6b8 100644
> --- a/net/ipv6/icmp.c
> +++ b/net/ipv6/icmp.c
> @@ -145,6 +145,7 @@ static bool is_ineligible(const struct sk_buff *skb)
> int ptr = (u8 *)(ipv6_h
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 10 +-
net/ipv6/reassembly.c | 33 -
3 files changed, 42 insertions(+), 2 deletions(-)
--
2.25.4
On Thu, Oct 22, 2020 at 5:12 AM Hangbin Liu wrote:
>
> Hi Willem,
>
> Thanks for the comments, see replies below.
>
> On Wed, Oct 21, 2020 at 10:02:55AM -0400, Willem de Bruijn wrote:
> > > + is_frag = (ipv6_find_hdr(skb, &offs, NEXTHDR_FRAGMENT, NULL,
> > > NULL) == NEXTHDR_FRAGMENT);
> >
Hi Willem,
Thanks for the comments, see replies below.
On Wed, Oct 21, 2020 at 10:02:55AM -0400, Willem de Bruijn wrote:
> > + is_frag = (ipv6_find_hdr(skb, &offs, NEXTHDR_FRAGMENT, NULL, NULL)
> > == NEXTHDR_FRAGMENT);
> > +
>
> ipv6_skip_exthdr already walks all headers. Should we not a
On Wed, Oct 21, 2020 at 12:20 AM Hangbin Liu wrote:
>
> Based on RFC 8200, Section 4.5 Fragment Header:
>
> - If the first fragment does not include all headers through an
> Upper-Layer header, then that fragment should be discarded and
> an ICMP Parameter Problem, Code 3, message sho
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 13 -
net/ipv6/reassembly.c | 18 +-
3 files changed, 30 insertions(+), 2 deletions(-)
--
2.25.4
From: "longguang.yue"
Just like for MASQ, inspect the reply packets coming from DR/TUN
real servers and alter the connection's state and timeout
according to the protocol.
It's ipvs's duty to do traffic statistic if packets get hit,
no matter what mode it is.
Sig
On Thu, Oct 08, 2020 at 11:47:00AM +0200, Eric Dumazet wrote:
>
>
> On 10/8/20 10:30 AM, Hangbin Liu wrote:
> >>> @@ -282,6 +285,21 @@ static struct sk_buff *ip6_rcv_core(struct sk_buff
> >>> *skb, struct net_device *dev,
> >>> }
> >>> }
> >>>
> >>> + /* RFC 8200, Section 4.5 Fragm
On 10/8/20 10:30 AM, Hangbin Liu wrote:
> Hi Eric,
>
> Thanks for the comments. I should add "RFC" in subject next time for the
> uncertain fix patch.
>
> On Wed, Oct 07, 2020 at 11:35:41AM +0200, Eric Dumazet wrote:
>>
>>
>> On 10/7/20 5:55 AM, Hangbin Liu wrote:
>>
>>> kfree_skb(
On Wed, Oct 07, 2020 at 07:58:07AM -0700, Jakub Kicinski wrote:
> On Wed, 7 Oct 2020 11:55:02 +0800 Hangbin Liu wrote:
> > Based on RFC 8200, Section 4.5 Fragment Header:
> >
> > - If the first fragment does not include all headers through an
> > Upper-Layer header, then that fragment sho
Hi Eric,
Thanks for the comments. I should add "RFC" in subject next time for the
uncertain fix patch.
On Wed, Oct 07, 2020 at 11:35:41AM +0200, Eric Dumazet wrote:
>
>
> On 10/7/20 5:55 AM, Hangbin Liu wrote:
>
> > kfree_skb(skb);
> > @@ -282,6 +285,21 @@ static struct sk_buff *ip
On Wed, 7 Oct 2020 11:55:02 +0800 Hangbin Liu wrote:
> Based on RFC 8200, Section 4.5 Fragment Header:
>
> - If the first fragment does not include all headers through an
> Upper-Layer header, then that fragment should be discarded and
> an ICMP Parameter Problem, Code 3, message sho
On 10/7/20 5:55 AM, Hangbin Liu wrote:
> kfree_skb(skb);
> @@ -282,6 +285,21 @@ static struct sk_buff *ip6_rcv_core(struct sk_buff *skb,
> struct net_device *dev,
> }
> }
>
> + /* RFC 8200, Section 4.5 Fragment Header:
> + * If the first fragment do
Based on RFC 8200, Section 4.5 Fragment Header:
- If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and
an ICMP Parameter Problem, Code 3, message should be sent to
the source of the fragment, with the Pointer
definition
IPv6: reply ICMP error if the first fragment don't include all headers
include/uapi/linux/icmpv6.h | 1 +
net/ipv6/icmp.c | 13 -
net/ipv6/ip6_input.c| 20 +++-
3 files changed, 32 insertions(+), 2 deletions(-)
--
2.25.4
My Greetings,
I am a banker, the Chief Auditor in our bank. I have the ability to
transfer unclaimed funds that belong to one of our late customer who
died in a car crash along with his family and no one came to claim the
funds, if left unclaimed the fund will be transferred to the state
treasury i
tunnel info request reached mainline in 5.9 merge window, we should
> still be able to fix the reply message type without breaking backward
> compatibility.
>
> Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface")
> Signed-off-by: Michal Kubecek
Applied, thank you.
> On the other hand, the enums are part of userspace API so I better take
> a closer look to make sure we don't run into some trouble there.
Hi Michal
Yes, that is what i was thinking about. But i guess you can pass a
tagged enum to a function expecting an int and the compiler will
silently cast
On Thu, Sep 17, 2020 at 03:41:51AM +0200, Andrew Lunn wrote:
> On Thu, Sep 17, 2020 at 01:04:10AM +0200, Michal Kubecek wrote:
> > Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd
> > field in genetlink header) for replies to tunnel info netlink request, i.e.
> > the same
On Thu, Sep 17, 2020 at 01:04:10AM +0200, Michal Kubecek wrote:
> Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd
> field in genetlink header) for replies to tunnel info netlink request, i.e.
> the same value as the request have. This is a problem because we are using
>
request reached mainline in 5.9 merge window, we should
> still be able to fix the reply message type without breaking backward
> compatibility.
>
> Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface")
> Signed-off-by: Michal Kubecek
Ouch, sorry & thanks!
Reviewed-by: Jakub Kicinski
message
types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with
ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for
kernel to userspace messages.
As the tunnel info request reached mainline in 5.9 merge window, we should
still be able to fix the reply message type without
NAT_CLASH tuple.
In that case the second skb will be sent, but no reply can be received
since the reply that is processed first removes the NAT_CLASH tuple.
Do not auto-delete, this gives a 1 second window for replies to be passed
back to originator.
Packets that are coming later (udp stream case
My Greetings,
I am a banker, a Chief Auditor in our bank, I have the ability to
transfer unclaimed funds that belong to one of our late customer died
in a car crash along with his family and no one came to put claim the
funds, if left unclaimed the fund will be transferred to the state
treasury in
On Mon, Aug 17, 2020 at 04:34:07PM +0300, Maxim Mikityanskiy wrote:
> The legacy ethtool userspace tool shows an error when no features could
> be changed. It's useful to have a netlink reply to be able to show this
> error when __netdev_update_features wasn't called, for examp
The legacy ethtool userspace tool shows an error when no features could
be changed. It's useful to have a netlink reply to be able to show this
error when __netdev_update_features wasn't called, for example:
1. ethtool -k eth0
large-receive-offload: off
2. ethtool -K eth0 rx-fcs on
The legacy ethtool userspace tool shows an error when no features could
be changed. It's useful to have a netlink reply to be able to show this
error when __netdev_update_features wasn't called, for example:
1. ethtool -k eth0
large-receive-offload: off
2. ethtool -K eth0 rx-fcs on
I am reverting my last patch because of the malformatted subject.
Thanks,
Izabela
On Tue, Aug 4, 2020 at 5:48 PM wrote:
>
> From: Izabela Bakollari
>
> Dropwatch is a utility that monitors dropped frames by having userspace
> record them over the dropwatch protocol over a file. This augument
>
From: Izabela Bakollari
Dropwatch is a utility that monitors dropped frames by having userspace
record them over the dropwatch protocol over a file. This augument
allows live monitoring of dropped frames using tools like tcpdump.
With this feature, dropwatch allows two additional commands (start
Good-Day Friend,
Hope you are doing great Today. I have a proposed business deal worthy
(US$16.5 Million Dollars) that will benefit both parties. This is legitimate'
legal and your personality will not be compromised.
Waiting for your response for more details, As you are willing to execute
From: Michal Kubecek
[ Upstream commit 7c87e32d2e380228ada79d20ac5b7674718ef097 ]
As ethnl_request_ops::reply_size handlers do not include common header
size into calculated/estimated reply size, it needs to be added in
ethnl_default_doit() and ethnl_default_notify() before allocating the
From: Michal Kubecek
Date: Sun, 10 May 2020 21:04:09 +0200
> As ethnl_request_ops::reply_size handlers do not include common header
> size into calculated/estimated reply size, it needs to be added in
> ethnl_default_doit() and ethnl_default_notify() before allocating the
> message.
As ethnl_request_ops::reply_size handlers do not include common header
size into calculated/estimated reply size, it needs to be added in
ethnl_default_doit() and ethnl_default_notify() before allocating the
message. On the other hand, strset_reply_size() should not add common
header size.
Fixes
Dear Friend,
I want you to be honest and truthful with me that you will help me with all
your effort and time for just seven to fourteen workings of your time
Please kindly reply to my most confidential email if you are really interested
in helping me please: saeedasutanah...@gmail.com
Hello
My name is Yuval Rose. I have an urgent lucrative business
opportunity for you worth over 15 Milli0n US D0llars. I got your
details on the internet when I was searching for a reliable
person that can handle this deal and I believe you can handle it.
Waiting for your speedy reply for
1 - 100 of 240 matches
Mail list logo
