Nabble - lwip-devel

[patch #7026] NetIO server implementation

2009-12-18T12:14:05Z

Follow-up Comment #5, patch #7026 (project lwip):

I apologize for the noise in the patch manager, I should have posed the
question to the list before posting.

But I did contact the staff at wikia and they were kind enough to enable the
upload of non-image files: *.c, *.h, and *.def (in hindsight I should have
asked for *.txt too!).

I uploaded the netio.c file using the "Upload a new image" link.

see: http://images1.wikia.nocookie.net/lwip/images/8/8b/Netio.c

I did not link to it from anywhere in the wiki, because I don't want to make
that decision :) I will update whatever page manifests itself to serve that
purpose.

The staff member ("uberfuzzy") warned that you might see some warnings that
he should have cleaned up over the weekend, though I did not see any.

I also asked for a special code syntax highlighting extension
(SyntaxHighlight GeSHi) to be enabled in the wiki markup, which may be useful
for code in wiki content... though I have not tested to see if it is working.
Supposedly the markup is: <syntaxhighlight lang="c"> .. </syntaxhighlight>.

Thanks,
MD

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28342] Many unnecessary records in ARP table

2009-12-18T12:05:46Z

URL:
<http://savannah.nongnu.org/bugs/?28342>

Summary: Many unnecessary records in ARP table
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: persich
Submitted on: Fri 18 Dec 2009 08:05:45 PM GMT
Category: ARP
Severity: 3 - Normal
Item Group: Change Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: CVS Head

_______________________________________________________

Details:

I found full ARP table with 16 items in very short time during my testing of
ARP protocol in my project (Atmel AVR32 UC3A0512). I discovered that in this
table is many unused IP addresses from my LAN. I found that every incoming IP
address in ARP Request Packet from LAN is stored to "arp_table". It is better
if in ARP table is only addresses which is necessary for MCU communication,
not all from LAN, I think. It is reduce MCU utilization, I think.
I found flag "ETHARP_FIND_ONLY" in file "etharp.c" and I made two small
changes:
line #605 in "etharp.c" (Rev 1.153):
old: update_arp_entry(netif, &(iphdr->src), &(ethhdr->src), 0);
new: update_arp_entry(netif, &(iphdr->src), &(ethhdr->src),
ETHARP_FIND_ONLY);
line #702:
old: update_arp_entry(netif, &sipaddr, &(hdr->shwaddr), 0);
new: update_arp_entry(netif, &sipaddr, &(hdr->shwaddr), ETHARP_FIND_ONLY);
With this changes ARP works ok - I think ... :-) - and in ARP table are only
used IP addresses not all LANs.
And one idea. Is it possible move declaration of "struct etharp_entry" and
"enum etharp_state" from "etharp.c" to "etharp.h", remove "static" from
arp_table definition and add declaration of "arp_table" in "etharp.h" for
diagnostics purpose ? There is not semaphore to this structure, I know ... But
for diagnostic it is not necessary, I think.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28342>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[patch #7026] NetIO server implementation

2009-12-16T02:17:06Z

Follow-up Comment #4, patch #7026 (project lwip):

I wonder if the mailing list archive retains attachments? If so a post to
the mailing list would have the double purpose of letting people know of this
code and then allowing us to link to the archive from the wiki so people could
easily obtain it later.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[patch #7026] NetIO server implementation

2009-12-16T02:14:32Z

Follow-up Comment #3, patch #7026 (project lwip):

The broblemisto find a location for "elsewhere"... Not everyone has space to
upload available somewhere.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[patch #7026] NetIO server implementation

2009-12-16T01:35:32Z

Follow-up Comment #2, patch #7026 (project lwip):

I guess the best thing would be to host it elsewhere and link to the wiki.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[patch #7026] NetIO server implementation

2009-12-15T22:34:03Z

Update of patch #7026 (project lwip):

Status: None => Invalid
Open/Closed: Open => Closed

_______________________________________________________

Follow-up Comment #1:

> So I am posting this here due to the lack of an organized
> "unmaintained" section of the download area on savannah.

Although I regret not having such an area, this is not the correct place to
put it. It's an application building on top of the stack, not a patch to the
stack. Putting things like this here only makes getting an overview of the
current patches (and bugs, tasks) more difficult.

If you have an idea of where to put such things (the download area is also
not an ideal solution since it's for our releases only, as far as I know),
please tell us. Unfortunately, there's no possibility to upload files to the
wiki, either.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[patch #7026] NetIO server implementation

2009-12-15T15:02:02Z

URL:
<http://savannah.nongnu.org/patch/?7026>

Summary: NetIO server implementation
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: m_dittrich
Submitted on: Tue 15 Dec 2009 11:02:01 PM GMT
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Planned Release: None

_______________________________________________________

Details:

Attached you will find a RAW api implementation of a netio tcp server,
licensed the same as the rest of lwIP.

It's buggy and ugly, but seems to work against the win32 client available in
the netio126.zip download available on the net. It does not calculate any
throughput results, it relies on the client/PC side for that. I cannot attest
that the results are meaningful or useful, but they seem change as I change
lwIP settings. They certainly change as I connect multiple netio clients!

Unfortunately, I cannot meet the requirements of a maintainer. So I am
posting this here due to the lack of an organized "unmaintained" section of
the download area on savannah.

Thanks,
MD

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Tue 15 Dec 2009 11:02:01 PM GMT Name: netio.c Size: 10kB By:
m_dittrich

<http://savannah.nongnu.org/patch/download.php?file_id=19278>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/patch/?7026>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-15T05:26:32Z

Follow-up Comment #8, bug #28288 (project lwip):

The only think I don't like in data after FIN
it is that we have ooseq queue in inconsistent state.

Simon, what do you mean under limit?
Stopping of data receive after some seqno?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-15T05:11:59Z

Follow-up Comment #14, bug #28241 (project lwip):

2nd patch for processing oos queue after receiving in-sequence segment

(Now in-sequence segment doesn't delete segments from oos queue)

(file #19272)
_______________________________________________________

Additional Item Attachment:

File name: oos_ins2.patch Size:3 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[task #9989] Limit data on ooseq queue

2009-12-15T03:36:43Z

URL:
<http://savannah.nongnu.org/task/?9989>

Summary: Limit data on ooseq queue
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: goldsimon
Submitted on: Di 15 Dez 2009 11:36:42 GMT
Category: None
Should Start On: Di 15 Dez 2009 00:00:00 GMT
Should be Finished on: Di 15 Dez 2009 00:00:00 GMT
Priority: 5 - Normal
Status: None
Privacy: Public
Percent Complete: 0%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: 1.4.0
Effort: 0.00

_______________________________________________________

Details:

Should be implemented in the same way as for sending (both limiting bytes and
number of pbufs)

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/task/?9989>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-15T01:25:28Z

Follow-up Comment #7, bug #28288 (project lwip):

limit on data on ooseq queue: sounds like a good feature for 1.4.0

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-15T00:07:56Z

Follow-up Comment #6, bug #28288 (project lwip):

I don't know if I would see that as an exploit: as Oleg said, it might lead
to the application seeing more data than it should, but nothing more.

Speaking of exploits, I don't think there a limit on the data on the ooseq
queue, maybe we should have a limit here as we do on sending
(send-queue/send-buf)...?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T23:56:13Z

Follow-up Comment #5, bug #28288 (project lwip):

OK, this would be a peer's bug. But would it be an exploit in lwip?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T08:19:33Z

Follow-up Comment #4, bug #28288 (project lwip):

> If we get two FINs at different sequence numbers we should
> definitely reset the connection so that the application at the
> other end might be made aware that there has been a problem and
> some data are not delivered.

Hm, that can happen in two cases:
a) Out-of-sequence, this case is quite easy to check, as we have both
segments to compare
b) In-sequence (i.e. the second FIN arrives in a closed state), this case is
not that easy to check as we would have to remember the seqno of the first FIN
to know it isn't a retransmission.

What do other stacks do about this? What do RFCs (or the requested comments,
if any) say about this?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T07:04:56Z

Follow-up Comment #3, bug #28288 (project lwip):

If we get two FINs at different sequence numbers we should definitely reset
the connection so that the application at the other end might be made aware
that there has been a problem and some data are not delivered. I agree this
is low priority, but is definitely something we could improve our handling,
even if it is the other end at fault.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T04:28:19Z

Follow-up Comment #2, bug #28288 (project lwip):

In current implementation as I can see data after FIN from oos queue will be
transfered to the application too if (pcb->ooseq->tcphdr->seqno ==
pcb->rcv_nxt).

It is bad mostly from debug position.
If we make some validation code for oos queue,
it could be two or more FIN segments on the oos queue or some data after
FIN.

I agree that it is not high priority task.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T03:56:12Z

Follow-up Comment #1, bug #28288 (project lwip):

First of all, correct me if I'm wrong, but I guess the only impact will be
wasted memory: once the segments are dequeued, they will be removed after FIN
is processed.

Second, I wouldn't spend too much time on this as it's clearly a bug in the
remote side's TCP implementation.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28288] Data after FIN in oos queue

2009-12-14T02:59:35Z

URL:
<http://savannah.nongnu.org/bugs/?28288>

Summary: Data after FIN in oos queue
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: olegreen
Submitted on: Mon 14 Dec 2009 10:59:34 AM GMT
Category: TCP
Severity: 3 - Normal
Item Group: Faulty Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: CVS Head

_______________________________________________________

Details:

Kieran in another thread (#28241) noticed that data after FIN doesn't have
special processing.

Now, if we receive segment with FIN flag, all data after FIN will be
rejected. It is OK.
But if we receive data after FIN packet already being in oos queue, they will
be queued too. It looks not quite good.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28288>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T05:15:30Z

Follow-up Comment #13, bug #28241 (project lwip):

Oh, that makes sense... in that case, the check should be included or we lose
the FIN - it might be retransmitted, but that's inefficient.

In any case: the current code doesn't have this problem. I'd still check this
in now, I've also locally adjusted the tests to verify it works.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T03:18:34Z

Follow-up Comment #12, bug #28241 (project lwip):

Ahh, now I understand. The length being used in the comparison (cseg->len)
is the payload length, not the sequence length, and so does not include any
FIN bits.

Oleg is right, we do therefore need to check whether there is a FIN byte in
the old packet before discarding it, and move that byte to the new packet if
the new packet does not also have a FIN.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T03:03:28Z

Follow-up Comment #11, bug #28241 (project lwip):

It is another question, what should we do when we have data behind the FIN,
but I mean here length of data

....45 - length of data 2 + FIN flag
...345 - length of data 3, but without FIN flag

tcp length of both packets is 3,
but seqno of 1st is 4 and 2nd is 3.

In this case we doesn't have contradiction.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T02:52:12Z

Follow-up Comment #10, bug #28241 (project lwip):

The other end is wrong and we can do what we like. Seqno 5 in the old packet
was a FIN, seqno 5 in the new packet is not a FIN. Which is correct? We
should probably reset the connection in this case.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T02:45:35Z

Follow-up Comment #9, bug #28241 (project lwip):

May be I have made not correct description

old -
seqno = 4
len = 2
flag = FIN

new -
seqno = 3
len = 3

result -
seqno = 3
len = 3
flag = FIN

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T02:36:30Z

Follow-up Comment #8, bug #28241 (project lwip):

The FIN uses a byte of sequence space, so if two packets finish on the same
sequence byte and one has a FIN and the other does not, that is wrong. I'm
happy with the change as Simon has made it.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-11T02:30:33Z

Follow-up Comment #7, bug #28241 (project lwip):

You are right in 4th comment.
It should be
TCPH_FLAGS_SET(cseg->tcphdr, TCPH_FLAGS(cseg->tcphdr) | TCP_FIN);

All cases are not covered with 1st line
if (TCPH_FLAGS(cseg->tcphdr) & TCP_FIN) {

This is neccesary for case when old segment has FIN flag but
new one - not.

e.g.
old - (4-5)FIN
new - (3-5)
result (3-5)FIN

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-10T09:37:49Z

Follow-up Comment #6, bug #28241 (project lwip):

After all, the extra FIN check is not at all necessary, since that case
should already be covered by the first line in tcp_oos_insert_segment():

if (TCPH_FLAGS(cseg->tcphdr) & TCP_FIN) {

I've extended the ooseq unit test and it shows that the suggested patch
works: data is delivered in correct order and the number of segments on ooseq
is sometimes smaller than without the patch.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #27858] PPP: missing call to netif_set_down()

2009-12-10T07:58:31Z

Update of bug #27858 (project lwip):

Open/Closed: Open => Closed

_______________________________________________________

Follow-up Comment #3:

Moved the problem from comment #2 to bug #28248.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?27858>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28248] netif_remove doesn't call netif callback

2009-12-10T07:58:04Z

URL:
<http://savannah.nongnu.org/bugs/?28248>

Summary: netif_remove doesn't call netif callback
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: goldsimon
Submitted on: Do 10 Dez 2009 15:58:03 GMT
Category: None
Severity: 3 - Normal
Item Group: Faulty Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: 1.3.1

_______________________________________________________

Details:

Without the callback, a callback-driven application will think the netif is
still active and up.

netif_remove() should possible at least call netif_set_down(). That makes
sure the user application is at least noticed of the fact that the netif isn't
up any more.

Adding a 'reason' argument to the callback would be best, as we couuld than
indicate that the netif is about to be removed. However, that would mean
breaking backwards compatibility.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28248>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-10T07:51:09Z

Follow-up Comment #5, bug #28241 (project lwip):

Anyway, I would have expected it to work without the extra check for the FIN
flag as that should already be covered by comparing the sequence numbers.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-10T06:27:53Z

Follow-up Comment #4, bug #28241 (project lwip):

That's true, I would have expected somthing like:
TCPH_FLAGS_SET(cseg->tcphdr, TCPH_FLAGS(cseg->tcphdr) | TCP_FIN);

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-10T02:46:25Z

Follow-up Comment #3, bug #28241 (project lwip):

I can see what you mean with the GT -> GEQ change, but I don't understand
that FIN change:

+ /* cseg with FIN already processed */
+ if (TCPH_FLAGS(next->mpTcpHdr) & TCP_FIN) {
+ TCPH_FLAGS_SET(cseg->tcphdr, TCPH_FLAGS(cseg->tcphdr) & ~TCP_FIN);
+ }

This reads to me as:
if (old packet has FIN set) {
remove FIN from new packet's flags;
}

Can you explain why you'd want to do that?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-10T02:04:26Z

Follow-up Comment #2, bug #28241 (project lwip):

Suppuse we have rcv_nxt==0

1st fragment
seqno=2
len=2
(2-3)
It is queued into oos.

2nd fragment
seqno=1
len=3
(1-3)

Without change we have on oos queue two fragments
(1-1)(2-3)
with change only
(1-3)

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-09T11:36:11Z

Follow-up Comment #1, bug #28241 (project lwip):

> In function tcp_oos_insert_segment()
> some segments covered with new segment are deleted.

I thought that was what we wanted to do with our last changes? Can you go
into detail a bit more on what's bad here?

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28241] oos processing

2009-12-09T07:36:49Z

URL:
<http://savannah.nongnu.org/bugs/?28241>

Summary: oos processing
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: olegreen
Submitted on: Wed 09 Dec 2009 03:36:48 PM GMT
Category: TCP
Severity: 3 - Normal
Item Group: Change Request
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release:
lwIP version: CVS Head

_______________________________________________________

Details:

In function tcp_oos_insert_segment()
some segments covered with new segment are deleted.
It would be better instead of

while (next &&
TCP_SEQ_GT((seqno + cseg->len),
(next->tcphdr->seqno + next->len))) {
struct tcp_seg *old_seg = next;
next = next->next;
tcp_seg_free(old_seg);
}

write

while (next &&
- TCP_SEQ_GT((seqno + cseg->len),
+ TCP_SEQ_GEQ((seqno + cseg->len),
(next->tcphdr->seqno + next->len))) {
struct tcp_seg *old_seg = next;
next = next->next;
tcp_seg_free(old_seg);
}

or if we don't want to lose FIN flag

while (next &&
- TCP_SEQ_GT((seqno + cseg->len),
+ TCP_SEQ_GEQ((seqno + cseg->len),
(next->tcphdr->seqno + next->len))) {
+ /* cseg with FIN already processed */
+ if (TCPH_FLAGS(next->mpTcpHdr) & TCP_FIN) {
+ TCPH_FLAGS_SET(cseg->tcphdr, TCPH_FLAGS(cseg->tcphdr) & ~TCP_FIN);
+ }
struct tcp_seg *old_seg = next;
next = next->next;
tcp_seg_free(old_seg);
}

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Wed 09 Dec 2009 03:36:48 PM GMT Name: oos_ins.patch Size: 790B By:
olegreen

<http://savannah.nongnu.org/bugs/download.php?file_id=19226>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28241>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel

[bug #28225] 2nd tcp_connect error after close of pcb

2009-12-08T05:40:26Z

Update of bug #28225 (project lwip):

Status: None => Invalid
Open/Closed: Open => Closed

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28225>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
lwip-devel mailing list
lwip-devel@...
http://lists.nongnu.org/mailman/listinfo/lwip-devel