[issue36132] Python cannot access hci_channel field in sockaddr_hci
Andrew P. Lentvorski, Jr. added the comment: It's up to you how you folks want to deal with this, but classifying it as a "bug" for those versions in bugfix is likely acceptable. You already have to call bind with a tuple, so as long as it is *optional* to add an extra field to that tuple (and I can't imagine that any fix would not do that as it would break existing code), it's not going to break things. However, since nobody seems to have felt the need to file this, fixing this in 3.8 is probably just fine. -- ___ Python tracker <https://bugs.python.org/issue36132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36132] Python cannot access hci_channel field in sockaddr_hci
New submission from Andrew P. Lentvorski, Jr. : On Linux, sockaddr_hci is: struct sockaddr_hci { sa_family_t hci_family; unsigned short hci_dev; unsigned short hci_channel; }; Unfortunately, it seems like python does not allow any way to initialize hci_channel, so you can't use a user channel socket (hci_channel == 0) or a monitor channel. There is probably a larger discussion of how to enable people to use a new field that appears in a structure like this, but that's above my pay grade ... Even worse, this appears to have been known for a while (since 2013 at least! by Chromium), but while people complained, nobody actually took the time to file it upstream with Python. So, I'm filing it upstream. Hopefully this is easy to fix by someone who knows what's up. Thanks. See: https://chromium.googlesource.com/chromiumos/platform/btsocket/+/factory-4455.B https://github.com/w3h/isf/blob/master/lib/thirdparty/scapy/layers/bluetooth.py class BluetoothUserSocket(SuperSocket): desc = "read/write H4 over a Bluetooth user channel" def __init__(self, adapter=0): # s = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_RAW, socket.BTPROTO_HCI) # s.bind((0,1)) # yeah, if only # thanks to Python's weak ass socket and bind implementations, we have # to call down into libc with ctypes sockaddr_hcip = POINTER(sockaddr_hci) cdll.LoadLibrary("libc.so.6") libc = CDLL("libc.so.6") socket_c = libc.socket socket_c.argtypes = (c_int, c_int, c_int); socket_c.restype = c_int bind = libc.bind bind.argtypes = (c_int, POINTER(sockaddr_hci), c_int) bind.restype = c_int ## actual code s = socket_c(31, 3, 1) # (AF_BLUETOOTH, SOCK_RAW, HCI_CHANNEL_USER) if s < 0: raise BluetoothSocketError("Unable to open PF_BLUETOOTH socket") sa = sockaddr_hci() sa.sin_family = 31 # AF_BLUETOOTH sa.hci_dev = adapter # adapter index sa.hci_channel = 1 # HCI_USER_CHANNEL r = bind(s, sockaddr_hcip(sa), sizeof(sa)) -- components: Library (Lib) messages: 336743 nosy: bsder priority: normal severity: normal status: open title: Python cannot access hci_channel field in sockaddr_hci versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20803] struct.pack_into writes 0x00 for pad bytes
New submission from Andrew P. Lentvorski, Jr.: This code did something unexpected to me: a = bytearray('1234') a bytearray(b'1234') struct.pack_into('xBxB', a, 0, 0x59, 0x5A) a bytearray(b'\x00Y\x00Z') The unexpected part was that the 'x' pad byte formatter actually *overwrote* the bytes to 0 rather than leaving them alone. Not necessarily a bug, but the fact that the pad byte writes 0x00 rather than being untouched/ignored should be documented. -- components: Interpreter Core messages: 212416 nosy: bsder priority: normal severity: normal status: open title: struct.pack_into writes 0x00 for pad bytes type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20803 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
New submission from Andrew P. Lentvorski, Jr.: The byte array init fails when \x00 is present This fails: ggRAM = bytearray(RAM_SIZE_BYTES, '\x00'*RAM_SIZE_BYTES) However, this works: ggRAM = bytearray(RAM_SIZE_BYTES) ggRAM[:] = '\x00'*RAM_SIZE_BYTES -- components: Interpreter Core messages: 212281 nosy: bsder priority: normal severity: normal status: open title: bytearray init fails when \x00 is present type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
Andrew P. Lentvorski, Jr. added the comment: Ayup, I are an idiot. Sorry. ggRAM = bytearray('\x00'*RAM_SIZE_BYTES) Works fine. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
Changes by Andrew P. Lentvorski, Jr. bs...@allcaps.org: -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com