-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dont recive ETP and TP messages. #228
Comments
How do you create the socket? Have a look at https://github.com/linux-can/can-utils/blob/master/j1939cat.c for a j1939 example. |
Good evening marckleinebudde, thanks for your attention.
I receive all messages as normal. However when the png is C8 or EC and the recipient is me, I don't get it. I only get paid when they go to broadcast. When I use candump, messages arrive normally. |
you filter setting looks incorrect:
Then, after J1939_PGN_ADDRESS_CLAIMED message, only after 250ms the kernel will start to forward message to the socket. Otherwise ECU address claiming process is not completed. |
One more issue, it is better to no mix as socket for address claiming, which needs broadcast support. And other sockets where broadcast is not needed. |
Hi @olerem, thanks for the attention. I made the changes to the filters and I still don't receive ETP messages. Any other PGN the socket receives and address confirmation message.
Regarding the socket for address claiming, I didn't quite understand. Can I have multiple sockets for the same address? |
Heh... silly me, i didn't noticed that you are trying to filter (E)TP CTRL messages. No, you will not get them in user space. The xTP are assembled in the kernel. The user-space will get assembled data. This PGNs should never go to the user space (except by using CAN_RAW socket):
Yes, you can have multiple sockets for the same address. You are even encouraged to do so. In fact, you can use existing j1939acd (adress claiming daemon), see: If you are using multiple sockets or applications for same NAME:
The kernel j1939 stack is designed to allow to use simplest programming model. Even using read()/write() calls should be enough for working application. |
@olerem so how do i get these messages? because to transfer the objectpool by ETP I need to receive the reply messages from the VT. When I try to send a message through sendto() with PGN 0xc800 the socket returns an error 33. Is it for the same reason? I can only send messages to PGN 0xc800 with cansend. |
Thanks for the clarifications, I was lost for a while kkkk it was bad if some questions are too silly, I'm starting now. |
You do not need to send TP control messages. The kernel will send it for you. You need to send only payload/data. |
Hi @olerem tanks for your help. I was able to send ob through the send () function. Some doubts:
|
One Note: Once all data of the initial
The kernel will receive the (E)TP control messages for your and handle them. What do you want to do with them? |
Hi @marckleinebudde thanks for the help, so i wanted to receive confirmation e-mail from vt (EoMA). I understand, so the send does not send the total on the first call? Sorry for the beginner's questions, things have started to become clear now. Thank you for your help. |
Keep in mind, the length indicated by the first If you want confirmation about EoMA, have a look at the https://github.com/linux-can/can-utils/blob/master/j1939cat.c - @olerem can probably elaborate on that. |
Seek for SCM_TSTAMP_ACK in j1939can.c SCM_TSTAMP_ACK - messages was completely transferred (confirmed by EoMA) This kernel code will send this ^ notifications to the user space: All notifications have a timestamp and a message cookie/tskey. The cookie/tskey is needed to identify which notification belongs to which message/payload. |
@marckleinebudde @olerem I understand now, thanks for the answers. I thought I would receive these control messages as normal messages. So I think my problem is another one, because the return of send () is the total number of bytes of the objectpool, however it returns the error 131 state not recoverable. |
can you please provide candump of you transmission? |
This would make no sense, since this socket interface allows you to queue multiple messages, you will not be able to map CTS, EoMA to which message it actually belong. |
hi @olerem my addrs is 96. |
I understand, it really wouldn't make any sense. |
Ok, i see. We have properly working start of transfer, but the session is aborted by transmitter:
Since abort was triggered really fast, I would assume, you stopped to feed the socket with the data. In this case the kernel log would show some errors. Can you please provide kernel log/dmesg. |
Good morning @HenriqueRicardoFigueira, can you create a log with strace[1] and candump at the same time and send the logs? [1] |
We analysed the candump a bit further, and the ETP is aborted after 4 transfers 0x40 messages which is 1792 bytes. @olerem will try to reproduce here, with the kernel stack which limits the number of messages to 0x40. |
I can reproduce it |
Good morning @marckleinebudde , of course, I will do it now. thanks for the help.
thanks for the help. |
As @olerem can reproduce the issue now, there's no need for a strace log. |
Ok |
@HenriqueRicardoFigueira BTW: What's the VT you're working with? |
@marckleinebudde I'm using a simulated network. |
If you want I can give you more details in an email. |
I'm interested. :) |
What is your email? |
Use the one from my github page: https://github.com/marckleinebudde |
@olerem has found the issue. It's due to the limitation of 0x40 frames per RTS/CTS cycle. We hope to have the fix on Monday. |
thanks for your help. @marckleinebudde @olerem |
Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
[ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
Source: Kernel.org MR: 105362 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: 154ccf69feca9751b2fd62dfca14d398bf687e4e Description: [ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Armin Kuster <akuster@mvista.com>
Source: Kernel.org MR: 105362 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: 154ccf69feca9751b2fd62dfca14d398bf687e4e Description: [ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Armin Kuster <akuster@mvista.com>
BugLink: https://bugs.launchpad.net/bugs/1893048 [ Upstream commit 840835c ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1893115 [ Upstream commit 840835c9281215341d84966a8855f267a971e6a3 ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
mainline inclusion from mainline-v5.9-rc2 commit 840835c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4CE CVE: CVE-2021-47232 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=840835c9281215341d84966a8855f267a971e6a3 -------------------------------- Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira <henrislip@gmail.com> Reported-by: linux-can/can-utils#228 Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
hi, I am testing the J1939 and I cannot receive messages from the transport protocol, however when I use candump the messages are arriving normally. I don't know if this is the right place for this kind of doubt, otherwise I apologize.
code to receive message
The text was updated successfully, but these errors were encountered: