Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPv6 fragmentation fixes #289

Merged
merged 7 commits into from
May 30, 2017
Merged

Conversation

jukkar
Copy link
Member

@jukkar jukkar commented May 23, 2017

No description provided.

The previous default 60 seconds is way too long for our limited
amount of memory. It might be that the 5 sec is still too long
but that can be changed in the future.

Signed-off-by: Jukka Rissanen <[email protected]>
If the fragmented IPv6 packet was very large, we could run out
of resources. When that happened, we leaked the memory for the
pending fragments that were waiting reassembly.

Jira: ZEP-2166

Signed-off-by: Jukka Rissanen <[email protected]>
* in the packet. There cannot be any extensions after the normal or
* typical IP protocols
*/
switch (next) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not an if here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, why not :)

tbursztyka
tbursztyka previously approved these changes May 29, 2017
The IPv6 fragmentation was not working properly when the large
IPv6 packet was being sent. There is unit tests in next commit
that will test the IPv6 fragmentation sending.

Signed-off-by: Jukka Rissanen <[email protected]>
The cancellation of reassembly did not work as expected because
K_WORK_INITIALIZER() did not setup the timeout function properly.
So do the timer initialization at runtime instead.

Signed-off-by: Jukka Rissanen <[email protected]>
If the user really wants, it is possible to increase the
maximum size of the fragmented packet. According to RFC 2460
chapter 5, we do not need to accept larger than 1500 byte IPv6
packets, so the max pkt limit is set to 2. But if really needed
the limit can be raised by defining NET_IPV6_FRAGMENTS_MAX_PKT
to some new value. Currently there is no Kconfig option for
doing this as it is unlikely that this is needed.

Signed-off-by: Jukka Rissanen <[email protected]>
These tests make sure that the IPv6 fragments are build correctly
when a large IPv6 packet is being sent.

Signed-off-by: Jukka Rissanen <[email protected]>
Print also network buffers that are allocated by the IPv6
fragment handler. This is very useful in debugging.

Signed-off-by: Jukka Rissanen <[email protected]>
@jukkar
Copy link
Member Author

jukkar commented May 29, 2017

Changed the switch() to if() in patch 3.

@jukkar jukkar merged commit df38a21 into zephyrproject-rtos:master May 30, 2017
nagineni pushed a commit to nagineni/zephyr that referenced this pull request Nov 20, 2017
@jukkar jukkar deleted the ipv6-frag-fix branch June 21, 2018 06:38
parthitce pushed a commit to linumiz/zephyr that referenced this pull request Jun 21, 2023
bugfix: floating point representaion without fractional part
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants