lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f1b120d7-f74c-2ea7-0a4d-bc5cef0a9162@oracle.com>
Date:   Mon, 9 Jul 2018 20:26:44 +0800
From:   Ka-Cheong Poon <ka-cheong.poon@...cle.com>
To:     Santosh Shilimkar <santosh.shilimkar@...cle.com>
Cc:     Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        davem@...emloft.net, netdev@...r.kernel.org,
        rds-devel@....oracle.com
Subject: Re: [PATCH v2 net-next 1/3] rds: Changing IP address internal
 representation to struct in6_addr

On 07/07/2018 01:26 AM, Santosh Shilimkar wrote:
> Hi Ka-Cheong,
> 
> On 7/6/2018 8:25 AM, Sowmini Varadhan wrote:
>> On (07/06/18 23:08), Ka-Cheong Poon wrote:
>>>
>>> As mentioned in a previous mail, it is unclear why the
>>> port number is transport specific.  Most Internet services
>>> use the same port number running over TCP/UDP as shown
>>> in the IANA database.  And the IANA RDS registration is
>>> the same.  What is the rationale of having a transport
>>> specific number in the RDS implementation?
>>
>> because not every transport may need a port number.
>>
> Lets keep separate port for RDMA and TCP transport. This has been
> already useful for wireshark dissector and can also help for eBPF
> like external tooling. The fragment format and re-assembly is
> different across transports.


But does it have anything to do with the fact that a #define
is in the rds.h file?


> I do see your point and also agree that port number isn't transport
> specific and in case we need to add another transport, what port
> to use. But may be till then lets keep the existing behavior.
> As such this port switch is not related to IPv6 support as such
> so lets deal with it separately.


As I mentioned in a previous mail, I can move the #define if
it makes folks happy.  But the number cannot be changed as it
is already being used.


-- 
K. Poon
ka-cheong.poon@...cle.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ