[AGWPE] D-Rats should use AX.25 UI Frames

[dscp46]

Hi,

D-Rats' AGW module makes an inappropriate use of AX.25 I frames (which one MAY use after having properly established an AX.25 connection-mode data link).

The issue is located there:

D-Rats/d_rats/agw.py

Lines 695 to 700 in 54bddfd

	data_frame = struct.pack("!B7s%isBB" % len(src),
	0x00, # Space for flag (?)
	dst, # Dest Call
	src, # Source Path
	0x3E, # Info
	0xF0) # PID: No layer 3

To comply, we would need set the control field value to 0x03 (UI Frame, poll bit set), instead of 0x3E (I Frame, poll bit set) at line 699.

This should not introduce any regression, since the AGW and AX.25 headers are stripped without any sanity check, at line 106:

D-Rats/d_rats/agw.py

Lines 103 to 108 in 54bddfd

	self.user_pad_longword = struct.unpack("<HHBBBB10s10sII",
	data[:AGW_HEADER_SIZE])
	self.payload = data[AGW_HEADER_SIZE:]
	if len(self.payload) != self.len:
	raise AgwPayloadLenError("Expecting payload of %i, got %i" %

Best regards,

[wb8tyw]

Issue has turned out to be more complex and affects the comm.py module also.

The problem is that doing bit manipulation on python3 UTF-8 string types as AGS and comm corrupts the UTF-8 strings.

This operation was valid in the original python2 code, for python3 only a byte type can be used.

[wb8tyw]

Similar bugs may be present in aprs_dprs.py, gps.py, yencode.py, and wl2k.py as they are pushing numbers into utf-8 strings.

[wb8tyw]

yencode.py is clear of issues, code is only present for in the python2 compatibility mode.

[wb8tyw]

aprs_dprs is clear of this issue, all results are constrained to ASCII values.

[wb8tyw]

gps.py is clear of this issue.

w2lk unfortunately has this, which was legal with python2, but it risks corrupting a UTF-8 string.

        header_str = self.__name + "\x00" + chr(len(data) & 0xFF) + "\x00"
        header = header_str.encode('utf-8', 'replace')