From: Daniel Squires <dan@engineeredarts.co.uk>
To: Marc Kleine-Budde <mkl@pengutronix.de>, linux-can@vger.kernel.org
Subject: Re: socket can receive order
Date: Tue, 08 Sep 2015 11:41:18 +0100 [thread overview]
Message-ID: <55EEBB4E.6080104@engineeredarts.co.uk> (raw)
In-Reply-To: <55EEB217.3080706@pengutronix.de>
Hi Marc,
I should have mentioned that this "issue" seems to only show up on our
application PC, (which is an Intel NUC).
On my laptop and Desktop PC I have not seen it happen.
Both the application PC (NUC) and the Laptop are running Ubuntu kernel
3.19.0-26-generic
The NUC has the kernel rebuilt without xhci due to problems it causes
with another USB peripheral.
I am not entirely sure what you mean by which can core I am using but if
it helps i am opening the socket as follows :
sock = socket(PF_CAN,SOCK_RAW,CAN_RAW);
in a small standalone test application which I wrote after having
difficulty with our main application.
I am using custom hardware/firmware and am using the kernel module found
here : https://github.com/fabiobaltieri/open-usb-can
though it has a small change to stop the net queue at the top of
open_usb_can_start_xmit as otherwise its prone to loosing TX packets
when loaded.
I can see the packets coming in the correct order in wireshark and it is
not immediately obvious to me how the kernel module could mix up the
order, so it seems that it must be something that happens at the socket
level?
On the top level I am using CANFestival for CANOpen implementation, so
it has occurred to me I could implement a CANFestival "driver" using
libusb and completely bypass the kernel module and socket can layers,
but I hope not to have to do this.
On 08/09/15 11:01, Marc Kleine-Budde wrote:
> On 09/08/2015 11:42 AM, Daniel Squires wrote:
>> Hi all,
>>
>> new to this list.
>>
>> Just a quick question at present, when using recv on a socket that is
>> bound to a can interface, should the packets be received in the order
>> they came off the wire? or is this not guaranteed?
> Should be guaranteed. Which CAN core are you using? What's your kernel
> version?
>
> Marc
>
--
Dan Squires
Engineered Arts Ltd.
next prev parent reply other threads:[~2015-09-08 10:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 9:42 socket can receive order Daniel Squires
2015-09-08 10:01 ` Marc Kleine-Budde
2015-09-08 10:41 ` Daniel Squires [this message]
2015-09-08 11:13 ` Marc Kleine-Budde
2015-09-08 11:17 ` Daniel Squires
2015-09-08 11:20 ` Marc Kleine-Budde
2015-09-08 11:37 ` Daniel Squires
2015-09-08 16:56 ` Oliver Hartkopp
2015-09-09 2:30 ` Austin Schuh
2015-09-09 3:10 ` Brian Silverman
2015-09-09 16:23 ` Oliver Hartkopp
2015-09-09 12:05 ` Daniel Squires
2015-09-09 16:14 ` Daniel Squires
2015-09-09 16:31 ` Oliver Hartkopp
2015-09-17 19:18 ` Oliver Hartkopp
2015-09-08 11:46 ` Wolfgang Grandegger
2015-09-08 11:49 ` Daniel Squires
2015-09-08 11:56 ` Marc Kleine-Budde
2015-09-10 2:29 ` Tom Evans
2015-09-10 8:08 ` Daniel Squires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EEBB4E.6080104@engineeredarts.co.uk \
--to=dan@engineeredarts.co.uk \
--cc=linux-can@vger.kernel.org \
--cc=mkl@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).