This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
laforge gerrit-no-reply at lists.osmocom.orglaforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/19793 ) Change subject: abis_rsl: prioritize emergency calls over regular calls ...................................................................... Patch Set 2: (1 comment) https://gerrit.osmocom.org/c/osmo-bsc/+/19793/2/src/osmo-bsc/abis_rsl.c File src/osmo-bsc/abis_rsl.c: https://gerrit.osmocom.org/c/osmo-bsc/+/19793/2/src/osmo-bsc/abis_rsl.c@1406 PS2, Line 1406: l how do we protect against Denial of Service here? I think we unconditioally append every channel request to the queue, growing it to extreme lengths. Think of somebody running a RACH DoS attack. If I read the code correctly: With the previous code in master (without a queue), I think there is stil la somewhat fair chance that a valid RACH request from a user gets a channel, as valid and invalid requests compete. With an indefinitely long queue, all of the hundreds to thousands of fake RACH requests make a very long queue, and until that queue has been fully processed, no new real RACH request has any chance of succeeding. So I think this patch would create a "DoS amplification", as it makes the situation even worse than it already is under DoS. If the queue grows beyond a certain length, the phone will have given up waiting for an IMMEDIATE ASSIGN (or IMMEDIATE ASSIGN REJECT) by the time we process the entry in the queue. So I think the entries must have a timeout that correlates with the timeout on the MS side, which in turn I believe is configured by the RACH control parameters in the system information. What about: When we dequeue the entries, we first check if the timeout already has expired. If it has, discard that queue entry and move to the next? -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/19793 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: If8651265928797dbda9f528b544931dcfa4a0b36 Gerrit-Change-Number: 19793 Gerrit-PatchSet: 2 Gerrit-Owner: dexter <pmaier at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de> Gerrit-CC: laforge <laforge at osmocom.org> Gerrit-Comment-Date: Thu, 03 Sep 2020 10:31:20 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200903/881c8ea6/attachment.htm>