| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Our cyc_crc16() function is the same function as crc_itu_t() in the
Linux kernel. Import and use crc_itu_t() from the Kernel for
consistency.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
We need to advance the input buffer used to create messages when the
data doesn't fit in a single RATP packet.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a cli-based RATP that opens and closes the RATP channel for
each command sent/received, it gets annoying to get the "Closed"
message printed all the time in console after each RATP channel close
operation. Just demote it to debug level.
E.g.:
barebox@barebox sandbox:/ ratp: Closed
ratp: Closed
ratp: Closed
ratp: Closed
...
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 desired, and also
hide the computation of the actual flag value within the macro, so the
previous example would now look like:
ratp_set_next_an(ratp_sn(hdr));
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
And also, use ratp_send_ack() instead of manually constructing an ACK
if no data is pending to be sent.
The current barebox implementation doesn't allow any queueing of data
until the connection is established, so this is probably not a case
that would get run anyway.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
Instead of manually constructing an ACK, use the ratp_send_ack()
method, which already does that properly.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
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 <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All ACKs without data must be built in the same way from the input
message:
<SN=received AN><AN=received SN+1 modulo 2><CTL=ACK>
The code was actually doing this instead:
<SN=0><AN=SN><CTL=ACK>
This change fixes how the retransmissions are ACK-ed by the peer, and
would have affected the barebox<->bbremote interactions.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a single data byte is sent, it is flagged as SO and the actual
data goes in the length byte within the header.
Worth noting that this issue wasn't found in any barebox<->bbremote
interaction because all data packets sent between them always have
more than one byte (due to the barebox command specific header).
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 one had RST set.
This commit fixes an infinite loop of messages sent and received
between both ends during the connection close procedure, found when
testing barebox against a third party ratp implementation.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reference says:
If the ACK flag was set then send:
<SN=received AN><CTL=RST>
If the ACK flag was not set then send:
<SN=0><AN=received SN+1 modulo 2><CTL=RST, ACK>
(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 the current value.
This fix isn't related to any failed barebox<->bbremote interaction
(it really is a very rare corner case).
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
<SN=received AN><AN=received SN+1 modulo 2><CTL=RST, ACK>
Add this missing step.
This issue affects the barebox<->bbremote interaction if bbremote
crashes without closing the channel and restarts opening a complete
new connection.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
This is just a cleanup; the variables are completely initialized later
on so the initial values are totally discarded anyway.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
<SN=0><AN=received SN+1 modulo 2><CTL=SYN, ACK><LENGTH=MDL>
Go to the SYN-RECEIVED state without any further processing.
Add this missing step.
This fix isn't related to any barebox<->bbremote interaction issue,
because the case where both ends start an active connection doesn't
apply in this case.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
| |
If ratp_establish() fails we would be accessing the ratp_internal
struct after having disposed it.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
This patch adds support for Reliable Asynchronous Transfer Protocol (RATP)
as described in RFC916.
Communication over RS232 is often unreliable as characters are lost or
misinterpreted. This protocol allows for a reliable packet based communication
over serial lines.
The implementation simply follows the state machine described in the RFC
text with one exception. RFC916 uses a plain checksum for the
transferred data. We decided to use CRC16 for greater robustness. Since
this is the only RFC916 implementation we currently know of interoperability
with other implementations should not matter.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Andrey Smirnov <andrew.smirnov@gmail.com>
|
