[issue36132] Python cannot access hci_channel field in sockaddr_hci

2019-02-27 Thread Andrew P. Lentvorski, Jr. 


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

2019-02-27 Thread Andrew P. Lentvorski, Jr. 


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

2014-02-28 Thread Andrew P. Lentvorski, Jr. 

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

2014-02-26 Thread Andrew P. Lentvorski, Jr. 

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

2014-02-26 Thread Andrew P. Lentvorski, Jr. 

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

2014-02-26 Thread Andrew P. Lentvorski, Jr. 

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