Seems there's a bug in Buffer::Iterator::ReadNtohU16

[Xin Yue]

Hi, all

I am reading ns3 code. But I am confused by these three functions: Buffer::Iterator::ReadNtohU16(), Buffer::Iterator::ReadNtohU32(), and Buffer::Iterator::ReadNtohU64()

Here's problem. To make it short and obvious, just consider these two cases.

1). When m_current > m_zeroEnd

ReadNtohU16() and ReadNtohU32() will read from m_data[m_current]. But ReadNtohU64() will invoke eight ReadU8() which in turn will invoke PeekU8(). But PeekU8() will read from m_data[m_current - (m_zeroEnd - m_zeroStart)]. Because the zero area bytes are usually used to represent the application payload, and the state invariant of m_start <= m_zeroStart <= m_zeroEnd <= m_end, they should be reading from different location.

2) When m_zeroStart < m_current < m_zeroEnd

ReadNtohU16() and ReadNtohU32() will increase m_current too much. Take ReadNtohU16() as a example. It invokes SlowReadNtohU16() and then increase m_current by 2. But SlowReadNtohU16() invokes ReadU8() twice, which in turn invokes PeekU8() and increases m_current by 1. Eventually, ReadNtohU16() will increase m_current by 4 instead of 2.

I searched this problem on google and in the bugzilla database, but failed to find related information.

This looks like a bug, but it doesn't hurt too much. Because there is few manipulation on application payload or footer during the packet processing.

Or perhaps there's something I just omitted? Any comment will be appreciated.

[Tommaso Pecorella]

Hi,

thanks for the heads-up, but I can say to sleep tight (at least in this case).

Taking ReadNtohU16 as an example, it is true that it can use SlowReadNtohU16, but when it does, it doesn't increase the m_current value (SlowReadNtohU16 did it already).

If you check, all the "Slow" versions invocations are in a "return" statement, so the rest of the function is skipped.

Hope this helps,

T.

[Xin Yue]

Oops. You are absolutely right about case 2). I guess I have to make an appointment with my eye doctor. LoL

Actually, case 2) just bumped into my head when I was describing case 1). Better make a double check about this kind of idea next time.

Any thought about case 1)?

--

"Across the Great Wall we can reach every corner in the world"

-- Since 1987

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/vvzH8TApe6U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Tommaso Pecorella]

Hi,

Just four words: you may be right.

We may need a testcase tho.

Cheers,

T.