From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CBBDC43603 for ; Fri, 13 Dec 2019 01:58:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 309102173E for ; Fri, 13 Dec 2019 01:58:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="PHrstTQb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731736AbfLMB61 (ORCPT ); Thu, 12 Dec 2019 20:58:27 -0500 Received: from m228-4.mailgun.net ([159.135.228.4]:51142 "EHLO m228-4.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727084AbfLMB61 (ORCPT ); Thu, 12 Dec 2019 20:58:27 -0500 X-Greylist: delayed 302 seconds by postgrey-1.27 at vger.kernel.org; Thu, 12 Dec 2019 20:58:26 EST DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1576202306; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=NohU4Uw/amJOHwUBaNTLQqjMskzme9uSsAjxcO9oFqg=; b=PHrstTQbfI3ZozgVsE7LyKGeK/NQitijUPpR1H1/IN+sQZTCmoD2wDLuNKAqxewkCsGvCjLD 0CZ6X/ni+5vw/B56liQl4Ap4es7e62U3SRce99wJHh2jHQw+Wrn/P3XDPOY7PVxxkqG6Ta+6 oR2dYYkJsAfOI/ODBY4y215TIiI= X-Mailgun-Sending-Ip: 159.135.228.4 X-Mailgun-Sid: WyJiZjI2MiIsICJuZXRkZXZAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5df2ef10.7fae3c14b068-smtp-out-n01; Fri, 13 Dec 2019 01:53:20 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 91EACC447A0; Fri, 13 Dec 2019 01:53:20 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: subashab) by smtp.codeaurora.org (Postfix) with ESMTPSA id E9A9AC433CB; Fri, 13 Dec 2019 01:53:19 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 12 Dec 2019 18:53:19 -0700 From: subashab@codeaurora.org To: Lorenzo Colitti , Jakub Kicinski Cc: =?UTF-8?Q?Maciej_=C5=BBenczykowski?= , "David S . Miller" , Linux Network Development Mailing List , Marcelo Ricardo Leitner , Sean Tranchetti , Eric Dumazet , Linux SCTP Subject: Re: [PATCH v2] net: introduce ip_local_unbindable_ports sysctl In-Reply-To: References: <20191209224530.156283-1-zenczykowski@gmail.com> <20191209154216.7e19e0c0@cakuba.netronome.com> <20191209161835.7c455fc0@cakuba.netronome.com> <20191210093111.7f1ad05d@cakuba.netronome.com> <20191212164749.4e4c8a4c@cakuba.netronome.com> Message-ID: <2e7ceea704ee71383d3f19d1de63dff4@codeaurora.org> X-Sender: subashab@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2019-12-12 17:57, Lorenzo Colitti wrote: > On Fri, Dec 13, 2019 at 9:47 AM Jakub Kicinski > wrote: >> How are the ports which get reserved communicated between the baseband >> and the AP? Is this part of the standard? Is the driver that talks to >> the base band in the user space and it knows which ports to reserve >> statically? Or does the modem dynamically request ports to >> reserve/inform the host of ports in use? > > I'm not an expert in that part of the system, but my understanding is > that the primary way this is used is to pre-allocate a block of ports > to be used by the modem on boot, before other applications can bind to > ports. Subash, do you have more details? AFAIK these ports are randomly picked and not from a standard. Userspace gets this information through qrtr during boot. Atleast in our case, there cannot be any existing user of these ports since these ports are blocked prior to mobile connection establishment. We could call SOCK_DIAG_DESTROY on these ports from userspace as a precaution as applications would gracefully handle the socket errors.