On 2012-02-28 23:18, Stefan Weil wrote:
> Am 17.02.2012 16:45, schrieb Jan Kiszka:
>> In case we requeued a packet that was the head of a longer session
>> queue, we failed to restore this ordering. Also, we did not properly
>> deal with changes to Slirp::next_m.
>>
>> Instead of a cumbersome roll
On 2012-02-28 23:52, Jan Kiszka wrote:
> On 2012-02-28 23:18, Stefan Weil wrote:
>> Am 17.02.2012 16:45, schrieb Jan Kiszka:
>>> In case we requeued a packet that was the head of a longer session
>>> queue, we failed to restore this ordering. Also, we did not properly
>>> deal with changes to Slirp
On 2012-02-28 23:18, Stefan Weil wrote:
> Am 17.02.2012 16:45, schrieb Jan Kiszka:
>> In case we requeued a packet that was the head of a longer session
>> queue, we failed to restore this ordering. Also, we did not properly
>> deal with changes to Slirp::next_m.
>>
>> Instead of a cumbersome roll
Am 17.02.2012 16:45, schrieb Jan Kiszka:
In case we requeued a packet that was the head of a longer session
queue, we failed to restore this ordering. Also, we did not properly
deal with changes to Slirp::next_m.
Instead of a cumbersome roll back, this fix simply avoids any changes
until we know
In case we requeued a packet that was the head of a longer session
queue, we failed to restore this ordering. Also, we did not properly
deal with changes to Slirp::next_m.
Instead of a cumbersome roll back, this fix simply avoids any changes
until we know if the packet was actually sent. Both fixe
