tasklwIP - A Lightweight TCP/IP stack - Tasks: task #6861, Pimp ip_frag.c

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #6861: Pimp ip_frag.c

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Wed 09 May 2007 07:27:13 AM UTC
   
 
Category:  None Should Start On:  Wed 09 May 2007 12:00:00 AM UTC
Should be Finished on:  Sun 05 Aug 2007 12:00:00 AM UTC Priority:  1 - Later
Status:  In Progress Privacy:  Public
Assigned to:  taranowski Percent Complete:  100%
Open/Closed:  Closed Planned Release:  1.3.0
Effort:  0.00

Jump to the original submission

Thu 18 Oct 2007 08:14:34 PM UTC, comment #41: 


> I don't have check-in permissions


Oh, OK! I didn't know that. Didn't know you could assign a task but don't have check-in permissions.

Anyway, since v1.43 I think it's 100% complete so could be marked as done. Only didn't update this task, yet.

So I'll close it as done. Reopen it if you find any problems.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 17 Oct 2007 08:19:11 PM UTC, comment #40: 

Thanks for checking in those modifications Simon. I don't have check-in permissions, hence the post-the-patch approach.  I should have some time in a week or two to test out Simon's modifications.

What is this task blocking on now?  It looks like Simon has implemented all the changes he wanted to get in.

Thomas Taranowski <taranowski>
Group Member
Thu 11 Oct 2007 07:51:47 PM UTC, comment #39: 

I have included code to free the oldest packets (not the currently assembled, however) until enough pbufs are freed to enqueue the new fragment. This is also done if MEMP_REASSDATA is empty.

I've also included an ifdef around it. Not included that in opt.h so far, because I'm not sure if we really need to disable it.

Any comments (and tests) are welcome!

Simon Goldschmidt <goldsimon>
Group administrator
Wed 10 Oct 2007 01:17:43 PM UTC, comment #38: 


>  I didn't mean the oldest fragments full stop, I meant the oldest packet being reassembled.


Hehe, OK, I was thinking the oldest fragment all the time. Throwing away the oldest packet might be enough and is simpler, of course.

Although there is a little more to be done to prevent a deadlock, it's still very simple, yes.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 10 Oct 2007 12:09:00 PM UTC, comment #37: 


>> discard the oldest fragments when reassembling
>
> I've been thinking about how to code this, and I didn't really
> find a solution except generating a second linked list of all
> fragments in the order of their creation (including a pointer to
> the packet they are enqueued), which isn't really in the spirit
> of lwIP for me...
>
> Any other ideas?


I think I may have been imprecise. I didn't mean the oldest fragments full stop, I meant the oldest packet being reassembled. Discarding individual fragments wouldn't help as you may be discarding other parts of the same packet you're reassembling!

So what I meant was the oldest (incomplete) packet, and we can already determine the oldest one using the timer field. The solution with least code is probably just to loop calling ip_reass_tmr() until there's space. In other words:

  while ((ip_reass_pbufcount + clen) > IP_REASS_MAX_PBUFS) {
    ip_reass_tmr();
  }

Jonathan Larmour <jifl>
Group Member
Tue 09 Oct 2007 07:34:05 PM UTC, comment #36: 


> discard the oldest fragments when reassembling


I've been thinking about how to code this, and I didn't really find a solution except generating a second linked list of all fragments in the order of their creation (including a pointer to the packet they are enqueued), which isn't really in the spirit of lwIP for me...

Any other ideas?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 09 Oct 2007 06:15:39 AM UTC, comment #35: 


> rc\core\ipv4\ip_frag.c (336) : warning: potential uninitialized
> reference to "iprh_tmp" in func "_chain_frag_into_packet_and_validate"


That was a type only. The right variable is "iprh", but obviously, "iprh_tmp" has the same value at that point, which is why it worked anyway...

Simon Goldschmidt <goldsimon>
Group administrator
Mon 08 Oct 2007 02:37:27 PM UTC, comment #34: 

Hmm, Thomas marked it as done, but I don't know what his status on this task is...

> I see the solution to using IP_HLEN...


Not using IP_HLEN is not that easy for us since we have the ram for the IP header 'statically' allocated in the struct ip_reassdata. If we don't know how long the header will be, we have to allocate that ram from the heap :-(

The 'throw away old fragments and favour new ones' thing is another thing that's open, yes. I'll think about how to do that...

Simon Goldschmidt <goldsimon>
Group administrator
Mon 08 Oct 2007 01:57:00 PM UTC, comment #33: 

Thanks for this Simon. I see the solution to using IP_HLEN or not is to just drop it if there are options - that's fair enough :). At least it's obvious what's going on.

The only thing is that I couldn't see any change to discard the oldest fragments when reassembling (otherwise we get the situation where we can't reassemble anything new either, so no reassembly will happen until the reassembly timer has timed out).

I realise it may not be done straight away, but in that case, I would like this task to be left open, not to be considered done.

Jifl

Jonathan Larmour <jifl>
Group Member
Mon 08 Oct 2007 07:40:54 AM UTC, comment #32: 

I add a default value in opt.h for MEMP_NUM_REASSDATA (but it need to be comment and tune), so, now, I can build. But I got this warning :

src\core\ipv4\ip_frag.c (336) : warning: potential uninitialized reference to "iprh_tmp" in func "_chain_frag_into_packet_and_validate"

Frédéric Bernon <fbernon>
Group Member
Mon 08 Oct 2007 07:28:33 AM UTC, comment #31: 

It seems there is a build problem with last changes:

inc/lwip/memp_std.h (47) : error: identifier "MEMP_NUM_REASSDATA" is undefined

In my lwipopts.h, I got:

#define IP_REASSEMBLY                   1
#define IP_FRAG                         1

When I look in opt.h, there is no default value for MEMP_NUM_REASSDATA.

Frédéric Bernon <fbernon>
Group Member
Sun 07 Oct 2007 11:54:43 AM UTC, comment #30: 

I just have added checks for overlapping and duplicate fragments. These are thrown away to prevent blocking of PBUF_POOL pbufs when they aren't needed. The checks are not big (4 if-statements), but still can be ifdef'ed out until we decide we really want them in.

Simon Goldschmidt <goldsimon>
Group administrator
Sat 06 Oct 2007 03:31:19 PM UTC, comment #29: 

OH, I forgot: if noone has any comments or change requests for this, I'd consider it as really done now and would close it!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 06 Oct 2007 03:29:48 PM UTC, comment #28: 

After waiting for some time now, I ported Thomas' patch to the newest CVS HEAD and checked it in with some changes:

- Combined chain & validate
- Changed the doubly linked list into a single linked list

Also changed the SNMP code for the maximum reassembly size and added the necessary options (removing the old IP_REASS_BUFSIZE option).

Thomas, please don't hit me for checking in although it's assigned to you, I simply couldn't wait to move on here after making the first patch!

Any comments are welcome!!!

BTW: why is this planned for 1.3.0 and at the same time marked as priority: 'later'??

Simon Goldschmidt <goldsimon>
Group administrator
Thu 09 Aug 2007 02:30:36 PM UTC, comment #27: 

I didn't get round to replying to Thomas either. First, thanks for your further efforts on this Thomas.

If it reduces the effort to get a first pass at this in, perhaps just keep the double linked list, and add a FIXME comment, that there's scope for improvement with a singly linked list.

I agree with Simon, that combining chain and validate wouldn't shrink code much, but it would a bit, and indeed be more efficient.

Everything else you say in comment #25 is fine as far as I'm concerned, Thomas, thx.

Jonathan Larmour <jifl>
Group Member
Thu 09 Aug 2007 02:13:39 PM UTC, comment #26: 

Since I'm currently only checking my emails (not at home yet), I can't really look at the code. But some comments anyway:
- The doubly linked list was necessary with my first try, I think it can be converted to a simple linked list by remembering the previous element when going through the list.
- I'd also vote for throwing away the oldest fragment. Although there's a chance we throw away fragments too fast, that would be a result of misconfiguration almost certainly.
- If combining chain and validate works, it would be good for performance. I'm not convinced it would shrink the code much, though.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 03 Aug 2007 08:10:48 PM UTC, comment #25: 

Thanks for the careful review Jonathan...

- Ouch, sorry about the tabs.  I hate when that happens.
- Static comments noted, and mods made.
- Didn't know about the IP_HLEN vs. IPH_LEN.  I'll fix those up and retest any reassembly code that uses those in the next couple days.
- I would say you are correct on the else if. I converted to just the plain old else.
- if ((ip_reass_pbufcount + clen) > IP_REASS_MAX_PBUFS) {
  It's true that we can't assemble anything more until some pbufs have been freed, by either completing assembly of a payload, or having the timer expire and free a stale entry.  The problem I see, and I think you are hinting at, is that with the check there, we don't accept any more pbufs once we hit that check, and therefore are unable to complete any new datagrams, therefore the oldest one MUST expire before we can continue, and hope to assemble any further.  Timing out the oldest one is a reasonable solution, and seems better than what we have now.  I'd like to have the code be smart, and check to see if accepting the packet would complete a datagram first, before it just discards it out of hand, and then, if it's unable to, go ahead and time out the oldest one. 

- doubly linked list - I'm not convinced of anything in this life anymore :)  The doubly linked list Simon introduced seemed like a reasonably solution, and I didn't bother trying to refactor it out.  If we could, I think it would simplify the code a good deal.  I think that would probably be a good goal of another patch, along with a fix for the "@todo What to do on bogus datagram?" block, and a method to trim datagrams to fit(which should be optional code).

- combine validate and chain - the problem with that is that, when chaining the fragment, it's perfectly acceptable for there to be segments missing from the chain (start!=end).  However, the validate requires that the segments be contiguous.  Maybe something like a currently valid/contiguous marker could be maintained in the chain_frag loop, to shortcut the validate call in most cases.

- The previous reassembly code used a large static buffer/array, which to me is more grievous than introducing extra code.  While working through the code, I felt there were a number of cases where the code could be reworked into common sections, and shortened.

I've attached a detabbed/static-i-fied patch.  I'll post the IPH_LEN, and some additional cleanup, patch once I get some time to test.



(file #13574)

Thomas Taranowski <taranowski>
Group Member
Fri 03 Aug 2007 03:45:58 PM UTC, comment #24: 

I should just mention that I was commenting on the state of the file now, not only Thomas' changes - some of these comments apply to what was there before it was p1mp3d. Thanks for being a p1mp, Thonmas ;).

Jonathan Larmour <jifl>
Group Member
Fri 03 Aug 2007 03:41:11 PM UTC, comment #23: 

Thanks Thomas.

A few comments:
- TABs seem to be messing up the indenting, at least for me.
- Almost all functions need to be static.
- There are still uses of the IP_HLEN constant, instead of IPH_LEN
- In ip_reass_tmr():
} else if (r->timer == 0) {
can just be:
 } else {
surely?

- This check:
 if ((ip_reass_pbufcount + clen) > IP_REASS_MAX_PBUFS) {
is interesting, because it means we effectively cannot reassemble anything any more, until a timer expires one of them. Perhaps instead it should it should loop calling ip_reass_tmr() (to expire the oldest packets) until space appears.
- I'm not convinced of the need for a doubly linked list.
- I feel that it would save something if the operation of validate_datagram could be incorporated into chain_frag_into_datagram, rather than repeating the work.



This seems like a whole lot of code that's going to be made compulsory for reassembly.

Jonathan Larmour <jifl>
Group Member
Fri 03 Aug 2007 06:52:24 AM UTC, comment #22: 

I've finished debugging/reworking Simon's patch, and it be p1mp3d. I've done some testing, and it works reliably.  I attached the patchfile    for the ip_frag.c file.  The other parts of Simon's original patch are unmodified.

(file #13563, file #13564)

Thomas Taranowski <taranowski>
Group Member
Thu 26 Jul 2007 03:15:23 PM UTC, comment #21: 

I think this is something we have to cope with.  Just waiting for a retransmission is no good as the retransmitted one may also overlap (there's a good chance of this).  We'd throw that one away too, and all future retransmissions, and so never make any progress.

Coping with the overlap should be fine.  There's similar code to do this already when we're adding/removing packets from the out-of-order list on packet reception I think.

Kieran Mansley <kieranm>
Group Member
Thu 26 Jul 2007 02:46:47 PM UTC, comment #20: 

Re comment #19:
yes and yes. I didn't really think about it, I was just implementing like it was. But I like both ideas.

Re comment #18:
It would be OK if it never happend, but what does the reassembled packet look like if it does happen? We would have to throw away the unfitting fragment and let the transmission time out...

Whatever we do, we have to check that the boundaries fit or else the reassembled packet will be wrong.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 26 Jul 2007 02:17:56 PM UTC, comment #19: 

From just visually looking at the code, it looks good.  Just two minor thoughts though:

a) should we instead reset the timer value for a reassembled buffer each time a fragment is received?

Imagine a 38400 bps modem - a 64Kbyte IP packet (consisting of many fragments) would take at least 13 seconds to receive. Sure, the developer can tweak IP_REASS_MAXAGE, but it just seems better to me that if the packet transmission is not yet stopped, we don't allow the reassembly to time out.

b) At various points the constant IP_HLEN is used for the header length. But shouldn't this be using the supplied header length within the header, given the possibility of options?

Jonathan Larmour <jifl>
Group Member
Thu 26 Jul 2007 01:58:26 PM UTC, comment #18: 


> What doesn't work yet is trimming pbufs if fragments don't
> exactly fit to each other (i.e. overlap) (e.g. due to
> retransmission using a different path over the internet).


Is that something we have to worry about that much in practice? That would seem to be the type of corner case which a "lightweight" stack needn't be expected to support (whatever the RFCs may strictly say).

Jonathan Larmour <jifl>
Group Member
Mon 23 Jul 2007 09:31:08 PM UTC, comment #17: 

Thanks Simon.  I'll perform some testing on the patch this week.

Thomas Taranowski <taranowski>
Group Member
Mon 23 Jul 2007 09:03:08 PM UTC, comment #16: 

I'm attaching a patch and the file ip_frag.c with my changes.

I did have to work a little on it to make it presentable and test it a little, still I'm not really convinced it is bug-free since testing this is a little hard.

What the new code should do is the following:
- move the global variables into a struct to support multiple simultaneously arriving IP packets to be reassembled at the same time (say, struct ip_reassdata)
- those structs should come from a (new) memp pool (maybe chain them on a queue to keep track of the current packets)
- instead of a reassbuf, the incoming pbufs should be used, chaining them together when the whole packet is received. This way we a) prevent copying the data and b) don't have to provide the memory for it all the time
- the maximum simultanously reassembled packets are limited by the memp pool the ip_reassdata struct comes from
- the maximum number of pbufs being queued for reassembly has also be limited in order to prevent queueing all the PBUF_POOL pbufs, which could deadlock the stack because no more packets can be received since the pbuf pool is empty (timeout also works, but may lead to 'nearly-deadlocking')


I moved from the bitmap algorithm to chaining the pbufs and remembering their offset & length (I use the space of the IP header that is not used after receiving).

What doesn't work yet is trimming pbufs if fragments don't exactly fit to each other (i.e. overlap) (e.g. due to retransmission using a different path over the internet).

BTW: the code size stays roughly the same on my embedded target (old: 1346 bytes vs. new: 1364 bytes).

(file #13444, file #13445)

Simon Goldschmidt <goldsimon>
Group administrator
Mon 23 Jul 2007 02:58:22 PM UTC, comment #15: 

I plan to be working the ip reassembly code pretty heavy this week, as I need some performance improvements for the short term.  However, At the moment, I'm not interesting reinventing the wheel if Simon already has done some work on this.  What's the current status on the design/implementation?

Thomas Taranowski <taranowski>
Group Member
Fri 20 Jul 2007 05:44:18 PM UTC, comment #14: 


> Re comment #9:
> Kieran wrote: [..]


I think he meant the new reassembly code which isn't yet written ;-) i.e. holding the input PBUF_POOLs until a packet is completely received and passing a pbuf list of those packets to ip_input.

> That being said, a fixed size, permanently allocated large buffer
> seems worse.


Which would result in "we don't need the configuration option" since we want to be lightweight, not fast? I'll have a look at the code sizes...

Simon Goldschmidt <goldsimon>
Group administrator
Fri 20 Jul 2007 03:16:31 PM UTC, comment #13: 

Hi folks. Sorry I've been out of touch - I was off on vacation for 3 weeks or so, and then returned to work to be dumped into major firefighting. I'm only now starting  on the lwIP backlog that built up in the time. Anyway.....

Re comment #7: I've no idea what was going on there. I know I tested some version of the code but it's highly improbable it could have worked with that flaw. Unless perhaps I made what I thought was a minor tweak after testing :-|. Anyway, what you say is right.

Re comment #8: I assume you're referring to the IP_FRAG_USES_STATIC_BUF==1 case. I guess you could indeed use a PBUF_RAM. However this would make even more obvious a flaw with the static buffer approach - what if the hardware hasn't sent the pbuf by the time this function could have been called a second time. But nicely enough, using a pbuf does seem to allow us a way to catch this - check the pbuf reference count.

Re comment #9:
Kieran wrote:

> Out of interest, has anything been done with this option to
> prevent the reassembly code consuming all the pbufs, so
> stopping the rest of the stack?


I'm not sure what the issue you're referring to here is - the reassembly code only allocates pbufs when reassembly is complete. If you were referring to the fragmentation code, then that does not store up pbufs - any created pbufs should get sent to the hardware; or if memory runs out, freed.

Re comment #10:

> (BTW I'm still not convinced we need a switch for this, the
> PBUF_REF code should be OK!)


I don't mind personally, but clearly the PBUF_REF code is bigger, and takes longer (lots of pbuf allocs being done as well as the code itself). That being said, a fixed size, permanently allocated large buffer seems worse.

Jonathan Larmour <jifl>
Group Member
Fri 13 Jul 2007 12:40:51 PM UTC, comment #12: 


> Any update on this?


No yet, really, but I'd certainly do it for 1.3.0. It's all planned in my head, after all, and only has to be coded, since we already talked a lot about it and have made everything quite clear.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 13 Jul 2007 12:06:18 PM UTC, comment #11: 

Any update on this?  I'm tempted to tag it as required for the 1.3.0 release, as it seems mostly done, but would like to make sure that's feasible before I do.

Kieran Mansley <kieranm>
Group Member
Tue 26 Jun 2007 03:46:31 PM UTC, comment #10: 

There are 2 patches:

The first comes from Jonathan and is for ip_frag. You can either use an u8_t buf[MAX_MTU_SIZE] and copy outgoing data there or let PBUF_REF point into the data. (BTW I'm still not convinced we need a switch for this, the PBUF_REF code should be OK!)

The second is not yet done (it's my todo for this week :) and it should use PBUF_POOL / PBUF_RAM for reassembling packets. There will be an option how much packets can be allocated for one packet and how much packets ip_reass may allocate at all. Other than that, I can't think of an option (we have no way to determine how much buffers are left, yet - aside from stats, which can be turned off).

Simon Goldschmidt <goldsimon>
Group administrator
Tue 26 Jun 2007 03:36:52 PM UTC, comment #9: 

Do you mean use a single PBUF_RAM as a static buffer for the whole reassembled packet?  I thought that this patch was trying to move away from a single static buffer. 

Out of interest, has anything been done with this option to prevent the reassembly code consuming all the pbufs, so stopping the rest of the stack?

Kieran Mansley <kieranm>
Group Member
Tue 26 Jun 2007 03:28:10 PM UTC, comment #8: 

Why can't we allocat a PBUF_RAM in ip_reass_init() (or ip_frag_init :) and use that as the static buffer? That way we wouldn't have to allocate a PBUF_REF (for data and IP header) and a PBUF_RAM (for link header) but simply could reuse the single PBUF_RAM all the time.

Jonathan?

Simon Goldschmidt <goldsimon>
Group administrator
Sun 03 Jun 2007 06:37:34 PM UTC, comment #7: 

Jonathan, I tried to integrate your patch and get a compiler warning that iphdr is accessed uninitialized on line 334 (for your version based on v1.1.1).

Could it be that around line 330, "iphdr = p->payload" or "iphdr = original_iphdr" is missing? Or is it more than that?

I've checked it in with that change (defaulting to the old implementation, for now).

Simon Goldschmidt <goldsimon>
Group administrator
Sat 02 Jun 2007 05:15:27 PM UTC, comment #6: 

I've just 'stumbled' accross ip_frag_init(). Since we have different options for frag and reass, and ip_frag_init() really initialzes the reassembly variables, shouldn't it be named ip_reass_init()???

Frag doesn't seem to need initialization for now, maybe later after the change.

I only ask because I plan to include some more ifdefs to separate the frag part from the reass part (seems unlikely to me someone wants to enable one without the other but since we have the options....).

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 11:50:21 AM UTC, comment #5: 

Good, I got permission. I'm attaching the fragmentation patch against 1.1. It does not presently apply cleanly against CVS and I haven't updated it, but you're going to be changing even more stuff in this area anyway.

If pbuf_alloc fails, the packet is simply dropped, with ERR_MEM.

The following was what I added to opt.h:
-=-=-=-=-=-=-=-=-=-=-=-=-
/* Use a static MTU-sized buffer for IP fragmentation.

  • Otherwise pbufs are allocated and reference the original
  • packet data to be fragmented.

 */
#ifndef IP_FRAG_USES_STATIC_BUF
#define IP_FRAG_USES_STATIC_BUF         0
#endif

/* Assumed max MTU on any interface for IP frag buffer */
#if IP_FRAG_USES_STATIC_BUF && !defined(IP_FRAG_MAX_MTU)
#define IP_FRAG_MAX_MTU                 1500
#endif
-=-=-=-=-=-=-=-=-=-=-=-=-




(file #12728)

Jonathan Larmour <jifl>
Group Member
Wed 09 May 2007 09:55:10 AM UTC, comment #4: 

My suggestion would be to hold PBUF_POOLs temporarily to reassemble them later. Let's say I'd allow a maximum of 10 packets consisting of PBUF_POOLs (of tot_len = maximum MTU). I would then allocate those pbuf chains in ip_frag_init() and free one each time I put a new packet in the reassembly-list. That way I guarantee the amount of pbufs in the pool stays the same while still avoiding 2*memcpy() for each reassembled packet (which, in my opinion, fits even better to the name "lwIP" :)

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 09:46:59 AM UTC, comment #3: 

I'm quite concerned about the risk of running out of PBUFs.  Swapping a problem of it not performing well (because it can't do much reassembly, and so more retransmissions are required) for one where the stack grinds to a halt because its run out of buffers wouldn't be a good idea.  If we can ensure that doesn't happen, I'd be happier to see this go in. 

Currently the reassembly is admittedly pretty simplistic, but that's not necessarily a bad thing given lwIP's goals.

Kieran Mansley <kieranm>
Group Member
Wed 09 May 2007 09:43:06 AM UTC, comment #2: 


>I'll check if I'm allowed to post it.


That would surely be better as what there is now.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 09 May 2007 09:33:06 AM UTC, comment #1: 

I have a patch against lwIP 1.1 to allow ip_frag to either use a static buffer (like the current implementation) or create a sequence of PBUF_REFs pointing into the payload of the original buffer.

I'll check if I'm allowed to post it.

Note that if you allow reassembled packets to be given as a chain, care (or at least a config option) would be needed to prevent running out of pool pbufs and locking the stack (because they were sitting on a chain waiting for the last bits to be reassembled).

Jonathan Larmour <jifl>
Group Member
Wed 09 May 2007 07:27:13 AM UTC, original submission:  

- segments could be "queued" as pbufs so no copy is needed (memcpy to reassbuf could be avoided)
- reassembled packets could be given to ip_input as a pbuf chain (memcpy from reassbuf could be avoided)
- that way, we could easily allow more than one fragmented IP packet to be reassembled at a time (e.g. different source hosts / packets lost...)

- care might have to be taken that ip_input() can cope with chained pbufs (but I think that shouldn't be a problem)

- copy_from_pbuf is roughly the same as netbuf_copy_partial. both could be moved into one function residing in pbuf.c to reduce code footprint

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #13574:  ip_frag.c.detabbed_and_static added by taranowski (20KiB - application/octet-stream)
file #13563:  ip_frag.c.patch_redeux added by taranowski (20KiB - application/octet-stream)
file #13564:  ip_frag.c added by taranowski (21KiB - text/x-csrc)
file #13444:  ip_frag.c added by goldsimon (17KiB - text/x-csrc)
file #13445:  ipreass_queue.patch added by goldsimon (20KiB - text/x-patch)
file #12728:  lwip-ipfrag-pbuf.patch added by jifl (6KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by taranowski (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    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 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-10-18 goldsimon Percent Complete80% 100%
        Open/ClosedOpen Closed
    2007-10-11 goldsimon Percent Complete60% 80%
    2007-10-09 goldsimon StatusDone In Progress
        Percent Complete0% 60%
    2007-08-03 taranowski Attached File- Added ip_frag.c.detabbed_and_static, #13574
    2007-08-03 taranowski StatusReady For Test Done
    2007-08-03 taranowski Attached File- Added ip_frag.c.patch_redeux, #13563
        Attached File- Added ip_frag.c, #13564
    2007-07-27 taranowski Should be Finished on2007-05-09 2007-08-05
    2007-07-27 taranowski Assigned toNone taranowski
    2007-07-23 goldsimon Attached File- Added ip_frag.c, #13444
        Attached File- Added ipreass_queue.patch, #13445
    2007-07-13 goldsimon Planned ReleaseNone 1.3.0
    2007-06-03 goldsimon StatusNone Ready For Test
    2007-05-09 jifl Attached File- Added lwip-ipfrag-pbuf.patch, #12728

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code