Bug#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)

2022-04-02 Thread Bastian Germann

Control: retitle -1 python3-serial: rfc2217 support broken

The original issue was solved upstream with 
https://github.com/pyserial/pyserial/pull/183 in v3.3



Bug#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)

2013-05-01 Thread Sascha Silbe
Package: python3-serial
Version: 2.5-2.1
Severity: important

Dear Maintainer,

the RFC2217 support of pyserial, at least when used with Python 3, is
completely broken. Even just importing serial.rfc2217 fails:

=== Begin ===
sascha.silbe@twin:~$ python3
Python 3.2.3 (default, Feb 20 2013, 14:44:27) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial.rfc2217
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 90, in module
IAC_DOUBLED = to_bytes([IAC, IAC])
  File /usr/lib/python3/dist-packages/serial/serialutil.py, line 55, in 
to_bytes
b.append(item)  # this one handles int and str
TypeError: an integer is required
=== End ===

Importing serial.rfc2217 happens automatically when passing a
rfc2217:// URL to serial.serial_for_url():

=== Begin ===
sascha.silbe@twin:~$ python3
Python 3.2.3 (default, Feb 20 2013, 14:44:27) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial
 serial.serial_for_url('rfc2217://localhost:4001')
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/__init__.py, line 45, in 
serial_for_url
from . import rfc2217  # late import, so that users that don't use it don't 
have to load it
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 90, in module
IAC_DOUBLED = to_bytes([IAC, IAC])
  File /usr/lib/python3/dist-packages/serial/serialutil.py, line 55, in 
to_bytes
b.append(item)  # this one handles int and str
TypeError: an integer is required
=== End ===


I've verified that it still happens with python3-serial 2.6-1 from sid.


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.7-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python3-serial depends on:
ii  python3  3.2.3-6

python3-serial recommends no packages.

Versions of packages python3-serial suggests:
pn  python3-wxgtk2.8 | python3-wxgtk  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706518: python3-serial: rfc2217 support broken (cannot even import serial.rfc2217)

2013-05-01 Thread Sascha Silbe
Sascha Silbe sascha-debian-bugs-pyserial-2013-05...@silbe.org writes:

 the RFC2217 support of pyserial, at least when used with Python 3, is
 completely broken. Even just importing serial.rfc2217 fails:
[...]


I managed to fix that part by replacing serial.serialutil.to_bytes()
with the following:

def to_bytes(seq):
convert a sequence to a bytes type
b = bytearray()
for item in seq:
if isinstance(item, bytes):
b.append(ord(item))
else:
b.append(item)
return bytes(b)


The previous comment about bytearray.append() also handling non-integers
is simply incorrect.


However, using python3-serial in RFC2217 mode with ser2net 2.6-1,
configured in RFC2217 mode (telnet + remctl; confirmed working using
microcom 2012.06.0-2), still fails:

=== Begin ===
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3/dist-packages/serial/rfc2217.py, line 436, in open
raise SerialException(Remote does not seem to support RFC2217 or BINARY 
mode %r % mandadory_options)
serial.serialutil.SerialException: Remote does not seem to support RFC2217 or 
BINARY mode [we-BINARY:False(INACTIVE), we-RFC2217:False(REQUESTED)]
=== End ===


Using Python 2 it works fine:

=== Begin ===
sascha.silbe@twin:~$ python
Python 2.7.3 (default, Jan  2 2013, 13:56:14) 
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
 import serial
 serial.serial_for_url('rfc2217://172.16.0.77:4001')
Serialid=0x2448e10, open=True(port='rfc2217://172.16.0.77:4001', 
baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=None, xonxoff=False, 
rtscts=False, dsrdtr=False)
 
=== End ===


It seems the Python 3 version does different things on the wire than the
Python 2 one:

=== Begin payload of network packets, using python2 ===
11.804968 192.168.1.2.55752  172.16.0.77.4001
fffd 01
11.805196 192.168.1.2.55752  172.16.0.77.4001
fffb 03
11.805383 192.168.1.2.55752  172.16.0.77.4001
fffd 03
11.805607 192.168.1.2.55752  172.16.0.77.4001
fffd 2c
11.805654 192.168.1.2.55752  172.16.0.77.4001
fffb 2c
11.854005 172.16.0.77.4001  192.168.1.2.55752
fffb 03ff fb01 fffe 01ff fd00
11.854234 192.168.1.2.55752  172.16.0.77.4001
fffb 00
11.874337 172.16.0.77.4001  192.168.1.2.55752
fffb 01ff fe03
11.884146 172.16.0.77.4001  192.168.1.2.55752
fffb 03ff fc2c fffa 2c6b 00ff f0ff fd2c
11.894046 172.16.0.77.4001  192.168.1.2.55752
fffd 00
11.906036 192.168.1.2.55752  172.16.0.77.4001
fffa 2c01  2580 fff0
11.906145 192.168.1.2.55752  172.16.0.77.4001
fffa 2c02 08ff f0
11.906197 192.168.1.2.55752  172.16.0.77.4001
fffa 2c03 01ff f0
11.906258 192.168.1.2.55752  172.16.0.77.4001
fffa 2c04 01ff f0
11.964215 172.16.0.77.4001  192.168.1.2.55752
fffa 2c65  2580 fff0 fffa 2c66 08ff f0
11.964244 172.16.0.77.4001  192.168.1.2.55752
fffa 2c67 01ff f0ff fa2c 6801 fff0
12.006749 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 01ff f0
12.034048 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 01ff f0
12.057067 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 0bff f0
12.094156 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 0bff f0
12.107393 192.168.1.2.55752  172.16.0.77.4001
fffa 2c05 08ff f0
12.144054 172.16.0.77.4001  192.168.1.2.55752
fffa 2c69 08ff f0
12.157701 192.168.1.2.55752  172.16.0.77.4001
fffa 2c0c 01ff f0
12.194055 172.16.0.77.4001  192.168.1.2.55752
fffa 2c70 01ff f0
12.208043 192.168.1.2.55752  172.16.0.77.4001
fffa 2c0c 02ff f0
12.244098 172.16.0.77.4001  192.168.1.2.55752
fffa 2c70 02ff f0
=== End payload of network packets, using python2 ===


=== Begin payload of network packets, using python3 ===
40.714514 192.168.1.2.55753  172.16.0.77.4001
fffd 01
40.714541 192.168.1.2.55753  172.16.0.77.4001
fffb 03
40.714556 192.168.1.2.55753  172.16.0.77.4001
fffd 03
40.714568 192.168.1.2.55753  172.16.0.77.4001
fffd 2c
40.714581 192.168.1.2.55753  172.16.0.77.4001
fffb 2c
40.754194 172.16.0.77.4001  192.168.1.2.55753
fffb 03ff fb01 fffe 01ff fd00
40.754251 172.16.0.77.4001  192.168.1.2.55753
fffb 01ff fe03
40.764074 172.16.0.77.4001  192.168.1.2.55753
fffb 03ff fc2c
40.764121 172.16.0.77.4001  192.168.1.2.55753
fffa 2c6b 00ff f0ff fd2c
=== End payload of network packets, using python3 ===


So either my fix above breaks other parts of the code or there's more
broken than just to_bytes(). A quick guess would be that python3-serial
doesn't recognise what sredird sends.

Sascha


pgpaxeXhVg6jE.pgp
Description: PGP signature