netdev - RE: [PATCH net-next-2.6 v6 08/12] net-caif: add CAIF socket implementation

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: <81C3A93C17462B4BBD7E272753C1057916954ED6B0@EXDCVYMBSTM005.EQ1STM.local>
Date:	Wed, 17 Mar 2010 12:04:11 +0100
From:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Daniel MARTENSSON <daniel.martensson@...ricsson.com>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"stefano.babic@...ic.homelinux.org" 
	<stefano.babic@...ic.homelinux.org>,
	"randy.dunlap@...cle.com" <randy.dunlap@...cle.com>
Subject: RE: [PATCH net-next-2.6 v6 08/12] net-caif: add CAIF socket
 implementation

Hi Marcel,
>> >> +	 * The sock->type specifies the socket type to use. The CAIF
>> >> socket is +	 * a packet stream in the sence that it is packet based.
>> >> +	 * CAIF trusts the reliability of the link, no resending is
>> >> implemented. +	 */ +	if (sock->type != SOCK_SEQPACKET)
>> >> +		return -ESOCKTNOSUPPORT;
>> > 
>> > we came to an interesting detail here when testing with a STE modem.
>> > Why is this SEQPACKET and not a STREAM.
>> 
>> The reason is that CAIF provides different services not just AT,
>> and some of them are really packet oriented such as Utility links and
>> Video. It would not be right to provide a stream based solution in this case.
>> 
>> > Especially with the AT
>> > command channels it is kinda weird that you have an MTU. The AT
>> > specification doesn't really have any defined behavior when using a
>> > sequential packet transport. It is more a stream based socket.
>> 
>> Yes I see your point. In order to limit the effort and simplify
>> caif_socket we ended up implementing only SEQPACKET. 
>
>I think we need to split this. Use SEQPACKET for packet based services
>and have STREAM for AT command channel.
>So while this might cause internally some more code. It would take away
>the complexity from userspace to turn it into a stream. And that is what
>the userspace is expecting.

Ok Marcel, I'll look into supporting both STREAM and SEQPACKET.
BR/Sjur