[lwip-users] I think I found a bug/problem in lwIP stack 1.0.0 (regarding retransmissions)

[Bonny Gijzen]

Hi guys,

 

 

After extensive debugging of my problems I think I found a problem with lwIP stack.

Let me try to explain it:

 

 

When a segment is sent, it is added to the unacked list.

When the segment needs to be retransmitted, it is removed from the unacked list

and put on the unsent list (so that it can be outputted again).

After it has been re-sent it is put back on the unacked list.

 

In my case, after some time, there are multiple segments on the unacked list.

If the 1st segment on the unacked list needs to retransmitted, then (after retransmission) it

ends up at the END of unacked list.

(you could say that the unacked list gets shuffled...)

 

Now, I am not sure if this is normal, or that this shouldn't cause a problem,

but in my case it *is* causing a problem.

It seems that when an ACK response arrives it is compared against the unacked list

to see if a matching segment is found.

The "while" code should process all segments, but it starts with the 1st one, and if the 1st segment on the unacked list doesn't match then the while is exitted.

So in my case (because the unacked list was shuffled) the 1st segment didn't match and the code continued without handling the received ACK.

 

My knowlegde of the lwIP stack is not good enough to know if this behaviour is a bug or intended. I hope one of the more experienced people can have a look at it and comment on it please.

 

I have thought of 2 solutions. They use a different approach and I am not sure which one is correct or preferred:

 

1) When a segment is up for retransmission, then put it onto the unsent list, but *LEAVE* it on the unacked list aswell. Then when the segment is re-sent, the code must check if this segment is already on the unacked list. If not then add it, if it is then dont add it (because it is already there).
The big advantage of this approach is that it preserves the original order in which the segments were put on the unacked list.

(I have implemented this approach using tcp_seg_copy() and tcp_seg_free() and it is running a test at the moment)

 

2) The 2nd approach involves not touching the unacked list (so the list gets shuffled).

But when an ACK arrives the *whole* list is checked for a match, and not exitting when the 1st segment doesn't match.

 

My overall knowlegde of this stack isn't good enough to know which approach is better.
I truly hope some of you can spare the time to have a look and think about this.

 

Also, I am curious as to why other people using this stack (version 1.0.0) aren't facing these problems.

I think if the higher level API is used this problem might be avoided depending on how it is used, but I am using the raw api.

 

 

Many regards,
Bonny

 

PS. The first tests I did with lwIP required a lot of tweaking because of 32bit alignment issues.

It was just recently I found out about the padding trick in the ethernet header to avoid the 32bit alignment issues using #define ETH_PAD_SIZE

Now I am using this trick and I am running the stack without modifications.

(I have only changed the checksum to use bytes instead of 16bits)