diff options
| author | Thomas Huth <thuth@linux.vnet.ibm.com> | 2011-09-27 11:20:38 +0200 |
|---|---|---|
| committer | Jan Kiszka <jan.kiszka@siemens.com> | 2011-09-28 13:11:30 +0200 |
| commit | 2b4404326598bec4cb954bfc54fc5e9740a51f7b (patch) | |
| tree | 39fb0d0b4dd9be56c125e389744da5b9bcc1fb10 | |
| parent | 8d06d69bc448301d27cab1405efba9d876dd39da (diff) | |
| download | qemu-2b4404326598bec4cb954bfc54fc5e9740a51f7b.zip qemu-2b4404326598bec4cb954bfc54fc5e9740a51f7b.tar.gz qemu-2b4404326598bec4cb954bfc54fc5e9740a51f7b.tar.bz2 | |
slirp: Fix packet expiration
The two new variables "arp_requested" and "expiration_date" in the mbuf
structure have been added after the variable-sized "m_dat_" array. The
variables have to be added before the m_dat_ array instead.
Without this patch, the expiration_date gets clobbered by code that
accesses the m_dat_ array.
I experienced this problem with the code in slirp/tftp.c: The
tftp_send_data() function created a new packet with the m_get()
function (which fills-in a default expiration_date value). Then the
TFTP code cleared the data section of the packet, which accidentially
also cleared the expiration_date. This zeroed expiration_date then
finally causes the packet to be discarded during if_start(), so that
TFTP packets were not transmitted anymore.
[Jan: added comment as suggested by Fabien ]
CC: Fabien Chouteau <chouteau@adacore.com>
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
| -rw-r--r-- | slirp/mbuf.h | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/slirp/mbuf.h b/slirp/mbuf.h index 55170e5..0708840 100644 --- a/slirp/mbuf.h +++ b/slirp/mbuf.h @@ -82,12 +82,13 @@ struct m_hdr { struct mbuf { struct m_hdr m_hdr; Slirp *slirp; + bool arp_requested; + uint64_t expiration_date; + /* start of dynamic buffer area, must be last element */ union M_dat { char m_dat_[1]; /* ANSI don't like 0 sized arrays */ char *m_ext_; } M_dat; - bool arp_requested; - uint64_t expiration_date; }; #define m_next m_hdr.mh_next |