lwIP - A Lightweight TCP/IP stack - Bugs: bug #34427, In RAW/NO_SYS mode, tcp_output may...
You are not allowed to post comments on this tracker with your current authentication level.
bug #34427: In RAW/NO_SYS mode, tcp_output may send out large number of ARQ REQ if destination ARP entry has expired
Submitter: | Min Xu <maximalmin> | ||
Submitted: | Thu 29 Sep 2011 12:45:27 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Duplicate |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 1.4.0 |
Jump to the original submission
Sun 13 Nov 2011 04:15:08 PM UTC, comment #8: |
Simon Goldschmidt <goldsimon> |
Sat 29 Oct 2011 09:09:18 AM UTC, comment #7: I have split the patch in comment #5 for two bugs reports
|
Amir Shalem <amirshalem> |
Fri 28 Oct 2011 12:29:57 PM UTC, comment #6: The patch in comment #5 is a bit confusing. It seems to be addressing a number of different issues, and I'm not sure if it fixes the problem of this bug, which is specifically about sending large numbers of ARPs when the destination entry has expired.
|
Kieran Mansley <kieranm> |
Sat 22 Oct 2011 10:17:17 AM UTC, comment #5: I'm attaching a patch for this bug,
arp requests are sent only when there's a new timer, or on etharp_tmr
in case someone is sending lots of packets without the entry resolved,
|
Amir Shalem <amirshalem> |
Thu 29 Sep 2011 09:07:43 PM UTC, comment #4: Forgot the attachment |
Min Xu <maximalmin> |
Thu 29 Sep 2011 09:03:17 PM UTC, comment #3: I ran a test with arp queuing turned on (ETHARP_TRUST_IP_MAC = 0, ARP_QUEUEING = 1), it doesn't appear to resolve the issue of single vs multiple ARP. However, it does behave differently in that immediately after the ARP flood, the sequence is continuous from the last transmission by the DSP (before ARP flood, desktop relative-ACKd 10221, after ARP flood, DSP started transmit at 10221). BUT.. after a short while, the DSP jumped a bunch of sequence number (at packet 141 in the attached pcap file), skipping 17520 bytes (12 packets of 1460 byte payload)... I didn't observe this issue in the build where ARP QUEUING is turned off.
|
Min Xu <maximalmin> |
Thu 29 Sep 2011 08:23:52 PM UTC, comment #2: Just a note: winsock delays send() until an ARP request succeeds or times out (which it does in 3 seconds, it is not retransmitted).
|
Simon Goldschmidt <goldsimon> |
Thu 29 Sep 2011 06:03:22 AM UTC, comment #1: We should at least limit the number of ARP requests to 1 per second or so (I'll check the RFCs for a value), to prevent ARP flooding (a general problem, not only for TCP). Unfortunately, we only have a 5-second timer in etharp.c (which is too long for retransmissions, I guess), so we might need to decrease that timer.
|
Simon Goldschmidt <goldsimon> |
Thu 29 Sep 2011 12:45:27 AM UTC, original submission:
This is related to bug #34426. So the next two paragraphs are quoted from that bug report.
|
Min Xu <maximalmin> |
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-11-13 | goldsimon | Status | None | Duplicate | |
Open/Closed | Open | Closed | |||
2011-10-22 | amirshalem | Attached File | - | Added arp-queuing.patch, #24184 | |
2011-09-29 | maximalmin | Attached File | - | Added example-arp-queuing.pcap, #24051 |
Powered by Savane 3.13-f8d8.
Corresponding source code
I think it does (as comment #7 also says).
Closing this as Duplicate (see bug #34682 and bug #34681).
By not re-sending from the output function (when we already sent a request and are waiting for the response) but from the timer function, the number of requests doesn't depend on the number of packets sent but is predictable.