Closed bob2oneil closed 2 years ago
@bob2oneil - it might help to reference a test case that can be easily reproducible. If a test case does not already exist, would you consider creating a PR with one?
It may not be possible to properly handle this issue without a minimal reproducible test, but that kind of test would typically be able to run in CI to avoid any future regressions.
cc @rlubos
Thanks for the response Chris, a test case does not yet exist, but I can create a minimal one to explore this raw socket to implementation mapping issue. Would it be sufficient to attach say a ZIP compressed file to this issue for tracking, or is a Pull Request required? As I understand GIT PR, it is typically submitted with proposed code to incorporate into the repo, for which I do not presently have a solution, only an observed problem.
@bob2oneil - a PR would be ideal
Doesn't a PR require change code that solves the problem? Currently, I have no idea as to why the 2 raw sockets, both associated with virtual Ethernet interfaces running on Native-POSIX, using the same create socket function, deviate when it comes to the mapping of the socket handle using POSIX networking APIs to the underlying implementation. That is, I do not fully understand the Zephyr networking stack architecture sufficient to provide a solution, I do not have years of experience using it nor domain knowledge in that area.
Currently, I have no idea as to why the 2 raw sockets
That is, I do not fully understand the Zephyr networking stack architecture sufficient to provide a solution
It's not expected from you to provide a solution. A simple test case however (likely an extension of existing tests/net/socket/af_packet
test suite) which allows to easily reproduce the issue would be a great starting point for us to find one. Ideally we could incorporate the test into the tree to avoid regressions in the future.
Thanks Robert, I will create a test case and attempt to use the PR mechanism to submit it. Presumably I would submit an entire Zephyr snapshot where the additions made by myself would just be this test case?
Presumably I would submit an entire Zephyr snapshot where the additions made by myself would just be this test case?
Yes, with git workflow you branch off from the main
branch (which is the current "snapshot" of Zephyr), and then add your commits on top (which in this case would be an extra test). From such a branch you can create a PR, unless one mess with the commit history, the PR should only contain your changes. The process is actually pretty well explained in our documentation, please see:
https://docs.zephyrproject.org/latest/contribute/#contribution-workflow
Also, @bob2oneil - if you use #
followed by any PR or Issue number, you create an automatic github reference, which is handy, so in your PR, remember to do that (in the commit message or in the web interface) to create a reference back here.
@bob2oneil please provide the information required.
I intend to submit a test case for this, have not had time to do that at the moment. It is still an important issue for me to resolve.
I intend to submit a test case for this, have not had time to do that at the moment. It is still an important issue for me to resolve.
@bob2oneil do you intend to pursue the resolution of this issue? Since it cannot be reproduced, you should either provide a test case or close the issue. Thanks!
I have tested this out with the Zephyr release that dates back maybe a week, and I believe it is fixed. I will close this out and will revisit it again should testing indicate that a problem remains.
I have tested this out with the Zephyr release that dates back maybe a week, and I believe it is fixed. I will close this out and will revisit it again should testing indicate that a problem remains.
Describe the bug I have a raw socket implementation on 2 virtual Ethernet interfaces using the Native-POSIX board target. The raw socket associated with the standard Ethernet interface, which also includes standard UDP and TCP listen sockets, no longer works properly with the latest Zephyr build as of Sept 7th, but I have observed this issue in previous versions.
What appears to happen is as shown in the callstack of the attached screenshot terminating in the zsock_recv_ctx() API for the failed raw socket read. This API does not support reads for raw sockets, so it would appear that perhaps the kernel configuration or runtime application settings is causing execution paths that are not expected?
The callstacks for the working and non-working raw socket interfaces shown in the following callstack excerpts between working and non-working implementations on different interfaces. It is clear that for the working raw socket, the 1st 2 lines differ from the non-working, so the callstack is simply different for 2 raw sockets. The POSIX read API as zsock_recv() goes to different flows for these two interfaces.
Specifically, the working L2 socket, calls zpacket APIs, while the non-working L2 socket calls zsock APIs.
Debugging involved walking into the POSIX recv() API for the working raw socket interface versus the non-working one to produce the callstacks.
To Reproduce Steps to reproduce the behavior:
Expected behavior Properly call stack routed behavior for raw socket on both virtual interfaces.
Impact Showstopper relative to raw socket operation.
Logs and console output
Working callstack for raw socket:
Failed callstack for non-working raw socket:
Environment (please complete the following information):
Additional context Kernel configuration is as follows:
Creation of socket method