transmission-daemon: UDP Failed to set receive / send buffer

6,784

Solution 1

Following this old article helped. Let me mention the claimed solution first:

  1. Open this text file as root, be aware it is one of those important system files:

    /etc/sysctl.conf
    

    An alternative option is to create a new config file to hold the parameters to override, but this question is not per se about how else to make your config, and hence we solve this issue directly.

  2. I added these two lines since I have enough memory; if you are for instance on an embedded system, you might want to reconsider applying these lines (we're setting 16 MiB for the receive buffer and 4 MiB for send buffer), I can't tell the actual running memory requirements yet:

    net.core.rmem_max = 16777216
    net.core.wmem_max = 4194304
    
  3. If you decided to add those lines above, you can re-read the config with:

    sysctl -p
    

There is no need for a reboot to take effect.


Now, let me quote that web page on this:

This message tries to tell us, that for some reason, Transmission would like to have 4 Megabytes of receive buffer and 1 Megabyte send buffer for its UDP socket. It turns out that the support for µTP, the µTorrent transport protocol, is implemented using a single socket.

By tuning the two variables, higher throughput can be achieved more easily using µTP.


Since we're using a single UDP socket to implement multiple µTP sockets, and since we're not always timely in servicing an incoming UDP packet, it's important to use a large receive buffer. The send buffer is probably less critical, we increase it nonetheless.

Solution 2

The answered solution works fine, but in systemd you must write these lines in:

/etc/sysctl.d/<anyname>.conf

And then, execute:

# sysctl --system
Share:
6,784

Related videos on Youtube

kabirbaidhya
Author by

kabirbaidhya

Updated on September 18, 2022

Comments

  • kabirbaidhya
    kabirbaidhya almost 2 years

    Our app lies on SAML SSO 2.0 for login. We just got this error in the saml response status from the IdP and I'm not sure what this actually means and what needs to be done in order to get it fixed.

    The Identity Provider our clients are using is Ping Federate and we have already configured SSO settings successfully between their IdP and our app long before. No issue so far and now suddenly we're getting this Authentication Failed error out of nowhere while the user tries to login.

    Can some one clarify what this actually means?

    There hasn't been any change on the app (Service Provider) side on the SSO recently so does this mean the issue is on the IdP end?

    Let me know. Thanks.

    Here's the saml response (signature & client identifers changed)

    <samlp:Response Version="2.0" ID="hbj8oC64PBip6qPoM9jrpS1OCfI" IssueInstant="2018-08-28T15:16:43.824Z" InResponseTo="_9a55c2b67dcd76cee19828ff496206a61b4c51237c" Destination="https://exampleapp.com/saml/login/callback" 
        xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">foobar</saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#hbj8oC64PBip6qPoM9jrpS1OCfI">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>rVffko3J5H6izfHOi4m0r4vtLHVLKbZqX6VmhYW7wIw=</ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
    CuLJsdfsdfxc9C81bcFYtahXu98eS2izTwXUp7Hi592Qh5/b/bNgyaDjV1l3r0R4dcx+wP6IDPnqIxpk7h BezfbD8bqm1cBC3AFgLh0b9RByGto2qpxJv1HP1sMkAk03x6JPq7ec6fAFJdrkeKMq5dyl8eodjy lNu0Ql3qY3k1gIerTToQZULkAZp8WLIekPpaOKzvXotzZx3dLoprn/XA+BKZZgR8WP7jZ4t/3jJF YF1l2WjaSWOJgoz8PIjwPJZ7mvqjvYbY3u726vra3x+c0wzp+qlNZNbUzqg2CQ07RICMgHbnLKMA /PiF81helnjOCOdOTIrFmkxoiwvYz3Th6/1sLA==
            </ds:SignatureValue>
        </ds:Signature>
        <samlp:Status>
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
                <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/>
            </samlp:StatusCode>
            <samlp:StatusMessage>Authentication Failed</samlp:StatusMessage>
            <samlp:StatusDetail>
                <Cause>org.sourceid.websso.profiles.idp.FailedAuthnSsoException</Cause>
            </samlp:StatusDetail>
        </samlp:Status>
    </samlp:Response>
    
    • Wiktor Zychla
      Wiktor Zychla almost 6 years
      status:Responder suggests an issue at the IdP side. Check logs and perform common maintenance, it could be something as trivial as the database went offline etc.
  • Admin
    Admin about 2 years
    old article link is dead