GNU GRUB - Bugs: bug #40363, TFTP: Files bigger than 63 MB...
You are not allowed to post comments on this tracker with your current authentication level.
bug #40363: TFTP: Files bigger than 63 MB generate "error: timeout reading `/boot/initrd'."
Submitter: | Bernhard Übelacker <bernhardu> | ||
Submitted: | Thu 24 Oct 2013 03:10:34 PM UTC | ||
Category: | Network | Severity: | Major |
Priority: | 5 - Normal | Item Group: | Software Error |
Status: | Fixed | Privacy: | Public |
Assigned to: | None | Originator Name: | |
Open/Closed: | Closed | Release: | Bazaar - trunk |
Release: | Reproducibility: | Every Time | |
Planned Release: | None |
Jump to the original submission
Sun 27 Oct 2013 06:17:09 PM UTC, comment #6: |
Vladimir Serbinenko <phcoder> |
Sat 26 Oct 2013 01:18:54 PM UTC, comment #5: When the block number gets over 0xffff the last
|
Bernhard Übelacker <bernhardu> |
Sat 26 Oct 2013 02:17:38 AM UTC, comment #4: If packet for 10000 reaches GRUB before packet FFFF then packet 10000 would be considered to come before FFFF and will be processed as delayed retransmission and GRUB will discard it but (re)send ack for 0000, then it will take packet for FFFF and process it correctly, send ack for FFFF. Then server will see ack for FFFF and 0000 which it will interpret as 10000 and go on with sending 10001 and GRUB will wait for 10000 which it will never receive. The reason why it worked for you is combination of #40293 and your network being perfect (no losses or duplicates). The full problem is more complex than casting few types. In general there is no solution. Imagine that packet for 00000 got duplicate in network and delayed and arrives at the same time as FFFF and before 10000. Then there is no way to distinguish this situation from packet 10000 arriving. You can handle it only by introducing some assumptions. The most sensible is that you never have packets more than 0x8000 apart. Then (grub_int16_t)(a-b) would give correct compare. Please try attached patch. |
Vladimir Serbinenko <phcoder> |
Sat 26 Oct 2013 12:52:28 AM UTC, comment #3: Then if the datatype change is removed the sorting in the
|
Bernhard Übelacker <bernhardu> |
Fri 25 Oct 2013 06:03:28 PM UTC, comment #2: This patch worked only by chance that the priority queue was empty at the moment of wraparound. |
Vladimir Serbinenko <phcoder> |
Thu 24 Oct 2013 03:14:35 PM UTC, comment #1: Patch which handles the overflow attached. |
Bernhard Übelacker <bernhardu> |
Thu 24 Oct 2013 03:10:34 PM UTC, original submission:
When attempting to load a file with a size bigger
|
Bernhard Übelacker <bernhardu> |
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 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2013-10-27 | phcoder | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2013-10-26 | bernhardu | Attached File | - | Added 0001-TFTP-Handle-overflow-in-blocknumber-fixes-bug-40363-try-4.patch, #29478 | |
2013-10-26 | phcoder | Attached File | - | Added tftp.diff, #29471 | |
2013-10-26 | bernhardu | Attached File | - | Added 0001-TFTP-Handle-overflow-in-blocknumber-fixes-bug-40363-try-2.patch, #29470 | |
2013-10-24 | bernhardu | Carbon-Copy | Removed bernhardu | - | |
2013-10-24 | bernhardu | Attached File | - | Added 0001-TFTP-Handle-overflow-in-blocknumber-fixes-bug-40363.patch, #29460 | |
2013-10-24 | bernhardu | Carbon-Copy | - | Added bernhardu |
Powered by Savane 3.13-3230.
Corresponding source code
comitted modification of my patch.