Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 #159

josemic · 2019-10-24T19:09:27Z

I have installed linux kernel 5.4rc4, as described in this link on Ubuntu 19.10.

I go forward as desribed in can-j1939-kickstart.md.

sudo modprobe vcan
sudo ip link add can0 type vcan
sudo ip link set can0 up
sudo modprobe can-j1939

On terminal 1:
./testj1939 -r can0:
On terminal 2:
cansend can0 1823ff40#0123
Result:
No output on terminal 1.

On terminal 2:
cansend can0 18234140#0123

Result (on terminal1):
No output.

On terminal 1:
./testj1939 -r can0:0x80

On terminal 2:
cansend can0 18238040#0123

Result (on terminal 1):
40 02300: 01 23
Which was expected.

On terminal 1:
candump -L can0

On terminal 2:
./testj1939 -s can0:0x80,0x3ffff
Result (on terminal 2):
./testj1939: sendto: Permission denied

On terminal 2:
./testj1939 -s can0:0x90,0x3ffff

Result (on terminal 2):
./testj1939: sendto: Permission denied
On terminal 2:
./testj1939 -s can0:0x80,0x12345

Result (on terminal 2):
./testj1939: bind(): Invalid argument
On terminal 2:
./testj1939 -s can0:,0x12300 :0x40

Result (on terminal 2):
./testj1939: sendto: File descriptor in bad state

On terminal 2:
./testj1939 -s can0:0x80,0x12300 :,0x32100
Result (on terminal 2):
./testj1939: sendto: Permission denied
On terminal 2:
./testj1939 -s can0:0x80,0x12300 :0x40,0x32100
Result (on terminal 1):
(1571942859.574852) can0 1B214080#0123456789ABCDEF
Which was beside the timestamp expected.

On terminal 2:
./testj1939 -s20 can0:0x80 :,0x12300

Result (on terminal 2):
./testj1939: sendto: Permission denied
On terminal 2:
./testj1939 -w1.0 -s20 can0:0x80 :,0x12300

Result (on terminal 2):
./testj1939: sendto: Permission denied

On terminal 3:
./testj1939 can0:0x90 -r &

Result (on terminal 3):
[1] 27414

On terminal 2:
./testj1939 -s20 can0:0x80 :0x90,0x12300

Result (on terminal 3):

80 12300: 01 23 45 67 89 ab cd ef
00008     01 23 45 67 89 ab cd ef
00010     01 23 45 67

Result (on terminal 1 (candump)):

(1571943360.432011) can0 18EC9080#1014000303002301
(1571943360.432044) can0 18EC8090#110301FFFF002301
(1571943360.432057) can0 18EB9080#010123456789ABCD
(1571943360.432058) can0 18EB9080#02EF0123456789AB
(1571943360.432060) can0 18EB9080#03CDEF01234567FF
(1571943360.432077) can0 18EC8090#13000003FF002301

However, besides the timestamps expected was:

18EC9080#1014000303002301
18EC8090#110301FFFF002301
18EB9080#010123456789ABCD
18EB9080#02EF0123456789AB
18EB9080#03CDEF01234567
18EC8090#13140003FF002301

On terminal 2:
./testj1939 -s can0:0x80,0x0100

Result (on terminal 2):
./testj1939: sendto: Permission denied

On terminal 2:
./testj1939 -s -p3 can0:0x80,0x0200

Result (on terminal 2):
./testj1939: sendto: Permission denied

The text was updated successfully, but these errors were encountered:

olerem · 2019-10-25T09:56:31Z

Hi @josemic,

thank you for testing!
I can extract from you report 3 different issues:

send to broadcast is currently not supported by testj1939
EOMA message was send by kernel with total size set to 0
your expected example has no 0xff padding at the end of payload.

So, lets do it one by one:

i'll fix probably today.
A fix for the kernel bug is already send to the linux-can list. https://www.spinics.net/lists/linux-can/index.html (not jet listed :/ )
According to SAE J1939 spec:
"Each Data Transfer packet (other than the last packet in a transmission sequence) shall include 7 bytes of the original large message. The final packet includes a data field of 8 bytes: those being the sequence number of the packet and at least 1 byte of data related to the Parameter Group and then any remaining unused bytes set to “FF 16 .”
I assume there is a typo in the expectation example.

josemic · 2019-10-26T21:36:34Z

Hi @olerem,

If you are refferring with 3. to the following, then I get the same result as before (except of the timestamp):
On terminal 1:
candump -L can0

On terminal 2:

./testj1939 can0:0x90 -r &
[1] 15741

On terminal 3:
./testj1939 -s20 can0:0x80 :0x90,0x12300

Output on terminal 1:

(1572125047.692271) can0 18EC9080#1014000303002301
(1572125047.692305) can0 18EC8090#110301FFFF002301
(1572125047.692317) can0 18EB9080#010123456789ABCD
(1572125047.692318) can0 18EB9080#02EF0123456789AB
(1572125047.692320) can0 18EB9080#03CDEF01234567FF
(1572125047.692335) can0 18EC8090#13000003FF002301

Output on terminal 3:

80 12300: 01 23 45 67 89 ab cd ef
00008     01 23 45 67 89 ab cd ef
00010     01 23 45 67

If you are referring with 3. to something else, please let me know to what you are refferring.

olerem · 2019-10-27T05:11:33Z

Hi @josemic ,
i refer to your comment:

However, besides the timestamps expected was:
18EC9080#1014000303002301
18EC8090#110301FFFF002301
18EB9080#010123456789ABCD
18EB9080#02EF0123456789AB
18EB9080#03CDEF01234567

Int this line you are missing FF on the end ^

18EC8090#13140003FF002301

On this line you are spotted real bug ^

josemic · 2019-10-27T12:01:05Z

Hi @olerem,

to 1:
Please let me know, when you have fixed "testj1939.c". I may test it again.

to 3:

Int this line you are missing FF on the end ^

This was not my copy and paste error. This comes directly from "can-j1939-kickstart.md". Please note that this occurs twice in "can-j1939-kickstart.md". Could you please patch "can-j1939-kickstart.md"?

marckleinebudde · 2019-10-30T13:08:22Z

@josemic
Feel free to send a patch for the kickstart yourself. I think you can edit it directly via the github web interface.

josemic · 2019-10-30T18:31:06Z

@marckleinebudde
Done. Yes. Editing via github web interface is stupid simple! Thanks for the hint.

josemic · 2019-10-30T21:46:05Z

I am trying the address claiming daemon jacd and I get the following result:

./jacd 3102032E003D0080
jacd: bindtodevice can0: Operation not permitted

I have CAN initilized with:

sudo modprobe vcan
sudo ip link add can0 type vcan
sudo ip link set can0 up
sudo modprobe can-j1939

What am I doing wrong?

josemic · 2019-11-01T00:06:05Z

I have upgraded to kernel 5.4rc5. Still the same errors.

Jacd also fails:

jacd -r 100,80-120 -v -c /tmp/1122334455667788.jacd 1122334455667788
jacd: ready for can0:1122334455667788
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, can0, 4);
jacd: bindtodevice can0: Operation not permitted

…end with the total message size set We were sending malformed EOMA messageswith total message size set to 0. This patch fixes the bug. Reported-by: linux-can/can-utils#159 Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

josemic · 2019-11-09T16:35:15Z

I have upgraded to kernel 5.4rc6. Still the same errors.

olerem · 2019-11-09T17:13:39Z

Works for me:

root@DistroKit:~/tests/j1939 jacd -r 100,80-120 -v -c /tmp/1122334455667788.jacd
 1122334455667788
jacd: ready for can0:1122334455667788
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, can0, 4);
- setsockopt(, SOL_CAN_J1939, SO_J1939_FILTER, <filter>, 96);
- setsockopt(, SOL_SOCKET, SO_BROADCAST, 1, 4);
- bind(, can0:1122334455667788, 24);
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, can0, 4);
- setsockopt(, SOL_CAN_J1939, SO_J1939_FILTER, <filter>, 96);
- setsockopt(, SOL_SOCKET, SO_BROADCAST, 1, 4);
- bind(, can0:1122334455667788, 24);
- sendto(, { 0, 0xee, 0, }, 3, 0, -,0ea00, 24);
jacd: request sent, pending for 1250 ms

- bind(, can0:1122334455667788, 24);
- send(, 1234605616436508552, 8, 0);
jacd: claimed 0x50

Do you actually have can0 interface? is it configured?

josemic · 2019-11-09T18:35:01Z

Hi @olerem,

I have configured can0 as following, is this sufficient?

sudo modprobe vcan
sudo ip link add can0 type vcan
sudo ip link set can0 up
sudo modprobe can-j1939

I have updated can-utils/jacd to the latest version.

./jacd -r 100,80-120 -c /tmp/1122334455667788.jacd 1122334455667788
jacd: bindtodevice can0: Operation not permitted

and with -v option:

./jacd -r 100,80-120 -v -c /tmp/1122334455667788.jacd 1122334455667788
jacd: ready for can0:1122334455667788: No such file or directory

olerem · 2019-11-09T19:28:24Z

Hm.. i reproduced it after switching to not root mode.
Can you please try with sudo.

@marckleinebudde, we need to think about permissions

josemic · 2019-11-10T10:10:24Z

@olerem:
With sudo and only latest can-utils it works without -v option.

sudo ./jacd -r 100,80-120 -c /tmp/1122334455667780.jacd 1122334455667780

Result is:

candump -L can0

(1573379833.419543) can0 18EAFFFE#00EE00
(1573379834.669767) can0 18EEFF50#8077665544332211

and with -v option:

sudo ./jacd -r 100,80-120 -v -c /tmp/1122334455667781.jacd 1122334455667781
jacd: ready for can0:1122334455667781: No such file or directory

and with -v option and previous temp file:

sudo ./jacd -r 100,80-120 -v -c /tmp/1122334455667780.jacd 1122334455667781
jacd: ready for can0:1122334455667781: Success

and strangely the prompt returns and candump output is empty:
candump -L can0
however without -v option:

sudo ./jacd -r 100,80-120 -c /tmp/1122334455667780.jacd 1122334455667781

prompt does not return and candump output is:

candump -L can0
(1573380419.254651) can0 18EAFFFE#00EE00
(1573380420.504910) can0 18EEFF50#8177665544332211

olerem · 2019-11-10T11:31:44Z

@josemic , sorry, i can't confirm it:

ore@DistroKit:/root/tests/j1939 sudo candump -t d vcan0 &
ore@DistroKit:/root/tests/j1939 sudo jacd -r 100,80-120 -c /tmp/1122334455667780.jacd 1122334455667780 vcan0 &
ore@DistroKit:/root/tests/j1939  (000.000000)  vcan0  18EAFFFE   [3]  00 EE 00
 (001.251263)  vcan0  18EEFF50   [8]  80 77 66 55 44 33 22 11

ore@DistroKit:/root/tests/j1939 
ore@DistroKit:/root/tests/j1939 sudo jacd -r 100,80-120 -v -c /tmp/1122334455667
781.jacd 1122334455667781 vcan0
jacd: ready for vcan0:1122334455667781
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, vcan0, 5);
- setsockopt(, SOL_CAN_J1939, SO_J1939_FILTER, <filter>, 96);
- setsockopt(, SOL_SOCKET, SO_BROADCAST, 1, 4);
- bind(, vcan0:1122334455667781, 24);
- socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
- setsockopt(, SOL_SOCKET, SO_BINDTODEVICE, vcan0, 5);
- setsockopt(, SOL_CAN_J1939, SO_J1939_FILTER, <filter>, 96);
- setsockopt(, SOL_SOCKET, SO_BROADCAST, 1, 4);
- bind(, vcan0:1122334455667781, 24);
- sendto(, { 0, 0xee, 0, }, 3, 0, -,0ea00, 24);
 (024.153737)  vcan0  18EAFFFE   [3]  00 EE 00
 (000.000381)  vcan0  18EEFF50   [8]  80 77 66 55 44 33 22 11
jacd: request sent, pending for 1250 ms
- bind(, vcan0:1122334455667781, 24);
- send(, 1234605616436508545, 8, 0);
 (001.250995)  vcan0  18EEFF51   [8]  81 77 66 55 44 33 22 11
jacd: claimed 0x51

josemic · 2019-11-10T22:02:55Z

@olerem: Now it looks a little bit different (note: I changed vcan0 to can0):

On terminal 1:
sudo candump -t d can0

On terminal 2:

sudo jacd -r 100,80-120 -c /tmp/1122334455667780.jacd 1122334455667780 can0 
jacd: send request for address claims: Permission denied

No output on terminal 1.

Looks still like a permission problem. Could it be that the signal handler in jacd is running without su rights?

josemic · 2019-11-11T21:08:12Z

@olerem:
I have deinstalled the ubuntu can-utils package with "sudo apt remove can-utils".
Now when using the latest can-utils from git it seems to work better.
Still I have 2 findings:

when the command is called with an & at the end of the line, the command does not work, as the password is not queried. When removing the "&", the password is queried.
when using the jacd -v option the command mostly fails with the message "No such file or directory"

sudo ./jacd -r 100,80-120 -v -c /tmp/1122334455667781.jacd 1122334455667781 can0
jacd: ready for can0:1122334455667781: No such file or directory

Sometimes also "success" is printed, but noting else and no candump output is generated. Also the prompt returns immediately:

sudo ./jacd -r 100,80-120 -v -c /tmp/1122334455667780.jacd 1122334455667780 can0
jacd: ready for can0:1122334455667780: Success

Terminal 1:

sudo ./candump -t d can0
 (012.914322)  can0  18EAFFFE   [3]  00 EE 00
 (000.000000)  can0  18EAFFFE   [3]  00 EE 00
 (001.250182)  can0  18EEFF51   [8]  81 77 66 55 44 33 22 11
 (001.250182)  can0  18EEFF51   [8]  81 77 66 55 44 33 22 11
 (023.529740)  can0  18EAFFFE   [3]  00 EE 00
 (023.529740)  can0  18EAFFFE   [3]  00 EE 00
 (000.000126)  can0  18EEFF51   [8]  81 77 66 55 44 33 22 11
 (000.000126)  can0  18EEFF51   [8]  81 77 66 55 44 33 22 11
 (001.250293)  can0  18EEFF50   [8]  80 77 66 55 44 33 22 11
 (001.250293)  can0  18EEFF50   [8]  80 77 66 55 44 33 22 11

Somehow the address claim seems to be doubled.

Terminal 2:
sudo ./jacd -r 100,80-120 -c /tmp/1122334455667781.jacd 1122334455667781 can0

Terminal 3:
sudo ./jacd -r 100,80-120 -c /tmp/1122334455667780.jacd 1122334455667780 can0

josemic · 2019-11-20T23:19:08Z

I have upgraded to kernel 5.4rc8. Still the same errors.

@olerem:
Furthermore I have noticed that networking/j1939.rst
referes to J1939_PGN_ADDRESS_REQUEST, however "j1939.h" defines only:
#define J1939_PGN_REQUEST 0x0ea00

Thus this patch is missing for j1939.h:
Link to patch

and networking/j1939.rst needs to be changed as following:

const struct j1939_filter filt[] = {
        {
                .pgn = J1939_PGN_ADDRESS_CLAIMED,
                .pgn_mask = J1939_PGN_PDU1_MAX,
        }, {
-                .pgn = J1939_PGN_ADDRESS_REQUEST, /* remove this line*/
+                .pgn = J1939_PGN_REQUEST,         /* add this line */
                .pgn_mask = J1939_PGN_PDU1_MAX,
        }, {
                .pgn = J1939_PGN_ADDRESS_COMMANDED,
                .pgn_mask = J1939_PGN_MAX,
        },
};

josemic · 2019-11-25T21:05:42Z

I have upgraded to kernel 5.4. Still the same errors.

olerem · 2019-11-26T07:03:18Z

@josemic , we have limited resources to fix all found bugs. For now I was able to spend a fix to respond on critical issues reported by google syzbot. Now I need to work on other projects and will be able to spends some time once a week. It is not match, but if you provide effective bug reports, I'll be able to handle them.

Please, separate different issues to different bug reports. I already lost a track of what is actually not working for you. If I answer you that I'm not able to reproduce it, then it is really the case. And I will need a help to reproduce it. Doing regular status report of kernel x.y.z will not help. Only in case I or some one else will write here, this bug was solved by patch X, then it will be time to test it.

If you have time to fix your issue, please do it. It is opensource project and it works only if all who use it participate in fixing bugs and extend functionality.

josemic · 2019-11-27T21:41:14Z

I have upgraded to kernel 5.4. Still the same errors.

This refers to usage of testj1939.c and especially to you following message.

Hi @josemic,

thank you for testing!
I can extract from you report 3 different issues:

1. send to broadcast is currently not supported by testj1939

2. EOMA message was send by kernel with total size set to 0

3. your expected example has no 0xff padding at the end of payload.

So, lets do it one by one:

1. i'll fix probably today.

2. A fix for the kernel bug is already send to the linux-can list. https://www.spinics.net/lists/linux-can/index.html (not jet listed :/ )

3. According to SAE J1939 spec:
   "Each Data Transfer packet (other than the last packet in a transmission sequence) shall include 7 bytes of the original large message. The final packet includes a data field of 8 bytes: those being the sequence number of the packet and at least 1 byte of data related to the Parameter Group and then any remaining unused bytes set to “FF 16 .”
   I assume there is a typo in the expectation example.

I have upgraded to kernel 5.4. Still the same errors: 1., 2. & 3. I expected that you have fixed 1.

Let this bug #159 refer only to the above testj1939.c issues, I have for the other issue created the bugs #173 and #174.

olerem · 2019-11-29T13:20:17Z

Hi @josemic ,
this pull request should address some of reported issues: #175

josemic · 2019-11-29T22:31:28Z

Hi @olerem,
I have made a minor editorial comment on the pull request. I have tested olerem:testj1938 and it works as expected on kernel 5.4 ubuntu.

josemic · 2019-12-01T11:33:08Z

When testing the priorities, I noticed, that for the priorities 0 and 1, the message occurs, that setting the priority is not permitted:

./testj1939 -B -s -p3 vcan0:0x80 :,0x0200

Works ok.

./testj1939 -B -s -p1 vcan0:0x80 :,0x0200
testj1939: set priority 1: Operation not permitted

./testj1939 -B -s -p0 vcan0:0x80 :,0x0200
testj1939: set priority 0: Operation not permitted

I am not aware that the priorities 0 & 1 are not permitted.

marckleinebudde · 2019-12-01T11:40:28Z

I am not aware that the priorities 0 & 1 are not permitted.

Priorities 0 and 1 are only permitted for root or users with capable(CAP_NET_ADMIN), see:

https://elixir.bootlin.com/linux/latest/source/net/can/j1939/socket.c#L705

I think this limit is arbitrary and we can discuss if this makes sense at all or add this to the documentation.

josemic · 2019-12-02T22:53:54Z

@marckleinebudde :
At least in the ISOBUS standard I am not aware the the priorities 0 an 1 require special handling compared to the other priorities 2-7. I am not aware, if this is the case for the other J1939 based standards. However if this is not the case, I recommend to remove the root requirements and capabilities requirement CAP_NET_ADMIN for the priorities 0 and 1.
As I am not familiar with the usage of capabilities, could you please explain how to set the capabilities CAP_NET_ADMIN for the command line or any userspace program.

marckleinebudde · 2019-12-06T11:53:11Z

https://unix.stackexchange.com/questions/389879/how-to-set-capabilities-with-setcap-command

marckleinebudde · 2019-12-08T10:29:39Z

On github a question[1] about j1939 priorities popped up:

On 12/2/19 11:53 PM, josemic wrote: At least in the ISOBUS standard I am not aware the the priorities 0 an 1 require special handling compared to the other priorities 2-7. I am not aware, if this is the case for the other J1939 based standards. However if this is not the case, I recommend to remove the root requirements and capabilities requirement CAP_NET_ADMIN for the priorities 0 and 1. As I am not familiar with the usage of capabilities, could you please explain how to set the capabilities CAP_NET_ADMIN for the command line or any userspace program.

[1] #159 (comment) Marc

During development the define J1939_PGN_ADDRESS_REQUEST was renamed to J1939_PGN_REQUEST. It was forgotten to adjust the documentation accordingly. This patch fixes the name of the symbol. Reported-by: linux-can/can-utils#159 (comment) Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

commit 8ac9d71 upstream. During development the define J1939_PGN_ADDRESS_REQUEST was renamed to J1939_PGN_REQUEST. It was forgotten to adjust the documentation accordingly. This patch fixes the name of the symbol. Reported-by: linux-can/can-utils#159 (comment) Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

josemic · 2020-05-30T13:57:40Z

I have retested with Ubuntu 20.04, the procedures described in can-j1939-kickstart.md. They are working now.
Tested with the following kernel:

uname -a
Linux michael-ThinkPad-T430 5.4.0-33-lowlatency #37-Ubuntu SMP PREEMPT Thu May 21 14:16:07 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

josemic · 2020-05-30T14:13:49Z

I have created a new issue for the priorities root requirements with #217. As this was the last topic with this issue #159, we can close #159.

…end with the total message size set mainline inclusion from mainline-v5.4-rc7 commit eaa654f category: bugfix bugzilla: 38684 CVE: NA --------------------------- We were sending malformed EOMA messageswith total message size set to 0. This patch fixes the bug. Reported-by: linux-can/can-utils#159 Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>

mainline inclusion from mainline-v5.5-rc3 commit 8ac9d71 category: feature bugzilla: 38684 CVE: NA --------------------------- During development the define J1939_PGN_ADDRESS_REQUEST was renamed to J1939_PGN_REQUEST. It was forgotten to adjust the documentation accordingly. This patch fixes the name of the symbol. Reported-by: linux-can/can-utils#159 (comment) Fixes: 9d71dd0 ("can: add support of SAE J1939 protocol") Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>

hartkopp mentioned this issue Oct 25, 2019

Networking with CAN-J1939 support (Manjaro Linux) #158

Closed

josemic changed the title ~~Networking with CAN-J1939 support (Ubuntu Linux)~~ Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 Nov 27, 2019

This was referenced Nov 27, 2019

Networking with CAN-J1939 support (Ubuntu Linux) jacd.c usage #173

Closed

Networking with CAN-J1939 support - documentation networking/j1939.rst #174

Closed

josemic mentioned this issue May 30, 2020

J1939 messages not sent/received in Ubuntu 20.04 (Kernel 5.4) #212

Closed

josemic mentioned this issue May 30, 2020

j1939 - Remove root requirements for messages with the priorities 0 & 1 #217

Open

josemic closed this as completed May 30, 2020

janaranjanahl mentioned this issue Nov 9, 2022

JACD : address claim does not work in Linux #383

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 #159

Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 #159

josemic commented Oct 24, 2019 •

edited by marckleinebudde

Loading

olerem commented Oct 25, 2019

josemic commented Oct 26, 2019 •

edited

Loading

olerem commented Oct 27, 2019

josemic commented Oct 27, 2019 •

edited

Loading

marckleinebudde commented Oct 30, 2019

josemic commented Oct 30, 2019

josemic commented Oct 30, 2019

josemic commented Nov 1, 2019

josemic commented Nov 9, 2019

olerem commented Nov 9, 2019 •

edited

Loading

josemic commented Nov 9, 2019 •

edited

Loading

olerem commented Nov 9, 2019

josemic commented Nov 10, 2019

olerem commented Nov 10, 2019

josemic commented Nov 10, 2019 •

edited

Loading

josemic commented Nov 11, 2019

josemic commented Nov 20, 2019 •

edited

Loading

josemic commented Nov 25, 2019

olerem commented Nov 26, 2019

josemic commented Nov 27, 2019

olerem commented Nov 29, 2019

josemic commented Nov 29, 2019

josemic commented Dec 1, 2019

marckleinebudde commented Dec 1, 2019 •

edited

Loading

josemic commented Dec 2, 2019

marckleinebudde commented Dec 6, 2019

marckleinebudde commented Dec 8, 2019 via email

josemic commented May 30, 2020

josemic commented May 30, 2020

Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 #159

Networking with CAN-J1939 support (Ubuntu Linux) ./testj1939 #159

Comments

josemic commented Oct 24, 2019 • edited by marckleinebudde Loading

olerem commented Oct 25, 2019

josemic commented Oct 26, 2019 • edited Loading

olerem commented Oct 27, 2019

josemic commented Oct 27, 2019 • edited Loading

marckleinebudde commented Oct 30, 2019

josemic commented Oct 30, 2019

josemic commented Oct 30, 2019

josemic commented Nov 1, 2019

josemic commented Nov 9, 2019

olerem commented Nov 9, 2019 • edited Loading

josemic commented Nov 9, 2019 • edited Loading

olerem commented Nov 9, 2019

josemic commented Nov 10, 2019

olerem commented Nov 10, 2019

josemic commented Nov 10, 2019 • edited Loading

josemic commented Nov 11, 2019

josemic commented Nov 20, 2019 • edited Loading

josemic commented Nov 25, 2019

olerem commented Nov 26, 2019

josemic commented Nov 27, 2019

olerem commented Nov 29, 2019

josemic commented Nov 29, 2019

josemic commented Dec 1, 2019

marckleinebudde commented Dec 1, 2019 • edited Loading

josemic commented Dec 2, 2019

marckleinebudde commented Dec 6, 2019

marckleinebudde commented Dec 8, 2019 via email

josemic commented May 30, 2020

josemic commented May 30, 2020

josemic commented Oct 24, 2019 •

edited by marckleinebudde

Loading

josemic commented Oct 26, 2019 •

edited

Loading

josemic commented Oct 27, 2019 •

edited

Loading

olerem commented Nov 9, 2019 •

edited

Loading

josemic commented Nov 9, 2019 •

edited

Loading

josemic commented Nov 10, 2019 •

edited

Loading

josemic commented Nov 20, 2019 •

edited

Loading

marckleinebudde commented Dec 1, 2019 •

edited

Loading