Hey,
For anyone interested, I ended up preparing a pair of C libraries and
a CLI tool that allow controlling barebox remotely using RATP, in the
same way as bbremote does it. The libraries would allow easy
integration on C applications that may want to remotely control
barebox.
Repositories:
ht
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.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 2 +-
scripts
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 e
Setting the next AN or SN flag was being done in two different ways
throughout the code; e.g. here for AN:
ratp_set_an(ratp_sn(hdr) + 1);
or:
ratp_set_an(!ratp_sn(hdr));
We define a pair of new ratp_set_next_sn() and ratp_set_next_an()
macros that make it clear that the next value is desi
All ACKs without data must be built in the same way from the input
message:
The code was actually doing this instead:
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index 321721ab7
And also, use ratp_send_ack() instead of manually constructing an ACK
if no data is pending to be sent.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index c7f3f4171..e810a9e54 100644
--- a/lib
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:
-->
<--
-->
This may lead to think that it is actually allowed to send
Instead of manually constructing an ACK, use the ratp_send_ack()
method, which already does that properly.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index 46a2b645c..c7f3f4171 100644
-
When a single data byte is sent, it is flagged as SO and the actual
data goes in the length byte within the header.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index c946bea1a..846f8130c
This is no code change in ratp_sn_expected(), it's just rewritten in
the same way as ratp_an_expected(), which follows the RFC916 approach.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index 5c52d3b5f
The reference says:
If the SYN flag was set but the ACK was not set then the other
end of the connection has executed an active open also.
Acknowledge the SYN, choose your MDL, and send:
Go to the SYN-RECEIVED state without any further processing.
Add this missing step.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/ratp.c b/lib/ratp.c
index 0d384aa4e..e9536499e 100644
--- a/lib/ratp.c
+++ b/lib/ratp.c
@@ -382,7 +382,7 @@ static int ratp_send_ack(struct ratp_internal *ri, struct
ratp_
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.
Signed-off-by: Aleksander
The reference says:
If SYN was set we assume that the other end crashed and has
attempted to open a new connection. We respond by sending a
legal reset:
Add this missing step.
Signed-off-by: Aleksander Morgado
---
lib/ratp.c | 7 +++
1 file changed, 7 insertions(+)
d
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
The reference says:
If the ACK flag was set then send:
If the ACK flag was not set then send:
(i.e. in both cases RST is needed)
The RST flag is set initially in the 'control' variable; so instead of
completely overwriting it, make sure the additional flags are OR-ed
to t
Hey Sascha,
I went through the RFC916 and ended up preparing a set of fixes and
improvements for the RATP logic in barebox.
Let me know what you think.
Cheers!
Aleksander Morgado (16):
ratp: add missing transition to SYN-RECEIVED in behavior B
ratp: avoid unnecessary variable initialization
The reference says:
This procedure represents the behavior of the CLOSED state of a
connection. All incoming packets are discarded. If the packet
had the RST flag set take no action. Otherwise it is necessary
to build a RST packet.
So, skip building the RST packet if the incoming
Hi Oleksij,
On 06/15/2017 08:56 AM, Oleksij Rempel wrote:
> Hi Vladimir,
>
> On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote:
>> Hi Oleksij,
>>
>> On 06/11/2017 09:19 AM, Oleksij Rempel wrote:
>>> Hi Rob,
>>>
>>> On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote:
Up to now only 2nd stage booting is tested and boots up to a prompt.
i2c and spi are working, ethernet, usb and sata don't.
Signed-off-by: Uwe Kleine-König
---
Changes since (implicit) v1:
- fix copyright stuff
- drop some debug remains
- fix kwboot.cfg
arch/arm/boards/Makefile
20 matches
Mail list logo
