summaryrefslogtreecommitdiff
path: root/scripts/remote
Commit message (Collapse)AuthorAgeFilesLines
* bbremote: Fix RATP handshake, errata #7321 for RFC916Jules Maselbas2023-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Side A Side B 1. CLOSED LISTEN 2. [OPEN request] SYN_SENT --> <SN=0><CTL=SYN> --> SYN_RECEIVED 3. ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK> <-- 4. --> <SN=1><AN=0><CTL=ACK> ... 5. ... <SN=0><AN=1><CTL=SYN,ACK> <-- (retransmit) 6. (packet sent by A at 4. finally arrives to B) ... --> ESTABLISHED 7. (packet resent by B at 5. finally arrives to A) CLOSED (C2) <-- ... 8. --> <SN=1><AN=1><CTL=RST> --> (connection reset) The Figure above illustrate the current issue RATP can face during the three-way handshake, and how behavior C2 can cause a connection to be closed immediately after being established. In the Figure above, side A try to establish a connection with side B, which is in the LISTEN state. Commented line: 1. side A is in the CLOSED state and side B is in the LISTEN state; 2. side A open a new connection and send a SYN packet and is received by side B which enters the SYN_RECEIVED state and send back a SYN-ACK; 3. side A receive the SYN-ACK packet from B; 4. side A respond with an ACK packet and move to the ESTABLISHED state. Meanwhile; 5. side B hasn't received yet the ACK from side A and decide to retransmit the SYN-ACK packet; 6. side B finally receive the ACK from side A and move to the ESTABLISHED state; 7. side A finally receive the duplicated SYN-ACK packet from side B, execute behavior C2: the received packet doesn't have the expected SN and has the SYN flag set, thus respond by sending a legal reset. 8. side B receive the reset and close the connection. One solution could be to tweak the initial RTO value of side B in order to prevent sending a duplicated SYN-ACK packet, however the initial RTT value is likely inaccurate during the handshake. This solution seems a bit brittle. The second solution would be to consider that a host has crashed only if the packet received has the SYN flag set but not the ACK flag. The rational is that the first step during handshake is to send a packet only containing the SYN flag, however a packet containing both ACK and SYN flags must have come after the initial handshake exchange and can be considered as a duplicated and be dropped. I proposed the following errata to RFC916 [1]: [Page 29] - 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: + If the SYN flag was set but the ACK was not set then we assume + that the other end crashed and has attempted to open a new connection. + We respond by sending a legal reset: [Page 30] - If neither RST, FIN, nor SYN flags were set it is assumed that - this packet is a duplicate of one already received. Send an - ACK back: + If neither RST nor FIN flags were set, or if SYN and ACK flags + were set, it is assumed that this packet is a duplicate of one + already received. Send an ACK back: [1] https://www.rfc-editor.org/errata/eid7321 Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu> Link: https://lore.barebox.org/20230207162055.10050-2-jmaselbas@kalray.eu Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: Fix default payload value in BBPacketJules Maselbas2023-02-131-1/+2
| | | | | | | | | | The payload variable is expected to typeof bytes, however the default value in BBPacket contructor is of type str, a simple way to declare a byte literal in Python is to prefix the string literal with `b`. Signed-off-by: Jules Maselbas <jmaselbas@kalray.eu> Link: https://lore.barebox.org/20230207162055.10050-1-jmaselbas@kalray.eu Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: Print usage when no command is givenSascha Hauer2022-09-121-0/+6
| | | | | | | | | Instead of dumping a backtrace, print usage information when no subcommand is given. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.barebox.org/20220908093005.3035259-6-s.hauer@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: Convert to python3Sascha Hauer2022-09-127-32/+51
| | | | | | | | This is the long overdue conversion from python2 to python3. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.barebox.org/20220908093005.3035259-3-s.hauer@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: implement support for GPIO operationsAleksander Morgado2018-09-173-0/+166
| | | | | Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: implement i2c read/write supportAleksander Morgado2018-09-173-0/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the bbremote script with operations to perform binary i2c read/write operations. E.g.: barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w 0x8f 0x30 0x00 0x00 barebox:/ i2c_write -b 0 -a 0x68 -r 0x06A0 -w 0x87 0x30 0x00 0x00 barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w 0x87 0x30 0x00 0x00 barebox:/ i2c_write -b 0 -a 0x68 -r 0x06A0 -w 0x8f 0x30 0x00 0x00 barebox:/ i2c_read -b 0 -a 0x68 -r 0x06A0 -c 4 -w 0x8f 0x30 0x00 0x00 =================================================================== $ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4 8f300000 $ ./scripts/bbremote --port /dev/ttyUSB2 i2c-write 0x00 0x68 0x06A0 0x01 "87300000" 4 bytes written $ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4 87300000 $ ./scripts/bbremote --port /dev/ttyUSB2 i2c-write 0x00 0x68 0x06A0 0x01 "8f300000" 4 bytes written $ ./scripts/bbremote --port /dev/ttyUSB2 i2c-read 0x00 0x68 0x06A0 0x01 4 8f300000 Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: add missing 'md' packet handlerAleksander Morgado2018-08-221-0/+3
| | | | | Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* ratp: new reset commandAleksander Morgado2018-03-013-3/+35
| | | | | | | | E.g.: $ ./bbremote -v --port /dev/ttyUSB2 reset Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* ratp: new md and mw commandsAleksander Morgado2018-03-013-0/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces support for running the md and mw commands using the binary interface provided by RATP. This allows clients to read and write memory files without needing to do custom string parsing on the data returned by the console 'md' and 'mw' operations. The request and response messages used for these new operations are structured in the same way: * An initial fixed-sized section includes the fixed-sized variables (e.g. integers), as well as the size and offset of the variable-length variables. * After the initial fixed-sized section, the buffer is given, which contains the variable-length variables in the offsets previously defined and with the size previously defined. The message also defines separately the offset of the buffer w.r.t. the start of the message. The endpoint reading the message will use this information to decide where the buffer starts. This allows to extend the message format in the future without needing to break the message API, as new fields can be appended to the fixed-sized section as long as the buffer offset is also updated to report the new position of the buffer. E.g.: $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5 0000000000 $ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0102030405 5 bytes written $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5 0102030405 $ ./bbremote --port /dev/ttyUSB2 mw /dev/pic_eeprom_rdu 0x107 0000000000 5 bytes written $ ./bbremote --port /dev/ttyUSB2 md /dev/pic_eeprom_rdu 0x107 5 0000000000 Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* bbremote: rename command subparser variablesAleksander Morgado2018-01-301-7/+7
| | | | | | | | | | Don't reuse unrelated subparser variables for new command subparsers, make each subparser have its own variable. Just for consistency really, not a bugfix. Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* ratp: user close may happen in SYN-RECEIVED stateAleksander Morgado2017-06-231-1/+1
| | | | | | | | | | | | | | | | | | 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 H1Aleksander Morgado2017-06-231-8/+6
| | | | | | | | | | | | | | | | | | | | | | 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 ACKAleksander Morgado2017-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 C2Aleksander Morgado2017-06-231-11/+5
| | | | | | | | | | | | | | 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 checkAleksander Morgado2017-06-231-2/+2
| | | | | | | | | | | | | | | | 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 nonemptySascha Hauer2016-02-121-0/+1
| | | | | | Otherwise they get removed by make distclean. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
* host side for barebox remote controlJan Luebbe2016-01-188-0/+1532
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>
View Lorry Controller Status