[Serdev] SIP UDP / dont fragment issue

[Martin Koenig]

Hello Ben,

you are correct, of course. The problem originates from a Router on the 
way to the destination (Japan) that drops / does not reply with the 
correct ICMP destination unreachable.

Sorry for the disturbance,

regards,
Martin

Benjamin Black wrote:

> That's the kernel implementing TCP path MTU discovery.  The first hop  
> before the low MTU link should be sending back an ICMP message  
> (fragmentation required/DF set) that includes the MTU of the outgoing  
> link.  So, the problem is not really SER, which doesn't control  
> setting the DF bit, but the router in front of the slow link that  
> isn't sending back the ICMP messages needed for PMTUD to function (or  
> perhaps you are filtering them).
>
> Try disabling PMTUD (I forget if this is the proper way under current  
> Linux systems):
>
>     echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc
>
>
>
> Ben
>
> On May 28, 2005, at 5:22 PM, Martin Koenig wrote:
>
>> Hello,
>>
>>
>>> Martin Koenig wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> we are having issues piping SIP to asia via a low MTU transit  
>>>> point. The problem is that SER sets the "dont fragement" bit for  
>>>> outgoing messages, which will then be dropped at the low MTU  
>>>> transit because it may not fragment the too big packets.
>>>>
>>>> A quick search on the archive did not put up anything useful. Has  
>>>> anyone ever had similar problems?
>>>>
>>>
>>>
>>> I don't think that SER is responsible for that. Actually, if my  
>>> memory serves BSD sockets API doesn't provide any portable way for  
>>> the application to set DF flag. I suspect that either your  
>>> operating system does it, or the problem is elsewhere.
>>>
>>> Setting DF on UDP packets is stupid thing to do since UDP doesn't  
>>> have any path MTU discovery mechanism. Therefore, sending UDP with  
>>> DF is a very good way to shoot yourself in the foot.
>>>
>>
>> This System is RH9. I verified with tcpdump that outgoing UDP has  
>> dont fragment bit set. Argh.
>>
>> Is there anything that can be done about this issue except lowering  
>> the MTU of the corresponding NIC?
>>
>> Regards,
>> Martin
>>
>> _______________________________________________
>> Serdev mailing list
>> serdev at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serdev
>>
>>
>
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev