ratp: user close may happen in SYN-RECEIVED state ...

The reference says:

     5.2.3. SYN-RECEIVED
     ...
     Departures
       - A CLOSE request is made by the user.  Create a packet with
         FIN set.  Send it and go to the FIN-WAIT state.

Add this missing step.

Probably not a real usecase for barebox anyway as there is no user
triggered close.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: don't ignore data that may arrive in behaviour H1 ...

If an input packet arrives H1 that has data in it, we need to:
  * track sn_received
  * if we have data pending, send it
  * if we don't have data pending, send a plain ACK

This process, as noted in RFC916, is the same as the I1 procedure, so
go and run it:

     Go to the ESTABLISHED state and execute procedure I1 to process
     any data which might be in this packet.

This fix allows the peer to queue data in the last packet doing the
connection establishment. It doesn't apply to the barebox<->bbremote
interaction because bbremote won't queue data until the connection is
completely established, but it allows third party ratp implementations
to do that.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: remove FIXME comment: FIN always requires ACK ...

Section 3.4 in the RFC916 shows a packet flow for the connection close
where the initial packet sent by the endpoint starting the close has
just the FIN flag set, without an ACK:

          -->     <SN=0><AN=1><CTL=FIN>
                <SN=1><AN=1><CTL=FIN,ACK>  <--
          -->     <SN=1><AN=0><CTL=ACK>

This may lead to think that it is actually allowed to send the initial
packet with just FIN set, without ACK-ing any other packet from the
peer.

But, this is actually not possible, the packet MUST be ACK-ing a
previous packet from the peer, even if this is just a duplicated ACK,
because otherwise the packet with the FIN wouldn't get processed in
the H2 behavior (FIN processing) of the peer, as the F2 behavior (ACK
processing) would filter it out.

This is actually the same reasoning why data packets always have ACK
set, even if the same ACK has already been sent previously (e.g. with
a simple ACK packet without data); if they didn't have it, they would
be filtered out in the F2 behavior, never arriving the I1 behavior,
which is where the received data is processed.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: remove bogus data checks in behavior C2 ...

The SN validation was being completely ignored if the packet had no
data (e.g. for RST, FIN or SYN or plain ACKs). This condition is now
removed so that the SN check is done.

The second check removed was actually never being used, as it was
already being tested for not having data in the first one.

These two fixes are a cleanup to follow the protocol correctly.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

ratp: fix data presence check ...

Looking at the "data length" and SO flag isn't enough to declare a
packet with or without data, because SYN flagged packets will also use
the "data length" field to define MDL.

So, improve the check to match against SYN|RST|FIN flagged packets,
which can never have data.

This commit fixed a segfault in barebox when an unexpected SYN packet
was sent in the middle of a connection; barebox thought the packet had
data because the "data length" in the SYN packet was different than 0.

Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

scripts: make __init__.py nonempty ...

Otherwise they get removed by make distclean.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

host side for barebox remote control ...

This contains the host tool for barebox remote control. It is written in
Phython with its own implementation of the RATP protocol. Currently this
is a very simple tool which needs more work, but the code can also be
used as a library.

Example output:

console: '.      '
console: '..     '
console: 'dev    '
console: 'env    '
console: 'mnt    '
console: '\n'
Result: BBPacketCommandReturn(exit_code=0)

Signed-off-by: Jan Lübbe <j.luebbe@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>