Closed michfine closed 9 years ago
Replicated the problem here now. Will look into it before the upcoming 2.2.0 release!
I have implemented a fix for this and can send it to you in a few days with a pull request if you would like.
That's awesome! :)
I've just started looking into it, investigating how to do PMTU discovery on operating systems other than Linux. I want to support the three main BSD's. How do you read the MTU, just looking at the outbound interface, or do you use MSG_ERRQUEUE on the socket to readout the discovered MTU? Curious!!
I didn't delve into figuring out the PMTU which would be the right approach. What I did was, on getting EMSGSIZE, split the pkt buffer into two halves and recursively send each half.
On 1/10/2014 6:18 AM, Joachim Nilsson wrote:
That's awesome! :)
I've just started looking into it, investigating how to do PMTU discovery on operating systems other than Linux. I want to support the three main BSD's. How do you read the MTU, just looking at the outbound interface, or do you use MSG_ERRQUEUE on the socket to readout the discovered MTU? Curious!!
— Reply to this email directly or view it on GitHub https://github.com/troglobit/pimd/issues/25#issuecomment-32030308.
Ah, well that's probably both portable and good enough for my next release ...
Fixed as of 5bf1139, added my own non-working version ifdef'ed out.
I have encountered a problem with register messages and am wondering if anyone else has seen the same thing or has any insights.
In my scenario, the problem occurs when the DR receives a full-size frame from a new source and encapsulates it in a register msg for sending to the RP. Due to the encap, the outgoing frame exceeds the MTU of the outgoing interface and the kernel returns error on the sendto() sys call with error EMSGSIZE. It seems that pimd needs to fragment the register msg whenever it exceeds the MTU of the outgoing interface or (better yet) when it exceeds the path MTU to the RP.