public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [PATCH 2/6] alfred: Make buffer size check before sending explicit
Date: Mon, 01 Jun 2015 19:23:55 +0200	[thread overview]
Message-ID: <7394365.ZOVSlEK3zK@bentobox> (raw)
In-Reply-To: <1433072160-3260-2-git-send-email-sven@narfation.org>

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Sunday 31 May 2015 13:35:56 Sven Eckelmann wrote:
> It is checked when data is send by checking if the data would fit inside
> the outgoing UDP packet. But it is not checked if the data would fit after
> the sending was done. This doesn't have to be true just from the
> restrictions which can be seen in this function. So just check if the data
> and its headers would now fit in outgoing buffer before copying the data to
> the output buffer.
> 
> This is not a problem by itself because the data + header in the dataset
> cannot be larger than (MAX_PAYLOAD - sizeof(struct alfred_push_data_v0)).

Alternative commit message:

The sending code is automatically transmitting a packet when the next data
block would not fit inside the outgoing, aggregated UDP packet. But the
code does not check whether the data would then fit inside the new,
complete empty push_data packet. It is currently no problem because alfred
has the restriction that a dataset never stores a buffer larger than
(MAX_PAYLOAD - sizeof(struct alfred_push_data_v0) - sizeof(struct alfred_data)).
Therefore, the length check for the empty push_data packet + dataset buffer
would never fail.

Nonetheless, make this check explicit to avoid problems when the receiving
code is changed or the sending code gets the ability to limit the size of
outgoing UDP packets.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-06-01 17:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-31 11:35 [B.A.T.M.A.N.] [PATCH 1/6] alfred: Reduce MAX_PAYLOAD by the size of the UDP header Sven Eckelmann
2015-05-31 11:35 ` [B.A.T.M.A.N.] [PATCH 2/6] alfred: Make buffer size check before sending explicit Sven Eckelmann
2015-06-01 17:23   ` Sven Eckelmann [this message]
2015-05-31 11:35 ` [B.A.T.M.A.N.] [PATCH 3/6] alfred: Don't push data when nothing is available Sven Eckelmann
2015-05-31 11:35 ` [B.A.T.M.A.N.] [PATCH 4/6] alfred: Check buffer size before pushing data over unix socket Sven Eckelmann
2015-05-31 11:35 ` [B.A.T.M.A.N.] [PATCH 5/6] alfred: First check only push_data header length Sven Eckelmann
2015-05-31 11:36 ` [B.A.T.M.A.N.] [PATCH 6/6] alfred: Drop small push_data packets early Sven Eckelmann
2015-06-01 17:56 ` [B.A.T.M.A.N.] [PATCH 1/6] alfred: Reduce MAX_PAYLOAD by the size of the UDP header Simon Wunderlich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7394365.ZOVSlEK3zK@bentobox \
    --to=sven@narfation.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox