* [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
@ 2007-06-01 3:51 Wei Yongjun
2007-06-02 10:49 ` Herbert Xu
0 siblings, 1 reply; 10+ messages in thread
From: Wei Yongjun @ 2007-06-01 3:51 UTC (permalink / raw)
To: netdev
When received ICMP Fragmentation Needed message, PATH MTU is always set
to the 576 even if MTU in ICMP message is lager then 576. This is
because of error condition in function ip_rt_frag_needed(), now if
packet size of that ICMP message is less then new MTU, packet size will
be used ,but RFC says ICMP error message return as much as we can
without exceeding 576 bytes.
This patch has Fixed this BUG.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- net/ipv4/route.c.orig 2007-05-25 05:22:47.000000000 +0800
+++ net/ipv4/route.c 2007-06-01 11:42:55.000000000 +0800
@@ -1424,7 +1424,7 @@ unsigned short ip_rt_frag_needed(struct
!(dst_metric_locked(&rth->u.dst, RTAX_MTU))) {
unsigned short mtu = new_mtu;
- if (new_mtu < 68 || new_mtu >= old_mtu) {
+ if (new_mtu < 68) {
/* BSD 4.2 compatibility hack :-( */
if (mtu == 0 &&
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-01 3:51 [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message Wei Yongjun
@ 2007-06-02 10:49 ` Herbert Xu
2007-06-04 0:39 ` Wei Yongjun
0 siblings, 1 reply; 10+ messages in thread
From: Herbert Xu @ 2007-06-02 10:49 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev
Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> When received ICMP Fragmentation Needed message, PATH MTU is always set
> to the 576 even if MTU in ICMP message is lager then 576. This is
> because of error condition in function ip_rt_frag_needed(), now if
> packet size of that ICMP message is less then new MTU, packet size will
> be used ,but RFC says ICMP error message return as much as we can
> without exceeding 576 bytes.
>
> This patch has Fixed this BUG.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- net/ipv4/route.c.orig 2007-05-25 05:22:47.000000000 +0800
> +++ net/ipv4/route.c 2007-06-01 11:42:55.000000000 +0800
> @@ -1424,7 +1424,7 @@ unsigned short ip_rt_frag_needed(struct
> !(dst_metric_locked(&rth->u.dst, RTAX_MTU))) {
> unsigned short mtu = new_mtu;
>
> - if (new_mtu < 68 || new_mtu >= old_mtu) {
> + if (new_mtu < 68) {
>
> /* BSD 4.2 compatibility hack :-( */
Huh? The test new_mtu >= old_mtu should only hold if the sending router
is buggy which is what the hack is for.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-02 10:49 ` Herbert Xu
@ 2007-06-04 0:39 ` Wei Yongjun
2007-06-04 2:55 ` Herbert Xu
0 siblings, 1 reply; 10+ messages in thread
From: Wei Yongjun @ 2007-06-04 0:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
>> When received ICMP Fragmentation Needed message, PATH MTU is always set
>> to the 576 even if MTU in ICMP message is lager then 576. This is
>> because of error condition in function ip_rt_frag_needed(), now if
>> packet size of that ICMP message is less then new MTU, packet size will
>> be used ,but RFC says ICMP error message return as much as we can
>> without exceeding 576 bytes.
>>
>> This patch has Fixed this BUG.
>>
>>
>
> Huh? The test new_mtu >= old_mtu should only hold if the sending router
> is buggy which is what the hack is for.
>
> Cheers,
>
Note here old_mtu is not the real old mtu, is the received message's size:
unsigned short old_mtu = ntohs(iph->tot_len);
So maybe the patch would like following.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- net/ipv4/route.c.orig 2007-05-25 05:22:47.000000000 +0800
+++ net/ipv4/route.c 2007-06-04 08:31:36.000000000 +0800
@@ -1424,7 +1424,7 @@ unsigned short ip_rt_frag_needed(struct
!(dst_metric_locked(&rth->u.dst, RTAX_MTU))) {
unsigned short mtu = new_mtu;
- if (new_mtu < 68 || new_mtu >= old_mtu) {
+ if (new_mtu < 68 || new_mtu >= rth->u.dst.metrics[RTAX_MTU-1]) {
/* BSD 4.2 compatibility hack :-( */
if (mtu == 0 &&
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 0:39 ` Wei Yongjun
@ 2007-06-04 2:55 ` Herbert Xu
2007-06-04 4:03 ` Wei Yongjun
0 siblings, 1 reply; 10+ messages in thread
From: Herbert Xu @ 2007-06-04 2:55 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev
On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote:
>
> >Huh? The test new_mtu >= old_mtu should only hold if the sending router
> >is buggy which is what the hack is for.
>
> Note here old_mtu is not the real old mtu, is the received message's size:
> unsigned short old_mtu = ntohs(iph->tot_len);
> So maybe the patch would like following.
The size of the packet that caused the ICMP is what we want here. That's
why the router must be buggy.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 2:55 ` Herbert Xu
@ 2007-06-04 4:03 ` Wei Yongjun
2007-06-04 4:14 ` Herbert Xu
0 siblings, 1 reply; 10+ messages in thread
From: Wei Yongjun @ 2007-06-04 4:03 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
> On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote:
>
>>> Huh? The test new_mtu >= old_mtu should only hold if the sending router
>>> is buggy which is what the hack is for.
>>>
>> Note here old_mtu is not the real old mtu, is the received message's size:
>> unsigned short old_mtu = ntohs(iph->tot_len);
>> So maybe the patch would like following.
>>
>
> The size of the packet that caused the ICMP is what we want here. That's
> why the router must be buggy.
>
>
So I want to know how the route announce a MTU larger then 576, such as
1280? RFC says ICMP error message return as much as we can without
exceeding 576 bytes.
And ipv4 router alaways return as a packet size 576 because of this.
If MTU is greater then 576, HOST will used "mtu = guess_mtu(old_mtu)" to
get a MTU. Method of send ICMP Fragmentation Needed message is
difference from receive,
how can this resolve? Change the method of send ICMP Fragmentation
Needed message? I do not think so, the only think we can do is to
change the method of receive ICMP message.
Do you agree this?
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: yjwei@cn.fujitsu.com
--------------------------------------------------
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: yjwei@cn.fujitsu.com
--------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 4:03 ` Wei Yongjun
@ 2007-06-04 4:14 ` Herbert Xu
2007-06-04 4:32 ` Wei Yongjun
0 siblings, 1 reply; 10+ messages in thread
From: Herbert Xu @ 2007-06-04 4:14 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev
On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
>
> So I want to know how the route announce a MTU larger then 576, such as
> 1280? RFC says ICMP error message return as much as we can without
> exceeding 576 bytes.
I think there is a misunderstanding here. The RFC is talking about
how much of the payload may be included in the ICMP packet. It is
not talking about the length field in the original IP header. That
must be left untouched.
> And ipv4 router alaways return as a packet size 576 because of this.
> If MTU is greater then 576, HOST will used "mtu = guess_mtu(old_mtu)" to
> get a MTU. Method of send ICMP Fragmentation Needed message is
> difference from receive,
Which router is doing that?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 4:14 ` Herbert Xu
@ 2007-06-04 4:32 ` Wei Yongjun
2007-06-04 4:55 ` Herbert Xu
0 siblings, 1 reply; 10+ messages in thread
From: Wei Yongjun @ 2007-06-04 4:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
> On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
>
>> So I want to know how the route announce a MTU larger then 576, such as
>> 1280? RFC says ICMP error message return as much as we can without
>> exceeding 576 bytes.
>>
>
> I think there is a misunderstanding here. The RFC is talking about
> how much of the payload may be included in the ICMP packet. It is
> not talking about the length field in the original IP header. That
> must be left untouched.
>
>
As you said, the RFC is talking about the payload of ICMP packet, it's
not greater then 576, if router announce a MTU larger then 1280, the
original IP header must be a size of 704? The format of ICMP message is
like this:
IPv4 header
ICMP header
payload
>> And ipv4 router alaways return as a packet size 576 because of this.
>> If MTU is greater then 576, HOST will used "mtu = guess_mtu(old_mtu)" to
>> get a MTU. Method of send ICMP Fragmentation Needed message is
>> difference from receive,
>>
>
> Which router is doing that?
>
>
>
The latest kernel 2.6.21.3 also doing so. The rule to send ICMP message
limit this.
Ref to net/ipv4/icmp.c
line 433 void icmp_send(struct sk_buff *skb_in, int type, int code,
__be32 info)
line 434 {
...
line 572 /* RFC says return as much as we can without exceeding 576
bytes. */
line 573
line 574 room = dst_mtu(&rt->u.dst);
line 575 if (room > 576)
line 576 room = 576;
line 577 room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
line 578 room -= sizeof(struct icmphdr);
line 579
line 560 icmp_param.data_len = skb_in->len - icmp_param.offset;
line 561 if (icmp_param.data_len > room)
line 562 icmp_param.data_len = room;
line 563 icmp_param.head_len = sizeof(struct icmphdr);
line 576 do this.
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: yjwei@cn.fujitsu.com
--------------------------------------------------
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: yjwei@cn.fujitsu.com
--------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 4:32 ` Wei Yongjun
@ 2007-06-04 4:55 ` Herbert Xu
2007-06-04 5:38 ` Wei Yongjun
0 siblings, 1 reply; 10+ messages in thread
From: Herbert Xu @ 2007-06-04 4:55 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev
On Mon, Jun 04, 2007 at 12:32:49PM +0800, Wei Yongjun wrote:
>
> The latest kernel 2.6.21.3 also doing so. The rule to send ICMP message
> limit this.
> Ref to net/ipv4/icmp.c
> line 433 void icmp_send(struct sk_buff *skb_in, int type, int code,
> __be32 info)
> line 434 {
> ...
> line 572 /* RFC says return as much as we can without exceeding 576
> bytes. */
> line 573
> line 574 room = dst_mtu(&rt->u.dst);
> line 575 if (room > 576)
> line 576 room = 576;
> line 577 room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
> line 578 room -= sizeof(struct icmphdr);
> line 579
> line 560 icmp_param.data_len = skb_in->len - icmp_param.offset;
> line 561 if (icmp_param.data_len > room)
> line 562 icmp_param.data_len = room;
> line 563 icmp_param.head_len = sizeof(struct icmphdr);
>
> line 576 do this.
But this is not the old_mtu field that we were talking about. The
old_mtu field comes from iph->tot_len which is the length of field
in the *original* IP header. We're certainly not allowed touch that
field.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 4:55 ` Herbert Xu
@ 2007-06-04 5:38 ` Wei Yongjun
2012-03-21 11:40 ` Ranjeeth
0 siblings, 1 reply; 10+ messages in thread
From: Wei Yongjun @ 2007-06-04 5:38 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
I know, I misunderstand the iph->tot_len, the ICMP payload is not
contained a valid ipv4 packet.
I do this under IPv6, it has no problem because IPv6 does not check
this. ^_^
Thank you very much.
> But this is not the old_mtu field that we were talking about. The
> old_mtu field comes from iph->tot_len which is the length of field
> in the *original* IP header. We're certainly not allowed touch that
> field.
>
> Cheers,
>
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: yjwei@cn.fujitsu.com
--------------------------------------------------
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: yjwei@cn.fujitsu.com
--------------------------------------------------
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message
2007-06-04 5:38 ` Wei Yongjun
@ 2012-03-21 11:40 ` Ranjeeth
0 siblings, 0 replies; 10+ messages in thread
From: Ranjeeth @ 2012-03-21 11:40 UTC (permalink / raw)
To: netdev
Hello,
I have a new query regarding the jumbo frames support in ICMP.
I am supporting jumbo frame support for self tx/rx.
So I need to handle the icmp reply and request for size of 9000.
i was able to ping upto max 3000 size. more than that icmp echo response is not
generated????
why is this???
any limitation?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-03-21 12:35 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-01 3:51 [PATCH] Fix bug of update IPv4 PMTU when received ICMP Fragmentation Needed message Wei Yongjun
2007-06-02 10:49 ` Herbert Xu
2007-06-04 0:39 ` Wei Yongjun
2007-06-04 2:55 ` Herbert Xu
2007-06-04 4:03 ` Wei Yongjun
2007-06-04 4:14 ` Herbert Xu
2007-06-04 4:32 ` Wei Yongjun
2007-06-04 4:55 ` Herbert Xu
2007-06-04 5:38 ` Wei Yongjun
2012-03-21 11:40 ` Ranjeeth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).