[issue40291] socket library support for CAN_J1939
New submission from Karl Ding : It would be nice to have support J1939 sockets. Support for J1939 landed as part of the SAE J1939 SocketCAN patches, which are available after the Linux 5.4rc1 kernel. This is another protocol family for SocketCAN, much like the existing support for ISOTP and BCM. Effectively, supporting this would hand off as much to the kernel as possible, which gives Python programs the ability deal with J1939 without having to implement the logic existing in the kernel in userspace. This is provided to userspace [0] via the header. I'd be happy to work on this and provide a PR. [0] https://www.kernel.org/doc/html/latest/networking/j1939.html -- components: Library (Lib) messages: 366487 nosy: karlding priority: normal severity: normal status: open title: socket library support for CAN_J1939 type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40291] socket library support for CAN_J1939
Change by Karl Ding : -- keywords: +patch pull_requests: +18886 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19538 ___ Python tracker <https://bugs.python.org/issue40291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40297] test_socket.CANTest is broken at HEAD on master
New submission from Karl Ding :
While working on https://bugs.python.org/issue40291, I was trying to run the
SocketCAN tests to ensure that my changes weren't causing any regressions.
However, I was seeing test failures at HEAD.
I'm running the tests like so:
# Kernel version
uname -r
# 5.4.23-1-MANJARO
# Load SocketCAN vcan kernel module
sudo modprobe vcan
# Start and set up a virtual SocketCAN interface
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
# Run the socket tests using locally built python
./python -m unittest -v test.test_socket.CANTest
After bisecting, I discovered that the test started failing back in 2017, with
the introduction of the ISOTP protocol.
https://github.com/python/cpython/pull/2956/files#diff-a47fd74731aeb547ad780900bb8e6953L1376-R1391
Here, the address family (the second tuple item) is explicitly removed:
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
index bf8d19fe2f..beadecfad5 100644
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1373,9 +1373,22 @@ makesockaddr(SOCKET_T sockfd, struct sockaddr *addr,
size_t addrlen, int proto)
ifname = ifr.ifr_name;
}
-return Py_BuildValue("O&h", PyUnicode_DecodeFSDefault,
-ifname,
-a->can_family);
+switch (proto) {
+#ifdef CAN_ISOTP
+ case CAN_ISOTP:
+ {
+ return Py_BuildValue("O&kk", PyUnicode_DecodeFSDefault,
+ ifname,
+ a->can_addr.tp.rx_id,
+ a->can_addr.tp.tx_id);
+ }
+#endif
+ default:
+ {
+ return Py_BuildValue("O&", PyUnicode_DecodeFSDefault,
+ifname);
+ }
+}
}
#endif
This seems to be an intentional breakage, since the code in getsockaddrarg also
operates on just the interface name, ignoring the address family.
if (!PyArg_ParseTuple(args,
"O&;AF_CAN address must be a tuple "
"(interface, )",
PyUnicode_FSConverter, &interfaceName))
As such, I believe the test should have been updated, but was missed during the
ISOTP changes. Can someone (a core member?) confirm that this is the correct
approach?
Note: However, this also implies that the CANTest test was never being run
(either via CI on PRs or on the Buildbot cluster) and instead was always
skipped, since I would've expected this failure to show up right away...
--
components: Library (Lib)
messages: 366576
nosy: karlding
priority: normal
severity: normal
status: open
title: test_socket.CANTest is broken at HEAD on master
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40297>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40297] test_socket.CANTest is broken at HEAD on master
Change by Karl Ding : -- keywords: +patch pull_requests: +18894 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19548 ___ Python tracker <https://bugs.python.org/issue40297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40291] socket library support for CAN_J1939
Change by Karl Ding : -- pull_requests: +19536 pull_request: https://github.com/python/cpython/pull/20248 ___ Python tracker <https://bugs.python.org/issue40291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40291] socket library support for CAN_J1939
Karl Ding added the comment: Should this be added to the What's New for 3.9? I see a smaller change that exposes the CAN_RAW_JOIN_FILTERS constant mentioned. I've created https://github.com/python/cpython/pull/20248 if this is needed. -- ___ Python tracker <https://bugs.python.org/issue40291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40297] test_socket.CANTest is broken at HEAD on master
Karl Ding added the comment: Related: I've started a thread on Discourse [0] looking into why the tests don't seem to be run on the Buildbot cluster (and what it would take to enable them). Hopefully it gains some traction. [0] https://discuss.python.org/t/what-would-it-take-to-run-socketcan-tests-on-a-buildbot/4137 -- ___ Python tracker <https://bugs.python.org/issue40297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37085] Expose additional socket constants for CAN_BCM flags
New submission from Karl Ding :
When reading through the values exposed via the socket library, I noticed that
currently, only the SocketCAN BCM opcode enums are exposed via the socket
constants. These correspond to the following from the Linux headers:
enum {
TX_SETUP = 1, /* create (cyclic) transmission task */
TX_DELETE, /* remove (cyclic) transmission task */
TX_READ,/* read properties of (cyclic) transmission
task */
TX_SEND,/* send one CAN frame */
RX_SETUP, /* create RX content filter subscription */
RX_DELETE, /* remove RX content filter subscription */
RX_READ,/* read properties of RX content filter
subscription */
TX_STATUS, /* reply to TX_READ request */
TX_EXPIRED, /* notification on performed transmissions
(count=0) */
RX_STATUS, /* reply to RX_READ request */
RX_TIMEOUT, /* cyclic message is absent */
RX_CHANGED /* updated CAN frame (detected content change)
*/
};
It would be nice to expose the BCM flags #defines as well.
#define SETTIMER0x0001
#define STARTTIMER 0x0002
#define TX_COUNTEVT 0x0004
#define TX_ANNOUNCE 0x0008
#define TX_CP_CAN_ID0x0010
#define RX_FILTER_ID0x0020
#define RX_CHECK_DLC0x0040
#define RX_NO_AUTOTIMER 0x0080
#define RX_ANNOUNCE_RESUME 0x0100
#define TX_RESET_MULTI_IDX 0x0200
#define RX_RTR_FRAME0x0400
#define CAN_FD_FRAME0x0800
These BCM flags are used as part of the BCM header that has the aforementioned
opcodes. The flags are set on the bcm_msg_head struct:
struct bcm_msg_head {
__u32 opcode;
__u32 flags;
__u32 count;
struct bcm_timeval ival1, ival2;
canid_t can_id;
__u32 nframes;
struct can_frame frames[0];
};
The existing documentation for the BCM constants
(https://docs.python.org/3/library/socket.html#socket.CAN_BCM) seems to imply
that these constants should already be included, but they are not.
See the Linux headers for more details:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/can/bcm.h
--
components: Library (Lib)
messages: 343865
nosy: karlding
priority: normal
severity: normal
status: open
title: Expose additional socket constants for CAN_BCM flags
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue37085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37085] Expose additional socket constants for CAN_BCM flags
Change by Karl Ding : -- keywords: +patch pull_requests: +13541 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13646 ___ Python tracker <https://bugs.python.org/issue37085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Bitfields Incorrectly - Linux
Karl Ding added the comment:
I believe the example can be simplified to the following:
class MyStructure(ctypes.Structure):
_pack_ = 1
_fields_ = [('A', ctypes.c_uint32, 8)]
assert ctypes.sizeof(MyStructure) == 1
Here, ctypes.sizeof returns 4 on my machine (64-bit Ubuntu 18.04 LTS), while I
would expect it to return 1 like GCC. This is using a tree checked out at
33ce3f012f249782507df896824b045b34f765aa, if it makes a difference.
If we compile the equivalent C code (on 64-bit Ubuntu 18.04 LTS):
#include
#include
#include
struct my_structure_uint32 {
uint32_t a : 8;
} __attribute__((packed));
int main(int argc, char *argv[]) {
printf("sizeof(struct my_structure_uint32): %d\n", sizeof(struct
my_structure_uint32));
printf("alignof(struct my_structure_uint32): %d\n", alignof(struct
my_structure_uint32));
return 0;
}
Using the following GCC invocation:
gcc temp.c -o test && ./test
We get the following result:
sizeof(struct my_structure_uint32): 1
alignof(struct my_structure_uint32): 1
However, if I compile with MSVC bitfields:
gcc -mms-bitfields test.c -o test && ./test
We get the following result:
sizeof(struct my_structure_uint32): 4
alignof(struct my_structure_uint32): 1
Similarly, adding a second and third 8-bit wide bitfield member fails and
returns 4, instead of the expected 2 and 3.
This is not just c_uint32, c_uint16 and c_int also exhibit the same behaviour:
class MyStructure(ctypes.Structure):
_pack_ = 1
_fields_ = [('A', ctypes.c_uint16, 8)]
assert ctypes.sizeof(MyStructure) == 1
--
nosy: +karlding
___
Python tracker
<https://bugs.python.org/issue29753>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
