Socket error: TCP_MD5SIG: Cannot allocate memory

[Ondrej Zajicek]

On Tue, Aug 25, 2015 at 03:45:47PM -0500, Michael Vallaly wrote:
> 
> For context on my end; this issue was experienced on physical hardware
> (64bit) with Intel 1Gbit NICs (no offloading).
> 
> We only noticed this after some length of time, (> 180 days) during
> which we likely had < 40 BGP session flaps on our end via Bird. 
> 
> optmem_max: Maximum ancillary buffer size allowed per socket. Ancillary
> data is a sequence of struct cmsghdr structures with appended data. The
> default size is 10240 bytes.
> 
> According to Eric Dumazet back in 2012 [1]: 
> 
> <snip>
> There is no limit on number of MD5 keys an application can attach to a
> tcp socket.
> 
> This patch adds a per tcp socket limit based
> on /proc/sys/net/core/optmem_max
> 
> With current default optmem_max values, this allows about 150 keys on
> 64bit arches, and 88 keys on 32bit arches.
> </snip>
> 
> Maybe we are getting multiple/duplicate MD5 keys assigned to the TCP
> session somehow?  

Thanks for the info about the limit.

Note that the incoming (listening) TCP socket (AFAIK) has to be
configured with all the keys, so it is possible to hit the limit
during regular operation without any leaks.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20150825/92412d9b/attachment.asc>