lwIP - A Lightweight TCP/IP stack - Patches: patch #5834, Don't fragment flag
You are not allowed to post comments on this tracker with your current authentication level.
patch #5834: Don't fragment flag
Submitter: | Frédéric Bernon <fbernon> | ||
Submitted: | Thu 29 Mar 2007 03:18:14 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | fbernon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Tue 03 Apr 2007 01:59:13 PM UTC, comment #24: |
Frédéric Bernon <fbernon> |
Tue 03 Apr 2007 01:53:12 PM UTC, comment #23: I don't have strong opinions either way, but now we seem to have some understanding about why it was there, I'm happy to remove it and just set to zero. Seems simplest. |
Kieran Mansley <kieranm> |
Tue 03 Apr 2007 01:33:31 PM UTC, comment #22: I'm happy if it is set to zero for good.
|
David Empson <dempson> |
Tue 03 Apr 2007 01:14:47 PM UTC, comment #21: Right, but IP_FRAG_FLAGS in ip.h give the possibility to someone to keep the current behavior (I don't know, perhaps there is a very strange reason I don't understand). And it's not a Heavy change :)
And that was a very first idea (see file #12332) :)
|
Frédéric Bernon <fbernon> |
Tue 03 Apr 2007 01:09:10 PM UTC, comment #20: Re comment #19:
|
Simon Goldschmidt <goldsimon> |
Tue 03 Apr 2007 01:03:56 PM UTC, comment #19: Yep, yep , yep...
|
Frédéric Bernon <fbernon> |
Tue 03 Apr 2007 12:32:39 PM UTC, comment #18: In our initial port (based on 1.2.0) we noticed the DF flag was set, and couldn't see any reason for it to be there (without path MTU discovery), so we simply turned it off. We have reassembly enabled at present, and are only talking to full TCP/IP implementations which support reassembly, so it won't be a problem yet. We aren't particularly short of memory so I see no need for us to disable reassembly.
|
David Empson <dempson> |
Tue 03 Apr 2007 08:19:51 AM UTC, comment #17:
|
Frédéric Bernon <fbernon> |
Tue 03 Apr 2007 06:45:04 AM UTC, comment #16: I think a reason to associate it with IP_REASSEMBLY is that if you can't send to the other host without fragmentation, the other host won't succeed in that, either.
|
Simon Goldschmidt <goldsimon> |
Mon 02 Apr 2007 11:12:24 PM UTC, comment #15: It doesn't seem to me that associating the state of the IP_DF flag with IP_REASSEMBLY is a reasonable choice. They apply to opposite directions of the communication dialogue.
|
David Empson <dempson> |
Fri 30 Mar 2007 01:35:38 PM UTC, comment #14: Remember if one day it's necessary (by example, to implement a "MTU discovery" client), that we could add a IP_DONTFRAGMENT option (for IPPROTO_IP level) for get/setsockopt... |
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 01:27:54 PM UTC, comment #13: OK. |
Kieran Mansley <kieranm> |
Fri 30 Mar 2007 01:24:24 PM UTC, comment #12: Proposed patch attached. |
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 12:37:37 PM UTC, comment #11: Not sure about the reason of IP_DF per default. Look the original file :
|
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 11:20:34 AM UTC, comment #10: I would only set it to 0 if lwIP supports reassembling. In other words ifdef it with IP_REASSEMBLY. Maybe that is why it was included in the initial version of ip.c (maybe reassembly was not supported then, I didn't check CVS, though) |
Simon Goldschmidt <goldsimon> |
Fri 30 Mar 2007 10:11:41 AM UTC, comment #9: In "RFC 791 - Internet Protocol", we can read :
|
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 09:02:51 AM UTC, comment #8: I search in the web CVS, and it was already here in the first file version:
|
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 08:55:06 AM UTC, comment #7: The only use I know about that is to discover max MTU on a path (like with the ping -f). I suppose it's just a mistake...
|
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 08:48:23 AM UTC, comment #6: No, I don't think we need to have an option for this. I just wish I understood why that line of code was written in the first place. I wonder if someone knew something we don't! |
Kieran Mansley <kieranm> |
Fri 30 Mar 2007 08:34:13 AM UTC, comment #5: If someone really need it as default (but will be strange, but, why not), I can add in opt.h a
|
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 08:27:04 AM UTC, comment #4: I suppose so. I'd like to understand this a bit better and work out why that line was there in the first place, but don't have time really!
|
Kieran Mansley <kieranm> |
Fri 30 Mar 2007 08:08:48 AM UTC, comment #3: I test to remove, but I got problems (I have supposed that this field wasn't initialized and could contains anything, but I don't search more...). Ok for you? |
Frédéric Bernon <fbernon> |
Fri 30 Mar 2007 07:59:22 AM UTC, comment #2: Would it be better to just remove that line rather than replace it with one that sets it to zero? I'm not sure. |
Kieran Mansley <kieranm> |
Thu 29 Mar 2007 05:51:39 PM UTC, comment #1: Proposed patch file attached (just set to 0 fragment flags).
|
Frédéric Bernon <fbernon> |
Thu 29 Mar 2007 03:18:14 PM UTC, original submission:
In last March (March 22th 2006), a user tell us there was a problem with ip.c: "IPH_OFFSET_SET(iphdr, htons(IP_DF))" is always called in ip_output_if (even if you have enable IP_FRAG and IP_REASSEMBLY). This limitation is really important, because if big packets are sent by a circuit with several routers, where MTU is lower than the one lwIP use, packets are lost.
|
Frédéric Bernon <fbernon> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-04-03 | fbernon | Open/Closed | Open | Closed | |
2007-04-03 | fbernon | Open/Closed | Closed | Open | |
2007-03-30 | fbernon | Status | None | Done | |
Open/Closed | Open | Closed | |||
2007-03-30 | fbernon | Attached File | - | Added IP_DF.patch, #12346 | |
2007-03-29 | fbernon | Attached File | - | Added IP_DF.patch, #12332 |
Powered by Savane 3.13-02a9.
Corresponding source code
Ok, I change it :)