Hello, this is the second times am sending you this mail and you refused to reply to my email why?

Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

On Sat, 2018-09-29 at 11:44 -0700, David Miller wrote: > From: Yifeng Sun > Date: Wed, 26 Sep 2018 11:40:14 -0700 > > > This patch fixes the bug that all datapath and vport ops are returning > > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies. > > > > Signed-off-by: Yifeng

Please Reply / Can i have a bit of your attention?

reply.. Hope to hear back from you kisses & hugs Bauer

Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

From: Yifeng Sun Date: Wed, 26 Sep 2018 11:40:14 -0700 > This patch fixes the bug that all datapath and vport ops are returning > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies. > > Signed-off-by: Yifeng Sun Applied.

Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

On Wed, Sep 26, 2018 at 11:40 AM Yifeng Sun wrote: > > This patch fixes the bug that all datapath and vport ops are returning > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies. > > Signed-off-by: Yifeng Sun I am surprised this was not found earlier. Acked-by: Pravin B Shelar

[PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

) ovs_header->dp_ifindex, reply, info->snd_portid, info->snd_seq, 0, - OVS_FLO

KINDLY REPLY diplmos...@gmail.com URGENTLY

KINDLY REPLY diplmos...@gmail.com URGENTLY

KINDLY REPLY diplmos...@gmail.com URGENTLY

KINDLY REPLY diplmos...@gmail.com URGENTLY

KINDLY REPLY stemlightresour...@gmail.com URGENTLY

KINDLY REPLY stemlightresour...@gmail.com URGENTLY

KINDLY REPLY stemlightresour...@gmail.com URGENTLY

KINDLY REPLY stemlightresour...@gmail.com URGENTLY

IMMEDIATE REPLY.

DEAR FRIEND, I know that this letter will come to you as surprise, I got your contact address while I was searching for foreign partner to champion this golden appoint unity that is present in our favor, My name is Mr. Isa Zongo, I am the Bill and Exchange (assistant) Manager CORIS BANK

REPLY URGENLY.

.Occupation:.. 7.Age:. 8.sex I shall send you more details as soon as i hear from you. Regards, My Regards, Mr. john Matthias ouedraogo REPLY URGENTLY.

Reply

Are you free for discussion?

Re: VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6 Global and Dest is IPV6 Link Local.

On 4/30/18 6:58 AM, Sukumar Gopalakrishnan wrote: > VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6 > Global and Dest is IPV6 Link Local. ... > if (fl6->flowi6_oif == dev->ifindex) { try adding ' && !rt6_need_strict(saddr)' to the above. If it wor

VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6 Global and Dest is IPV6 Link Local.

VRF: ICMPV6 Echo Reply failed to egress if ingress pkt Src is IPV6 Global and Dest is IPV6 Link Local. KERNEL VERSION: 4.14.28 BUG REPORT: https://bugzilla.kernel.org/show_bug.cgi?id=199573 CONFIGURATION AND PACKET FLOW: == 1) Created

Reply

Dear Shaohui, I plead an indulgence if I have invaded your privacy by receiving this mail from me without prior permission.With due respect,I contact you purposely based on the similarities of names between you and my deceased client who was an oil servicing contractor with shell petroleum in West

[PATCH 2/2] can: cc770: Fix queue stall & dropped RTR reply

From: Andri Yngvason While waiting for the TX object to send an RTR, an external message with a matching id can overwrite the TX data. In this case we must call the rx routine and then try transmitting the message that was overwritten again. The queue was being stalled

[PATCH net 2/3] net/smc: use link_id of server in confirm link reply

From: Karsten Graul <kgr...@linux.vnet.ibm.com> The CONFIRM LINK reply message must contain the link_id sent by the server. And set the link_id explicitly when initializing the link. Signed-off-by: Karsten Graul <kgr...@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ubr...@lin

[PATCH net-next 5/5] net/smc: use server link_id in confirm link reply

From: Karsten Graul <kgr...@linux.vnet.ibm.com> The CONFIRM LINK reply message must contain the link_id sent by the server. And set the link_id explicitly when initializing the link. Signed-off-by: Karsten Graul <kgr...@linux.vnet.ibm.com> Signed-off-by: Ursula Braun <ubr...@lin

Re: [V9fs-developer] [PATCH] 9p/trans_virtio: discard zero-length reply

-- > Greg > > On Mon, 22 Jan 2018 22:02:05 +0100 > Greg Kurz <gr...@kaod.org> wrote: > > > When a 9p request is successfully flushed, the server is expected to just > > mark it as used without sending a 9p reply (ie, without writing data into > > the buffer). I

Re: [V9fs-developer] [PATCH] 9p/trans_virtio: discard zero-length reply

y flushed, the server is expected to just > mark it as used without sending a 9p reply (ie, without writing data into > the buffer). In this case, virtqueue_get_buf() will return len == 0 and > we must not report a REQ_STATUS_RCVD status to the client, otherwise the > client will erroneously a

[PATCH bpf-next v10 01/12] bpf: Only reply field should be writeable

Currently, a sock_ops BPF program can write the op field and all the reply fields (reply and replylong). This is a bug. The op field should not have been writeable and there is currently no way to use replylong field for indices >= 1. This patch enforces that only the reply field (which equ

[PATCH bpf-next v9 01/12] bpf: Only reply field should be writeable

Currently, a sock_ops BPF program can write the op field and all the reply fields (reply and replylong). This is a bug. The op field should not have been writeable and there is currently no way to use replylong field for indices >= 1. This patch enforces that only the reply field (which equ

Re: [PATCH bpf-next v8 04/12] bpf: Only reply field should be writeable

On 1/24/18 11:58 AM, Yuchung Cheng wrote: On Tue, Jan 23, 2018 at 11:57 PM, Lawrence Brakmo <bra...@fb.com> wrote: Currently, a sock_ops BPF program can write the op field and all the reply fields (reply and replylong). This is a bug. The op field should not have been wri

Re: [PATCH bpf-next v8 04/12] bpf: Only reply field should be writeable

On Tue, Jan 23, 2018 at 11:57 PM, Lawrence Brakmo <bra...@fb.com> wrote: > Currently, a sock_ops BPF program can write the op field and all the > reply fields (reply and replylong). This is a bug. The op field should > not have been writeable and there is currently no way to use re

[PATCH bpf-next v8 04/12] bpf: Only reply field should be writeable

Currently, a sock_ops BPF program can write the op field and all the reply fields (reply and replylong). This is a bug. The op field should not have been writeable and there is currently no way to use replylong field for indices >= 1. This patch enforces that only the reply field (which equ

[PATCH bpf-next v7 04/12] bpf: Only reply field should be writeable

Currently, a sock_ops BPF program can write the op field and all the reply fields (reply and replylong). This is a bug. The op field should not have been writeable and there is currently no way to use replylong field for indices >= 1. This patch enforces that only the reply field (which equ

[PATCH] 9p/trans_virtio: discard zero-length reply

When a 9p request is successfully flushed, the server is expected to just mark it as used without sending a 9p reply (ie, without writing data into the buffer). In this case, virtqueue_get_buf() will return len == 0 and we must not report a REQ_STATUS_RCVD status to the client, otherwise

[PATCH net-next 0/6] bpf: Fix bugs in sock_ops samples In-Reply-To:

The programs were returning -1 in some cases when they should only return 0 or 1. Changes in the verifier now catch this issue and the programs fail to load. This is now fixed. [PATCH net-next 1/6] bpf: Fix tcp_synrto_kern.c sample program [PATCH net-next 2/6] bpf: Fix tcp_rwnd_kern.c sample

Re: Grant -> Reply To fmayrhoferfam...@gmail.com

-- Good Day, My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims to our private email on: fmayrhoferfam...@gmail.com . We await your earliest response and God Bless you.

Reply

Are you free for discussion?

[net-next 10/12] igbvf: after mailbox write, wait for reply

From: Greg Edwards <gedwa...@ddn.com> Two of the VF mailbox commands were not waiting for a reply from the PF, which can result in a VF mailbox timeout in the VM for the next command. Signed-off-by: Greg Edwards <gedwa...@ddn.com> Tested-by: Aaron Brown <aaron.f.br...@intel.

Re: Reply Urgent

Hello, How are you doing? I have been sent to inform you that, We have an inheritance of a deceased client with your surname. Contact Mr Andrew Bailey Reply Email To: myinf...@gmail.com with your "Full Names" for more info. Thanks for your understanding. Reply ASAP thank you

[PATCH 1/2] batman-adv: Fix rx packet/bytes stats on local ARP reply

From: Sven Eckelmann The stats are generated by batadv_interface_stats and must not be stored directly in the net_device stats member variable. The batadv_priv bat_counters information is assembled when ndo_get_stats is called. The stats previously stored in net_device::stats

Reply for more details

account, meanwhile here are the needed information from you for the facilitation of the funds. 1.Your First Name 2.Your Last Name 3.Your Telephone number 4.Your Age 5.Your Country 6.Your occupation 7.Your Email Address Am waiting for your urgent reply so that we will starts immediately, Sorry if you

I NEED YOUR REPLY,

are the right person which i can work with.I will tell you more about me when i get a reply from you.   I am awaiting to hear from you yours Princess Joy J.Zengo Call me +229 64 89 03 05

Re: openvswitch conntrack and nat problem in first packet reply with RST

actions=ct(commit,zone=1,nat(dst=10.0.0.7)),output:1' >> 5. # ovs-ofctl add-flow br0 'table=1, ct_state=+est+trk,ip,in_port=1 >> actions=ct(commit,zone=1,nat(src=2.2.1.7)),output:2' >> >> >> I found that netns1 can access 1.1.1.7:123 when there is 123-port listen >

Re: openvswitch conntrack and nat problem in first packet reply with RST

ctions=ct(commit,zone=1,nat(src=2.2.1.7)),output:2' > > > I found that netns1 can access 1.1.1.7:123 when there is 123-port listen > on 1.1.1.7 in netns2 > > But if there is no listen 123 port, The first RST packet reply by 1.1.1.7 > (no datapath kernel rule) can't do dst-nat back

openvswitch conntrack and nat problem in first packet reply with RST

But if there is no listen 123 port, The first RST packet reply by 1.1.1.7 (no datapath kernel rule) can't do dst-nat back to 10.0.0.7. The second RST packet is ok (there is datapath kernel rule which comes from first RST packet) # tcpdump -i eth0 -nnn tcpdump: verbose output suppressed, use -v or -vv for full

Awaiting your urgent reply.

information's bellow to enable us commence immediately: Awaiting your urgent reply. (1) Full names. (2) Private phone number (3) Current residential address (4) Occupation . (5) Age and Sex

I NEED YOUR URGENT REPLY

Dear Friend, I am contacting you on a business deal of $9,500,000.00 Million United States Dollars, ready for transfer into your own personal account and if we make this claim, we will share it on the ratio of 50% / 50% basis. I would like to assure you that it be 100% risk free and it will be

[PATCH RESEND net-next 02/12] s390/qeth: test RX/TX checksum offload reply

From: Thomas Richter <tmri...@linux.vnet.ibm.com> Turning on receive and/or transmit checksum offload support on the OSA card requires 2 commands: 1. start command which replies with available features 2. enable command to turn on selected features. The current version does not check the

[PATCH net-next 02/13] s390/qeth: test RX/TX checksum offload reply

From: Thomas Richter <tmri...@linux.vnet.ibm.com> Turning on receive and/or transmit checksum offload support on the OSA card requires 2 commands: 1. start command which replies with available features 2. enable command to turn on selected features. The current version does not check the

Re: [net-next PATCH 0/3] net: optimize ICMP-reply code path

From: Jesper Dangaard Brouer <bro...@redhat.com> Date: Mon, 09 Jan 2017 16:03:59 +0100 > This patchset is optimizing the ICMP-reply code path, for ICMP packets > that gets rate limited. A remote party can easily trigger this code > path by sending packets to port number with no li

Re: [net-next PATCH 0/3] net: optimize ICMP-reply code path

On Mon, 2017-01-09 at 09:43 -0800, Cong Wang wrote: > On Mon, Jan 9, 2017 at 7:03 AM, Jesper Dangaard Brouer > wrote: > > > > Use-case: The specific case I experienced this being a bottleneck is, > > sending UDP packets to a port with no listener, which obviously result > > in

Re: [net-next PATCH 0/3] net: optimize ICMP-reply code path

On Mon, Jan 9, 2017 at 7:03 AM, Jesper Dangaard Brouer wrote: > > Use-case: The specific case I experienced this being a bottleneck is, > sending UDP packets to a port with no listener, which obviously result > in kernel replying with ICMP Destination Unreachable (type:3), Port

[net-next PATCH 0/3] net: optimize ICMP-reply code path

This patchset is optimizing the ICMP-reply code path, for ICMP packets that gets rate limited. A remote party can easily trigger this code path by sending packets to port number with no listening service. Generally the patchset moves the sysctl_icmp_msgs_per_sec ratelimit checking to earlier

[PATCH 04/17] batman-adv: Add wrapper for ARP reply creation

ed-arp-table.c @@ -949,6 +949,41 @@ static unsigned short batadv_dat_get_vid(struct sk_buff *skb, int *hdr_size) } /** + * batadv_dat_arp_create_reply - create an ARP Reply + * @bat_priv: the bat priv with all the soft interface information + * @ip_src: ARP sender IP + * @ip_dst: ARP target

[PATCH 04/17] batman-adv: Add wrapper for ARP reply creation

ed-arp-table.c @@ -949,6 +949,41 @@ static unsigned short batadv_dat_get_vid(struct sk_buff *skb, int *hdr_size) } /** + * batadv_dat_arp_create_reply - create an ARP Reply + * @bat_priv: the bat priv with all the soft interface information + * @ip_src: ARP sender IP + * @ip_dst: ARP target

[PATCH net-next iproute2 1/2 v2] libnetlink: Add test for error code returned from netlink reply

In case if some diag module is not present in the system, say the kernel is not modern enough, we simply skip the error code reported. Instead we should check for data length in NLMSG_DONE and process unsupported case. Signed-off-by: Cyrill Gorcunov --- lib/libnetlink.c | 16

Re: [RFC net-next iproute2 1/2] libnetlink: Add test for error code returned from netlink reply

On Thu, Oct 27, 2016 at 09:52:53AM +0300, Cyrill Gorcunov wrote: ... > > > > This looks like a mistake in how you implemented the functionality in the > > kernel. > > Despite what it looks like, all netlink request/reply functionality reports > > errors in curre

Re: [RFC net-next iproute2 1/2] libnetlink: Add test for error code returned from netlink reply

egative length > > +* as error code. > > +*/ > > + if (h->nlmsg_len < > > NLMSG_LENGTH(sizeof(int))) { > > + fprin

Re: [RFC net-next iproute2 1/2] libnetlink: Add test for error code returned from netlink reply

* as error code. > + */ > + if (h->nlmsg_len < > NLMSG_LENGTH(sizeof(int))) { > + fprintf(stderr, "Truncated > length reply\

[RFC net-next iproute2 1/2] libnetlink: Add test for error code returned from netlink reply

NGTH(sizeof(int))) { + fprintf(stderr, "Truncated length reply\n"); + return -1; + } + len = *(int *)NLMSG_DATA(h); +

[PATCH net 04/13] rxrpc: Only ping for lost reply in client call

When a reply is deemed lost, we send a ping to find out the other end received all the request data packets we sent. This should be limited to client calls and we shouldn't do this on service calls. Signed-off-by: David Howells <dhowe...@redhat.com> --- net/rxrpc/input.c |3 ++-

[PATCH net-next 3/8] rxrpc: Include the last reply DATA serial number in the final ACK

In a client call, include the serial number of the last DATA packet of the reply in the final ACK. Signed-off-by: David Howells <dhowe...@redhat.com> --- net/rxrpc/recvmsg.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/rec

[PATCH net-next 7/8] rxrpc: Schedule an ACK if the reply to a client call appears overdue

If we've sent all the request data in a client call but haven't seen any sign of the reply data yet, schedule an ACK to be sent to the server to find out if the reply data got lost. If the server hasn't yet hard-ACK'd the request data, we send a PING ACK to demand a response to find out whether

[PATCH net-next 4/8] rxrpc: Reinitialise the call ACK and timer state for client reply phase

Clear the ACK reason, ACK timer and resend timer when entering the client reply phase when the first DATA packet is received. New ACKs will be proposed once the data is queued. The resend timer is no longer relevant and we need to cancel ACKs scheduled to probe for a lost reply. Signed-off

[PATCH net-next 6/6] qed: PF to reply to unknown messages

If a future VF would send the PF an unknown message, the PF today would not send a reply. This would have 2 bad effects: a. VF would have to timeout on the request. b. If VF were to send an additional message to PF, firmware would mark it as malicious. Instead, if there's some valid

[PATCH net-next 7/8] cxgb4: Don't assume FW_PORT_CMD reply is always port info msg

The firmware can send a set of asynchronous replies through FW_PORT_CMD with DCBX information when that's negotiated with the Link Peer. The old code always assumed that a FW_PORT_CMD reply was always a Get Port Information message. This change conditionalizes the code to only handle the Get Port

Loan @ 3% Rate offer. Reply if interested.

--

Reply: [net] bonding: use return instead of goto

> On Fri, Feb 05, 2016 at 09:42:24AM +0800, 张胜举 wrote: > > > On Wed, Feb 03, 2016 at 06:15:22AM +, Zhang Shengju wrote: > > > > Replace 'goto' with 'return' to remove unnecessary check at label: > > > > err_undo_flags. > > > > > > I think you're going to have to explain how you came to the > >

Re: Reply: [net] bonding: use return instead of goto

On Fri, Feb 05, 2016 at 09:42:24AM +0800, 张胜举 wrote: > > On Wed, Feb 03, 2016 at 06:15:22AM +, Zhang Shengju wrote: > > > Replace 'goto' with 'return' to remove unnecessary check at label: > > > err_undo_flags. > > > > I think you're going to have to explain how you came to the conclusion > >

Reply: [net] bonding: use return instead of goto

> On Wed, Feb 03, 2016 at 06:15:22AM +, Zhang Shengju wrote: > > Replace 'goto' with 'return' to remove unnecessary check at label: > > err_undo_flags. > > I think you're going to have to explain how you came to the conclusion that > the check isn't necessary. > > -- > Jarod Wilson >

Reply: [PATCH iproute2] ip-link: remove warning message

> On Thu, 21 Jan 2016 02:23:49 + > Zhang Shengju wrote: > > > the warning was: > > iproute.c:301:12: warning: 'val' may be used uninitialized in this > > function [-Wmaybe-uninitialized] > >features &= ~RTAX_FEATURE_ECN; > > ^ > >

THIS BUSINESS WE BENEFIT US.>reply with(safi.kabo...@gmail.com)

Dear friend, I need your help for Transferring(US$4.5M DOLLARS)to your Bank Account. Reply Me back lets proceed also send the below requirement so i can reply you with more details so i can advice you on how to apply to the Bank for the transfer. 1)Full names. 2)country of origin. 3)Your

Review & Reply

Greetings, My name is Mr.Michael J. Tynan, I am a banker with Bank Of America. It is true that we have not meet each other in person, but I strongly believe in trust and friendship in every business. I have a Lebanese deceased customer's abandoned fund, which I am his personal financial adviser

Some ICMP-Reply messages don't arrive in User Space in recent Kernels

Hello all, I'm moving an application from 2.6.23 (yes, it's ancient; that's why we are moving) to 3.18LTS. The application monitors multiple network links to the same target with ping packets. The different links are selected either by their next hop router (Ethernet) or the network interface

Re: Some ICMP-Reply messages don't arrive in User Space in recent Kernels

Hannes, thanks for your reply. It was indeed rp_filter (found it myself). What changed were the default settings in Ubuntu (07.04 to 14.04). Regards Joerg 2015-10-13 15:18 GMT+02:00 Hannes Frederic Sowa <han...@stressinduktion.org>: > On Tue, Oct 13, 2015, at 08:47, Jörg Pommn

Re: Some ICMP-Reply messages don't arrive in User Space in recent Kernels

On Tue, Oct 13, 2015, at 08:47, Jörg Pommnitz wrote: > Hello all, > I'm moving an application from 2.6.23 (yes, it's ancient; that's why > we are moving) to 3.18LTS. The application monitors multiple network > links to the same target with ping packets. The different links are > selected either by

Re: [PATCH net] ipv4: fix reply_dst leakage on arp reply

From: Jiri Benc <jb...@redhat.com> Date: Thu, 1 Oct 2015 16:25:43 +0200 > There are cases when the created metadata reply is not used. Ensure the > allocated memory is freed also in such cases. > > Fixes: 63d008a4e9ee ("ipv4: send arp replies to the correct tunnel&

[PATCH net] ipv4: fix reply_dst leakage on arp reply

There are cases when the created metadata reply is not used. Ensure the allocated memory is freed also in such cases. Fixes: 63d008a4e9ee ("ipv4: send arp replies to the correct tunnel") Reported-by: Hannes Frederic Sowa <han...@stressinduktion.org> Signed-off-by: Jiri Benc &

[PATCH 11/30] ipvs: ensure that ICMP cannot be sent in reply to ICMP

From: Alex Gartrell Check the header for icmp before sending a PACKET_TOO_BIG Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman --- net/netfilter/ipvs/ip_vs_xmit.c |5 +++-- 1 file

[PATCH nf-next 11/15] ipvs: ensure that ICMP cannot be sent in reply to ICMP

From: Alex Gartrell Check the header for icmp before sending a PACKET_TOO_BIG Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman --- net/netfilter/ipvs/ip_vs_xmit.c | 5 +++-- 1 file

REPLY URGENTLY

Dear Friend, I'm happy to inform you about my success in getting the fund transferred under the cooperation of a new partner from London. Presently I'm in London for investment projects with my own share of the total sum. Meanwhile, I didn't forget your past efforts and attempts to assist me in

I Need Your Attention,Reply

I am Mr.Simon Isaac a regional managing director (Africa Development Bank) Ouagadougou Burkina Faso,If you are interested to help the orphans with US$9,500. million united state dollars around the world contact me and send your personal information for more details: Names... Country...

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

: err = -EINVAL; e_nobufs: err = -ENOBUFS; So I don't think anything is incorrect here. Regards, Rami Rosen On Dec 6, 2007 9:49 AM, Jarek Poplawski [EMAIL PROTECTED] wrote: On 06-12-2007 07:31, Mitsuru Chinen wrote: IPv4 stack doesn't reply any ICMP destination

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

On Thu, 6 Dec 2007 08:49:47 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote: On 06-12-2007 07:31, Mitsuru Chinen wrote: IPv4 stack doesn't reply any ICMP destination unreachable message with net unreachable code when IP detagrams are being discarded because of no route could be found

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

On 06-12-2007 09:14, Mitsuru Chinen wrote: On Thu, 6 Dec 2007 08:49:47 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote: On 06-12-2007 07:31, Mitsuru Chinen wrote: IPv4 stack doesn't reply any ICMP destination unreachable message with net unreachable code when IP detagrams are being discarded

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

On Thu, 6 Dec 2007 09:47:33 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote: On 06-12-2007 09:14, Mitsuru Chinen wrote: On Thu, 6 Dec 2007 08:49:47 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote: On 06-12-2007 07:31, Mitsuru Chinen wrote: IPv4 stack doesn't reply any ICMP destination

[PATCH] [IPv4] Reply net unreachable ICMP message

IPv4 stack doesn't reply any ICMP destination unreachable message with net unreachable code when IP detagrams are being discarded because of no route could be found in the forwarding path. Incidentally, IPv6 stack replies such ICMPv6 message in the similar situation. Signed-off-by: Mitsuru Chinen

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

From: Mitsuru Chinen [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 15:31:05 +0900 IPv4 stack doesn't reply any ICMP destination unreachable message with net unreachable code when IP detagrams are being discarded because of no route could be found in the forwarding path. Incidentally, IPv6 stack

Re: [PATCH] [IPv4] Reply net unreachable ICMP message

On 06-12-2007 07:31, Mitsuru Chinen wrote: IPv4 stack doesn't reply any ICMP destination unreachable message with net unreachable code when IP detagrams are being discarded because of no route could be found in the forwarding path. Incidentally, IPv6 stack replies such ICMPv6 message

[PATCH][v2] net/ipv4/arp.c: Fix arp reply when sender ip 0

Fix arp reply when received arp probe with sender ip 0. Send arp reply with target ip address 0.0.0.0 and target hardware address set to hardware address of requester. Previously sent reply with target ip address and target hardware address set to same as source fields. Signed-off-by: Jonas

Re: [PATCH][v2] net/ipv4/arp.c: Fix arp reply when sender ip 0

From: Jonas Danielsson [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 17:28:22 +0100 Fix arp reply when received arp probe with sender ip 0. Send arp reply with target ip address 0.0.0.0 and target hardware address set to hardware address of requester. Previously sent reply with target ip address

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

address of requestor. But if you use zero protocol address as source, you really can use any hw address. The dhcp clients I examined, and the implementation of the arpcheck that I use will compare the target hardware field of the arp-reply and match it against its own mac, to verify the reply

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

:-)), if we used our protocol address and hardware address of requestor. But if you use zero protocol address as source, you really can use any hw address. The dhcp clients I examined, and the implementation of the arpcheck that I use will compare the target hardware field of the arp-reply

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

From: Bill Fink [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 00:16:07 -0500 On Mon, 19 Nov 2007, Alexey Kuznetsov wrote: 2. What's about your suggestion, I thought about this and I am going to agree. Arguments, which convinced me are: - arping still works. - any piece of

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

Bill Fink wrote, On 11/16/2007 08:26 PM: ... Regarding the Target IP, RFC 826 says: The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

what is most likely to result in successful communication. This is likely why we are changing that target address to the one of the interface actually sending back the reply rather than the zero value you used. In fact I think this information can be useful to the sender of the DAD request

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

address? Because of this, in cases where a choice can be made Linux will advertise what is most likely to result in successful communication. This is likely why we are changing that target address to the one of the interface actually sending back the reply rather than the zero value you

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

DM == David Miller [EMAIL PROTECTED] writes: Reply: Opcode: reply (0x0002) Sender HW: 00:AA.00:AA:00:AA Sender IP: 192.168.0.1 Target HW: 00:AA:00:AA:00:AA Target IP:192.168.0.1 DM And this is exactly a sensible response in my opinion. Why send the reply at all? Sending a unicast

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

sending back the reply rather than the zero value you used. In fact I think this information can be useful to the sender of the DAD request. There seem to be some confusion about what my patch really does. It does not set the hardware address to a zero value. I knew you were

[PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

Fix arp reply when received arp probe with sender ip 0. Can't find any ground in RFC2131 to send a non-valid arp-reply in the special case of sender ip being set to 0. - Bug fix for arp handling when sender ip is set to 0. Send a correct arp reply instead of one with sender ip and sender

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

Hello! Send a correct arp reply instead of one with sender ip and sender hardware adress in target fields. I do not see anything more legal in setting target address to 0. Actually, semantics of target address in ARP reply is ambiguous. If it is a reply to some real request, it is set

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

the target ip address in the reply, it is the fact that the target hardware address is set to the hardware address of the machines that is sending the reply. The target hardware address should be the same as the destination address in the ethernet frame. The dhcp clients I examined

Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

by RFCs. Because of this, in cases where a choice can be made Linux will advertise what is most likely to result in successful communication. This is likely why we are changing that target address to the one of the interface actually sending back the reply rather than the zero value you used

Re: [PATCH RESEND] 2.6.22.6 networking [ipv4]: fix wrong destination when reply packetes

Now icmp_reply is only called by icmp_echo and icmp_timestamp ip_send_reply is only called by tcp_v4_send_reset and tcp_v4_send_ack I think in all situations the ip_hdr(skb)-saddr is set and should be the destination of reply packets. If using rt-rt_src as destination is correct in some

[PATCH RESEND] 2.6.22.6 networking [ipv4]: fix wrong destination when reply packetes

is an example (NOTE: eth0 address is set to 10.10.10.1/24): #tcpdump -n -i lo icmp [1] 3155 ... # hping3 --icmp --spoof 10.10.10.3 10.10.10.1 ... 09:53:49.508449 IP 10.10.10.3 10.10.10.1: icmp 8: echo request seq 0 09:53:49.508482 IP 10.10.10.1 10.10.10.1: icmp 8: echo reply seq 0 09

Re: [PATCH RESEND] 2.6.22.6 networking [ipv4]: fix wrong destination when reply packetes

I'm not sure why it's using rt_src here, but there are relevant cases that your description doesn't cover. For example, what happens if the source is not set in the original packet? Does NAT affect this? You quote RFC text for ICMP echo and the case where the receiving machine is the final

  1   2   >