lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] Bug in snd_buf calculation


From: Jan Ulvesten
Subject: RE: [lwip-users] Bug in snd_buf calculation
Date: Mon, 6 Feb 2006 10:07:20 +0100

I posted an earlier bug report related this topic. 

snd_buf may be "lost" due to this correction. The alignment code takes
one byte of extra space out of the send buffer if the content is odd.
The idea was that the ack routine should correct this.  It works fine as
long as every single packets is ackd. If the ack routine acks two or
more packets it may actually not give the extra byte back (if acking an
even number of bytes when two odd byte packets has been sent).

Jan Ulvesten
SICOM  AS

-----Original Message-----
From: Curt McDowell [mailto:address@hidden 
Sent: 4. februar 2006 02:01
To: 'Mailing list for lwIP users'
Subject: [lwip-users] Bug in snd_buf calculation

Hi,

A code change was made in two files almost exactly 1 year ago:

        tcp_out.c revision 1.43
        tcp_in.c revision 1.54
        Applied fix patch for bug #2679.
        http://savannah.nongnu.org/bugs/?func=detailitem&item_id=2679

I think the idea was to fix a checksum alignment problem.  However, the
fix is not correct and should be removed (now that the
checksum alignment problem has been addressed in the checksum routine).
In tcp_out.c, the change was:

        <<<<<
          pcb->snd_buf -= len;
        =====
          /* FIX: Data split over odd boundaries */
          pcb->snd_buf -= ((len+1) & ~0x1); /* Even the send buffer */
        >>>>>

If snd_buf becomes an odd number (which is possible elsewhere in lwip),
and the application uses tcp_write() on that entire odd
amount, pcb->snd_buf underflows to 65535, crashing the application.

Regards,
Curt McDowell
Broadcom Corp.





_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users





reply via email to

[Prev in Thread] Current Thread [Next in Thread]