search

troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
197 stars 87 forks source link

Add fragmentation support for unicast message that are larger than the #27

Closed michfine closed 9 years ago

michfine commented 10 years ago

MTU of the output interface.

Assuming all ethernet interfaces, the encap added to register messages will cause the size of the packet to exceed the MTU of the outgoing interface if the original packet is max size. Since the socket has option IP_HDRINCL set, the kernel will not fragment the IP packet. So pimd must do it.

troglobit commented 10 years ago

Great stuff! :-)

I'll try it out as soon as possible, and might do some minor code cleanup before I push it to master, but it looks great. Have you tried really small MTU's, like 576 with this patch? I'm just curious if the IP stack on the other side really can reassemble the fragments when there are >2 of them coming in from pimd.

michfine commented 10 years ago

Please use/modify the code anyway you see fit.

All I tested was max size ethernet and a few bytes less on the input side to trigger the fragmentation. I would be surprised if the receiving IP stack could not handle >2 fragments coming in. Those should be well tested for this case.

troglobit commented 10 years ago

Thanks, I'm changing the attribution to go to Michael Fine though, that's what I could dig up on the Internet. Hope that's OK?

I was just a bit worried when you get a full-size multicast packet in and want to egress it encapsulated on a min MTU (576) size Ethernet interface, then you'd need more than two fragments, so you probably need a bit more logic. But don't worry, I'll look into that.

Thanks again for the patch! I'll close this pull-request as soon as I've merged and fine tuned the code to my liking. I might look into refactoring the fragmentation code so I can reuse it for fragmenting BSR frames as well, but not for the upcoming 2.2.0 relese. Just FYI.

michfine commented 10 years ago

I see what you mean about >2 fragments. The scenario you are suggesting should work too (but I did not test it) since send_raw_ip() calls itself recursively with each half. So a 1500B input pkt will split in half and then each half split again to get a 4 fragments under 576B. This may be non-optimal since if you knew the MTU you could get away with 3 fragments instead.

Updated my profile with name and email so you don't have to guess :-)

troglobit commented 10 years ago

Whipped up 49c4e9c as a follow-up commit on a merge branch. Completely untested brain barf ... it compiles, but I may very well have fsck'ed length calculations. Will test later this week, just pushing for your viewing pleasure, in case you're interested.

troglobit commented 9 years ago

Merged, finally ... failed to get my own optimized version to work. It's in there as well, but ifdef:ed out. I also pushed an attempt to add PMTU discovery as a separate branch.

I've tested it quite thoroughly in my limited setup and will now resume testing before releasing a new official version with all the other fixes.

Fixed in commit 5bf1139.