Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • ocserv ocserv
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 79
    • Issues 79
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenConnect VPN projectsOpenConnect VPN projects
  • ocservocserv
  • Issues
  • #322
Closed
Open
Issue created Jul 13, 2020 by Alan Jowett@Alan_JowettDeveloper

rate-limit-ms with adaptive limiting doesn't work as expected on Ubuntu 20.04 and later

rate-limit-ms with adaptive limiting doesn't work as expected on Ubuntu 20.04 and later

The logic for the rate limiting change used 50% queue depth as a good high water mark to engage rate limiting, but it looks like between Linux kernel 4.18 and Linux kernel 5.4 the maximum queue depth was raised to 1024 (from 128).

This results on ocserv-sm getting flooded and connections getting dropped during TLS signing.

https://gitlab.com/openconnect/ocserv/-/blob/master/src/main.c#L1263

Edited Oct 05, 2020 by Nikos Mavrogiannopoulos
Assignee
Assign to
Time tracking