Handling recv oversized packets

[Stuart Longland]

On 09/07/11 09:21, Smith, JDave wrote:
> Thanks for the info Stuart
> 
> I must admit I did not think to take off our standard disclaimer before sending out this message as an email to the mail distributer. I think I have learnt my lesson - thanks...
> 
> As I said, I went looking in common_channel.c and spotted
> 
>     678 /* Shared for data and stderr data - when we receive data, put it in a buffer
>     679  * for writing to the local file descriptor */
>     680 void common_recv_msg_channel_data(struct Channel *channel, int fd,
>     681 		circbuffer * cbuf) {
>      :
>     701 	datalen = buf_getint(ses.payload);
>     702 	TRACE(("length %d", datalen))
>     703 
>     704 	maxdata = cbuf_getavail(cbuf);
>     705 
>     706 	/* Whilst the spec says we "MAY ignore data past the end" this could
>     707 	 * lead to corrupted file transfers etc (chunks missed etc). It's better to
>     708 	 * just die horribly */
>     709 	if (datalen > maxdata) {
>     710 		dropbear_exit("Oversized packet");
>     711 	}
> 
> As I said, I am not a coding expert and I really want to be proved wrong. So is the above not applicable to my concern?

One can only hope dropbear_exit is to terminate the connection and not
the daemon.  I haven't spotted where common_channel.c is lurking in CVS.

Is it too difficult to move up to the latest release?  Perhaps the
"problem" was fixed there, as I don't see it in CVS?

> PS. Do you really still use tape for backups, my head is in the clouds ;-)

You betcha… tapes for data storage and vinyl for audio. :-)

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.