You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proxy UART stack parses the data, data length, and service port in the layer 4 functions but when placing data into the RX queue for RESTful GET to return the FULL maximum packet is always returned instead of only the received data.
Problem Explanation
The UART stack is a fixed length protocol always transferring 123 bytes of payload information from a packet. Each layer 4 UART packet also contains a data length byte indicating the length of the payload data the exact data placed into the packet can be extracted from the padding.
defrun(self):
while(self.enabled):
#Delay to allow CPU utilization relaxingtime.sleep(0.001)
#check for transmit itemsif(self.transmit_datagram_queue_hasitem()):
tx_datagram=self.transmit_datagram_queue_get()
self.layer_2_object.POST(tx_datagram)
#check for receive itemsifself.receive_datagram_queue_hasitem():
rx_datagram=self.receive_datagram_queue_get()
try:
parsed_l4_packet=layer_4_protocol.parse_packet(rx_datagram)
self.receive_service_queue_put(parsed_l4_packet[2], parsed_l4_packet[0])
except:
logger.info('FAILED PARSING'+str(rx_datagram))
pass#Check uart datalink receive for new datagrams to parseself.uart_layer_receive_link()
simply ignores the payload length data parsed and returns the ENTIRE packet.
This is incorrect because ideally DATA IN == DATA OUT of a packetized network layer. Data of 42 bytes long in expects to be returned as 42 bytes output.
Summary
Proxy UART stack parses the data, data length, and service port in the layer 4 functions but when placing data into the RX queue for RESTful GET to return the FULL maximum packet is always returned instead of only the received data.
Problem Explanation
The UART stack is a fixed length protocol always transferring 123 bytes of payload information from a packet. Each layer 4 UART packet also contains a data length byte indicating the length of the payload data the exact data placed into the packet can be extracted from the padding.
https://github.com/FaradayRF/Faraday-Software/blob/master/faraday/uart/layer_4_protocol.py#L35
shown below extracts the layer 4 packet and returns it to the calling function.
The calling function in https://github.com/FaradayRF/Faraday-Software/blob/master/faraday/uart/layer_4_service.py#L221
simply ignores the payload length data parsed and returns the ENTIRE packet.
This is incorrect because ideally DATA IN == DATA OUT of a packetized network layer. Data of 42 bytes long in expects to be returned as 42 bytes output.
The correct fix for this is to change:
self.receive_service_queue_put(parsed_l4_packet[2], parsed_l4_packet[0])
to
self.receive_service_queue_put(parsed_l4_packet[2][0:parsed_l4_packet[1]], parsed_l4_packet[0])
which places only the original data into the proxy queue and removes all padding.
Environment
Software
I'm using an older master but this this is present in the current master as linked.
Hardware
Faraday REV D
Supporting Information
Data is a constant 42 byte packet sent from Faraday firmware, no proxy TX is involved.
Incorrect (Below) shows data returned from proxy randomly returning 42 bytes and 123 bytes (padding included in return).
When the data is extracted as described above the correct packet is always returned with NO padding.
The text was updated successfully, but these errors were encountered: