Re: recv list

Re: recv list

[Kurt Van Dijck]

On Mon, Jan 09, 2012 at 10:46:17AM +0000, Wolfgang wrote:
> Hi,
> 
> now it is saying 'sendto failed: Machine is not on the network', when I am 
> sending a message with id 0x15FFD000
I think what happens is that your engine ECU (0x00) does address claiming.
During recvfrom, its 8byte name is returned in src_addr too.
Since that name has not been seen on the second network, you get an error.

Try clearing the destination NAME by:

> 
> 		len = sizeof(src_addr);
> 		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
> 		
> 		
> 		if (ret < 0)
> 		perror ("recvfrom failed");
> 		
> 		src_addr.can_addr.j1939.addr = J1939_NO_ADDR;

+ 		src_addr.can_addr.j1939.name = J1939_NO_NAME;

> 
> 		
> 			if (sendto(s2, buf, ret, 0, (void *)&src_addr, len) < 0)
> 				perror("sendto failed");
> 						
> 	}
> 

Kurt

Re: recv list

[Wolfgang]

> I think what happens is that your engine ECU (0x00) does address claiming.
I am using on both interfaces a simulator tool, so I think there is not ac.

> During recvfrom, its 8byte name is returned in src_addr too.

		printf("%lld\n", src_addr.can_addr.j1939.name);

after recvfrom is returning always a '0'

> Since that name has not been seen on the second network, you get an error.
> 
> Try clearing the destination NAME by:

I have cleared the name but it is still saying 'sendto failed: Machine is not 
on the network'. By the way 'recv' and 'send' is working. 


--Wolfgang

Re: recv list

[Kurt Van Dijck]

On Mon, Jan 09, 2012 at 04:35:08PM +0000, Wolfgang wrote:
> > I think what happens is that your engine ECU (0x00) does address claiming.

I take back this conclusion. I looked again, and came on this:
clear the src_addr.can_ifindex, since that's for sure wrong when bridging.

Sorry for the overhead ...
Kurt

Re: recv list

[Wolfgang]

> I take back this conclusion. I looked again, and came on this:
> clear the src_addr.can_ifindex, since that's for sure wrong when bridging.

It is working, thanks.
As far as I can judge this, your patch is also working I can bind different 
sockets on one interface, and then send with different src addr.


> In a later iteration, You could (if necessary, since I have no clue what kind
> of traffic you will bridge):
> * make the receiving socket (s) 'promiscuous', i.e. receiving all traffic.
> * fetch the original destination by using recvmsg() as illustrated in jspy

OK, I think I am that far, making one socket promiscuous and than depending 
on the source address send it with the corresponding socket.
Is there any 'easy' iteration, of that. Or do I have to rebuild the jspy.c, 
libj1939.c, libj1939.h according to my wishes?


Thanks so far.

Kind regards,

Wolfgang

Re: recv list

[Kurt Van Dijck]

On Tue, Jan 10, 2012 at 10:45:30AM +0000, Wolfgang wrote:
> > I take back this conclusion. I looked again, and came on this:
> > clear the src_addr.can_ifindex, since that's for sure wrong when bridging.
> 
> It is working, thanks.
> As far as I can judge this, your patch is also working I can bind different 
> sockets on one interface, and then send with different src addr.
Thanks for testing!
> 
> 
> > In a later iteration, You could (if necessary, since I have no clue what kind
> > of traffic you will bridge):
> > * make the receiving socket (s) 'promiscuous', i.e. receiving all traffic.
> > * fetch the original destination by using recvmsg() as illustrated in jspy
> 
> OK, I think I am that far, making one socket promiscuous and than depending 
> on the source address send it with the corresponding socket.
> Is there any 'easy' iteration, of that. Or do I have to rebuild the jspy.c, 
> libj1939.c, libj1939.h according to my wishes?

jspy just serves as illustration here. I don't think you will need the binary.
But I consider using recvmsg() a bit complicated, easily forgotten ...

Kind regards,
Kurt

promiscuous mode

[Wolfgang]

static struct {
	struct sockaddr_can src;
	int pkt_len;
} ss = {
	.pkt_len = 1024,
	.src.can_addr.j1939 = {
		.name = J1939_NO_NAME,
		.addr = J1939_NO_ADDR,
		.pgn = J1939_NO_PGN,
	},
};


int main (void)
{
	
	int s;
	s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	    
	struct sockaddr_can addr;

    memset(&addr, 0, sizeof(addr));
    addr.can_ifindex = ss.src.can_ifindex;
    addr.can_addr.j1939.name = J1939_NO_NAME;    
    addr.can_addr.j1939.addr = J1939_NO_ADDR;
    addr.can_addr.j1939.pgn = J1939_NO_PGN;
    addr.can_family = AF_CAN;  
   
   
    if (bind(s, (void *)&addr, sizeof(addr))<0)
    	   		perror ("bind failed");
    	   	else
        		printf("bind of promiscuous socket successful\n");
        		     		
        		   	       	       	
    int s2;
	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	
	struct sockaddr_can addr2;	
	   
    memset(&addr2, 0, sizeof(addr2));
    addr2.can_ifindex = if_nametoindex("can1");
    addr2.can_addr.j1939.name = J1939_NO_NAME;    
    addr2.can_addr.j1939.addr = 0x3d;
    addr2.can_addr.j1939.pgn = J1939_NO_PGN;
    addr2.can_family = AF_CAN;     
   
    if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
    	   		perror ("bind2 failed");
        	else
        		printf("bind of s2 on can1 addr 0x3d successful\n");
        		
        		
    int ret;
	socklen_t len; 
	struct sockaddr_can src_addr;
	char buf[128];
;
	
	
	while (1)
	 {
			
			len = sizeof(src_addr);
			ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
			if (ret < 0)
			perror ("recvfrom failed");
		
		}
			
	}					
	

  		 
  return 0;
}

It is working, is it possible to use it or do I have to use recvmsg, because
when I do sendto it is receiving the sent message again and again or is it
possible to clear the buffer somehow? Recvmsg is working as well but how do I 
have to change the sendto, 'sendto failed: Invalid argument'?


	
	static char ctrlmsg[
	CMSG_SPACE(sizeof(uint8_t)) /* dest addr */
	+ CMSG_SPACE(sizeof(uint64_t)) /* dest name */
	+ CMSG_SPACE(sizeof(uint8_t)) /* priority */
	];
	
static struct {
	struct sockaddr_can addr;
	int pkt_len;
} s = {
	.pkt_len = 1024,
	.addr.can_addr.j1939 = {
		.name = J1939_NO_NAME,
		.addr = J1939_NO_ADDR,
		.pgn = J1939_NO_PGN,
	},
};

int main (void)
{
   int sock, ret, j;
   unsigned int len;
   struct msghdr msg;
   struct iovec iov;
   static uint8_t *buf;
   struct sockaddr_can src;

	socklen_t leng; 
   
   
   	buf = malloc(s.pkt_len);
	if (!buf)
		error(1, errno, "malloc %u", s.pkt_len);
   
   sock = socket(PF_CAN,SOCK_DGRAM,CAN_J1939);
      
   
   memset(&src, 0, sizeof(src));
   src.can_ifindex = s.addr.can_ifindex;
   src.can_family = AF_CAN;
   src.can_addr.j1939.name = J1939_NO_NAME;
   src.can_addr.j1939.addr = J1939_NO_ADDR;
   src.can_addr.j1939.pgn = J1939_NO_PGN;
   
   bind(sock,(void*)&src,sizeof(src));
   len = sizeof(src);
   
   iov.iov_base = &buf[0];
   msg.msg_name = &src;
   msg.msg_iov = &iov;
   msg.msg_iovlen = 1;
   msg.msg_control = &ctrlmsg;
   
   msg.msg_namelen = len;
   
   
       int s2;
	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	
	struct sockaddr_can addr2;	
	   
    memset(&addr2, 0, sizeof(addr2));
    addr2.can_ifindex = if_nametoindex("can1");
    addr2.can_addr.j1939.name = J1939_NO_NAME;    
    addr2.can_addr.j1939.addr = 0x3d;
    addr2.can_addr.j1939.pgn = J1939_NO_PGN;
    addr2.can_family = AF_CAN;     
   
    if (bind(s2, (void *)&addr2, sizeof(addr2))<0)
    	   		perror ("bind2 failed");
        	else
        		printf("bind of s2 on can1 addr 0x3d successful\n");

   
   
	while (1) {
		/* these settings may be modified by recvmsg() */
		iov.iov_len = s.pkt_len;
		msg.msg_namelen = sizeof(src);
		msg.msg_controllen = sizeof(ctrlmsg);
		msg.msg_flags = 0;

		ret = recvmsg(sock, &msg, 0);
		
		
		len = ret;
		

			
			if ((sendto(s2, buf, ret, 0, (void *)&src, leng))<0);
			perror("sendto failed");
			
			
		
		}
		free(buf);
	
		
	return 0;
}

Thanks
Best regards,
Wolfgang

bridge

[Kurt Van Dijck]

Wolfgang,

I'm afraid I don't full understand the problem now.
Promiscuous mode means that PGNs not destined for you
are received also. It is not needed to catch broadcasted
traffic. Sorry for the noise about that.

Based on the 2 programs, I see no advantage in the use of recvmsg(),
since you're not using any of the extra functionality.

So far, use the first program as a reference.
Instead of modifying your source, I'll shortly describe the headlines
that I think I would use.

so:
	int ret, s1, s2;
 	socklen_t len; 
 	struct sockaddr_can src_addr;
 	char buf[128];

	struct sockaddr_can src_addr = {
		.can_family = AF_CAN,
		.can_addr.j1939 = {
			.addr = J1939_NO_ADDR,
			.pgn = J1939_NO_PGN,
			.name = J1939_NO_NAME,
		},
	};

	src_addr.can_ifindex = if_nametoindex("can0");
	dest_addr.can_ifindex = if_nametoindex("can1");

	s1 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	if (s1 < 0)
		perror("...");
	ret = bind(s1, (void *)&src_addr, sizeof(src_addr));
	if (ret < 0)
		perror("...");

	s2 = socket(PF_CAN, SOCK_DGRAM, CAN_J1939);
	if (s2 < 0)
		perror("...");
	/* no bind for s2 yet */

	while (1) {
		len = sizeof(src_addr);
 		ret = recvfrom(s, buf, sizeof(buf), 0, (void *)&src_addr, &len);
 		if (ret < 0)
 			perror ("recvfrom failed");
		/*
		 * OK, we got a PGN, of size 'ret' and originating
		 * from src_addr.can_ifindex, using SA src_addr.can_addr.j1939.addr
		 * and PGN src_addr.can_addr.j1939.pgn
		 *
		 * We need to use this info in s2 to be used as source for this PGN
		 * except for the can_ifindex member, since it's the other ifindex.
		 */

		/* clear the  ifindex */
		src_addr.can_ifindex = 0;
		if (bind(s2, (void *)&src_addr, sizeof(src_addr)) < 0)
			perror("...");

		/* s2 is now ready */
 		if (send(s2, buf, ret, 0)) < 0);
			perror("sendto failed");
	}

since my commits a few days ago, calling bind() with different source addresses is
now possible.

Kind regards,
Kurt

Re: recv list

[Wolfgang]

Hi,

is it possible when I create a promiscuous socket with 
...

static struct {
	struct sockaddr_can src;
	int pkt_len;
} ss = {
	.pkt_len = 1024,
	.src.can_addr.j1939 = {
		.name = J1939_NO_NAME,
		.addr = J1939_NO_ADDR,
		.pgn = J1939_NO_PGN,
	},
};
....
addr.can_ifindex = ss.src.can_ifindex;
...

and then receive a msg with recvfrom and  send that msg with sendto to tell 
the promiscuous socket to ignore the send msg. That the promiscuous socket only
receives 'extern' messages. I am totally floored, or am I on the wrong track?

Best regards,
Wolfgang

Re: recv list

[Kurt Van Dijck]

On Thu, Jan 12, 2012 at 03:23:43PM +0000, Wolfgang wrote:
> Hi,
> 
> is it possible when I create a promiscuous socket with 
> ...
> 
> static struct {
> 	struct sockaddr_can src;
> 	int pkt_len;
> } ss = {
> 	.pkt_len = 1024,
> 	.src.can_addr.j1939 = {
> 		.name = J1939_NO_NAME,
> 		.addr = J1939_NO_ADDR,
> 		.pgn = J1939_NO_PGN,
> 	},
> };
> ....
> addr.can_ifindex = ss.src.can_ifindex;
> ...
> 
> and then receive a msg with recvfrom and  send that msg with sendto to tell 
> the promiscuous socket to ignore the send msg. That the promiscuous socket only
> receives 'extern' messages. I am totally floored, or am I on the wrong track?

I think you are looking to 'avoid receiving msgs that you just sent yourself'.
We had such issue solved in can_raw some time ago, and I put the same mechanism
in can-j1939.
I'll come back on that tomorrow ...

You may look at socket option SO_J1939_RECV_OWN, and flag MSG_DONTROUTE in recvmsg.

Kurt

bridging with can-gw - was Re: recv list

[Oliver Hartkopp]

On 12.01.2012 16:23, Wolfgang wrote:

> is it possible when I create a promiscuous socket with 
> ...
> 
> static struct {
> 	struct sockaddr_can src;
> 	int pkt_len;
> } ss = {
> 	.pkt_len = 1024,
> 	.src.can_addr.j1939 = {
> 		.name = J1939_NO_NAME,
> 		.addr = J1939_NO_ADDR,
> 		.pgn = J1939_NO_PGN,
> 	},
> };
> ....
> addr.can_ifindex = ss.src.can_ifindex;
> ...
> 
> and then receive a msg with recvfrom and  send that msg with sendto to tell 
> the promiscuous socket to ignore the send msg. That the promiscuous socket only
> receives 'extern' messages. I am totally floored, or am I on the wrong track?


Hello Wolfgang,

as you are always writing about the bridging of J1939 frames - what does this
mean on the bus?

Do you only bridge single frames?

If so the kernel based CAN gateway (can-gw) may be something to fit to your
requirements. See:

http://old.nabble.com/netlink-based-CAN-gateway-kernel-module-td27707326.html

The can-gw is in the SocketCAN repos and part of the recently released 
kernel 3.2.

It's performance has been talked about in the 13th Real Time Linux Workshop in
Prague: https://lwn.net/images/conf/rtlws-2011/

PDF is here: https://lwn.net/images/conf/rtlws-2011/paper.22.html

The cangw tool improved since the original posting, see below.

Regards,
Oliver

---8<--- 

Usage: cangw [options]

Commands:  -A (add a new rule)
           -D (delete a rule)
           -F (flush / delete all rules)
           -L (list all rules)
Mandatory: -s <src_dev>  (source netdevice)
           -d <dst_dev>  (destination netdevice)
Options:   -t (preserve src_dev rx timestamp)
           -e (echo sent frames - recommended on vcanx)
           -f <filter> (set CAN filter)
           -m <mod> (set frame modifications)
           -x <from_idx>:<to_idx>:<result_idx>:<init_xor_val> (XOR checksum)
           -c <from>:<to>:<result>:<init_val>:<xor_val>:<crctab[256]> (CRC8 cs)
           -p <profile>:[<profile_data>] (CRC8 checksum profile & parameters)

Values are given and expected in hexadecimal values. Leading 0s can be omitted.

<filter> is a <value><mask> CAN identifier filter
   <can_id>:<can_mask> (matches when <received_can_id> & mask == can_id & mask)
   <can_id>~<can_mask> (matches when <received_can_id> & mask != can_id & mask)

<mod> is a CAN frame modification instruction consisting of
<instruction>:<can_frame-elements>:<can_id>.<can_dlc>.<can_data>
 - <instruction> is one of 'AND' 'OR' 'XOR' 'SET'
 - <can_frame-elements> is _one_ or _more_ of 'I'dentifier 'L'ength 'D'ata
 - <can_id> is an u32 value containing the CAN Identifier
 - <can_dlc> is an u8 value containing the data length code (0 .. 8)
 - <can_data> is always eight(!) u8 values containing the CAN frames data
The max. four modifications are performed in the order AND -> OR -> XOR -> SET

Example:
cangw -A -s can0 -d vcan3 -e -f 123:C00007FF -m SET:IL:333.4.1122334455667788

Supported CRC 8 profiles:
Profile '1' (1U8)       - add one additional u8 value
Profile '2' (16U8)      - add u8 value from table[16] indexed by (data[1] & 0xF)
Profile '3' (SFFID_XOR) - add u8 value (can_id & 0xFF) ^ (can_id >> 8 & 0xFF)

Re: bridging with can-gw

[Kurt Van Dijck]

On Thu, Jan 12, 2012 at 07:08:21PM +0100, Oliver Hartkopp wrote:
> On 12.01.2012 16:23, Wolfgang wrote:
> 
> > is it possible when I create a promiscuous socket with 
> > ...
> > 
> > static struct {
> > 	struct sockaddr_can src;
> > 	int pkt_len;
> > } ss = {
> > 	.pkt_len = 1024,
> > 	.src.can_addr.j1939 = {
> > 		.name = J1939_NO_NAME,
> > 		.addr = J1939_NO_ADDR,
> > 		.pgn = J1939_NO_PGN,
> > 	},
> > };
> > ....
> > addr.can_ifindex = ss.src.can_ifindex;
> > ...
> > 
> > and then receive a msg with recvfrom and  send that msg with sendto to tell 
> > the promiscuous socket to ignore the send msg. That the promiscuous socket only
> > receives 'extern' messages. I am totally floored, or am I on the wrong track?
> 
> 
> Hello Wolfgang,
> 
> as you are always writing about the bridging of J1939 frames - what does this
> mean on the bus?
> 
> Do you only bridge single frames?

The idea has crossed my mind also that when only single frames are bridged,
a raw cangw may suit the need.
A cangw setup _may_ not suit when transport protocol comes in place...
> 
Kurt

Re: bridging with can-gw

[Wolfgang]

> > Do you only bridge single frames?
> 
> The idea has crossed my mind also that when only single frames are bridged,
> a raw cangw may suit the need.
> A cangw setup _may_ not suit when transport protocol comes in place...

Thanks for your ideas.
cangw sounds really interesting but the point is my gw should be capable for 
transport protocol as well.

Thank you so far,
Wolfgang

MSG_DONTROUTE

[Wolfgang]

What did I do wrong I want that after the reception of the message it is checked 
whether the MSG_DONTROUTE flag is set and if it isn't set the message is bridged
on socket s2? 
At the moment it doesn't matter if the frame is new or created on the local host.

	while (1) {
		
		iov.iov_len = s.pkt_len;
		msg.msg_namelen = sizeof(src);
		msg.msg_controllen = sizeof(ctrlmsg);
		msg.msg_flags = 0;

			
		ret = recvmsg(sock, &msg, 0);


		if ((msg.msg_flags & MSG_DONTROUTE) == 0)
			{
				src.can_addr.j1939.addr = J1939_NO_ADDR;
				src.can_ifindex = if_nametoindex("can1");
				sendmsg(s2, &msg, 0);
			}


Thanks for your ideas!

Re: MSG_DONTROUTE

[Kurt Van Dijck]

On Mon, Jan 16, 2012 at 10:04:17AM +0000, Wolfgang wrote:
> What did I do wrong I want that after the reception of the message it is checked 
> whether the MSG_DONTROUTE flag is set and if it isn't set the message is bridged
> on socket s2? 
> At the moment it doesn't matter if the frame is new or created on the local host.
> 
> 	while (1) {
> 		
> 		iov.iov_len = s.pkt_len;
> 		msg.msg_namelen = sizeof(src);
> 		msg.msg_controllen = sizeof(ctrlmsg);
> 		msg.msg_flags = 0;
> 
> 			
> 		ret = recvmsg(sock, &msg, 0);
> 
> 
> 		if ((msg.msg_flags & MSG_DONTROUTE) == 0)
> 			{
> 				src.can_addr.j1939.addr = J1939_NO_ADDR;
> 				src.can_ifindex = if_nametoindex("can1");
> 				sendmsg(s2, &msg, 0);
> 			}
> 

I think this should have worked.
After a look, I see that this path in kernel is left incomplete ...
For some reason, the line copying the flags dissappeared.

I'm just pushed an update that fixes this.
You did nothing wrong.

Kurt

sendmsg

[Wolfgang]

> I'm just pushed an update that fixes this. 
Great! Thanks.


 	while (1) {
		
 		iov.iov_len = s.pkt_len;
 		msg.msg_namelen = sizeof(src);
 		msg.msg_controllen = sizeof(ctrlmsg);
		msg.msg_flags = 0;
 
 			
		ret = recvmsg(sock, &msg, 0);
 

		if ((msg.msg_flags & MSG_DONTROUTE) == 0)
 			{
 				src.can_addr.j1939.addr = J1939_NO_ADDR;
 				src.can_ifindex = if_nametoindex("can1");
 				sendmsg(s2, &msg, 0);
 			}

                  } 



Is it possible or what do I have to change that sendmsg will send the _same_ 
frame which is received? Now the dlc is always 0x400 as declared in s.pkt_len.

Kind regards!

Re: sendmsg

[Kurt Van Dijck]

On Mon, Jan 16, 2012 at 03:28:24PM +0000, Wolfgang wrote:
> > I'm just pushed an update that fixes this. 
> Great! Thanks.
> 
> 
>  	while (1) {
> 		
>  		iov.iov_len = s.pkt_len;
>  		msg.msg_namelen = sizeof(src);
>  		msg.msg_controllen = sizeof(ctrlmsg);
> 		msg.msg_flags = 0;
>  
>  			
> 		ret = recvmsg(sock, &msg, 0);
>  
> 
> 		if ((msg.msg_flags & MSG_DONTROUTE) == 0)
>  			{
>  				src.can_addr.j1939.addr = J1939_NO_ADDR;
>  				src.can_ifindex = if_nametoindex("can1");
>  				sendmsg(s2, &msg, 0);
>  			}
> 
>                   } 
> 
> 
> 
> Is it possible or what do I have to change that sendmsg will send the _same_ 
> frame which is received? Now the dlc is always 0x400 as declared in s.pkt_len.
after recvmsg(), do
	msg.iov_len = ret;

I believe you understand why?
Kurt

max dlc

[Wolfgang]

Hi Kurt,

I am back working a little my gw.

As the defined in the j1939-21 the maximum dlc is 1785. 

static struct {
	int pkt_len;
} s = {
	.pkt_len = 1024,
};

buf = malloc(s.pkt_len);

recvmsg(sockfd, &msg, 0);


Did I get that right, that a dlc more than 1024 bytes is not possible with
recvmsg or sendmsg. For my application I won't need so many data but for
understanding the code!

Kind regards,
Wolfgang

Re: sendmsg

[Wolfgang]

Hi Kurt,

I am back working a little my gw.

As the defined in the j1939-21 the maximum dlc is 1785. 

static struct {
	int pkt_len;
} s = {
	.pkt_len = 1024,
};

buf = malloc(s.pkt_len);

recvmsg(sockfd, &msg, 0);

Did I get that right, that a dlc more than 1024 bytes is not possible with
recvmsg or sendmsg. For my application I won't need so many data but for
understanding the code!

Kind regards,
Wolfgang


I forget to mention, that I set s.pkt_len = 1785 and it seemed to work with
sendmsg and recvmsg. But UIO_MAXIOV is defined as 1024, so what do I get wrong?

Re: sendmsg

[Kurt Van Dijck]

Hey Wolfgang,

On Tue, Feb 07, 2012 at 03:11:13PM +0000, Wolfgang wrote:
> Hi Kurt,
> 
> I am back working a little my gw.
> 
> As the defined in the j1939-21 the maximum dlc is 1785. 

Yes.
This stack also supports the Extended Transport Protocol as defined
in iso11783-6, which extends to several MegaBytes...

> 
> static struct {
> 	int pkt_len;
> } s = {
> 	.pkt_len = 1024,
> };
> 
> buf = malloc(s.pkt_len);
> 
> recvmsg(sockfd, &msg, 0);
> 
> Did I get that right, that a dlc more than 1024 bytes is not possible with
> recvmsg or sendmsg.
That is not a limitation of recvmsg or sendmsg. 1024 in jspy.c is just
a decent default. Via options a different (bigger) packet size can be selected.
For a complete explanation, man 2 recvmsg, look for MSG_TRUNC.
That will explain what happens when I supply a buffer to recvmsg that is smaller
than the packet I'm receiving. The received packet is then truncated.

> For my application I won't need so many data
Most application don't need such packets ....
> but for understanding the code!
Very well!
> 
> Kind regards,
> Wolfgang
> 
> 
> I forget to mention, that I set s.pkt_len = 1785 and it seemed to work with
> sendmsg and recvmsg. But UIO_MAXIOV is defined as 1024, so what do I get wrong?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

How to get the DA

[Wolfgang Wagner]

Hi Kurt,

is there a simple way to get the destination address out of the ID, or has it to
be done with the struct cmsghdr, like implement in the jspy?

Greetings,
Wolfgang

Re: How to get the DA

[Kurt Van Dijck]

On Thu, Feb 16, 2012 at 09:58:27AM +0000, Wolfgang Wagner wrote:
> Hi Kurt,
> 
> is there a simple way to get the destination address out of the ID, or has it to
> be done with the struct cmsghdr, like implement in the jspy?
There is no simpler way.

Retreiving the original Destination address is in most cases irrelevant.
Receiving the message means that you should process it (in most cases).
I admit that your usecase, being a bridge, is a major exception to this
rule.
Like the message priority, the original destination address did not make
it into the a simple API.

Looking at your attempt, I'm a bit glad I did not totally strip these
attributes, and kept the available, altough  they're a bit hard to fetch :-)

Kurt

Transport Protocol

[Wolfgang Wagner]

Hi Kurt,

I try to bridge a Multi Packet Message. 


I set can0 on j1939 and started it

$echo can0 > /proc/net/can-j1939/net
$ip link set can0 up type can bitrate 500000
$ip addr add j1939 0x00 dev can0


I am still working with the simulator software.
Now sent the TP.CM 0x1CEC009F 0x16 0x00 0xF0 0x30 0xFF 0x00 0xEE 0x00


Now it responses with this:
0X1CEC9F00 0xFF 0x05 0xFF 0xFF 0xFF 0x00 0xEE 0x00

and I get this message:
$j1939xtp_rx_bad_message, pgn 0ee00
$j1939xtp_rx_abort 2, 0ee00


I am pretty sure I did something wrong, can you please correct?

Is it possible if everything is done right to bridge the TP.CM and TP.DT
directly with the previous implementation?

Re: Transport Protocol

[Kurt Van Dijck]

> $echo can0 > /proc/net/can-j1939/net
> $ip link set can0 up type can bitrate 500000
> $ip addr add j1939 0x00 dev can0
ok
> I am still working with the simulator software.
> Now sent the TP.CM 0x1CEC009F 0x16 0x00 0xF0 0x30 0xFF 0x00 0xEE 0x00
Oeps, this is not right, for 3 reasons:
* 0x16 is defined in the extended transport protocol, which I think you're not using
* 0xf0 bytes can be sent in 0x21 packets; you will send 0x30 of them?

* j1939 defines PGN 0x00ee00 as address claim, which is exactly 8 bytes long,
and therefore will not use transport protocol at all.

fault 1 cause the following message.
fault 2 is 'not done', but I don't know by head what the result will be. Probably
I will be tolerant and accept it.
fault 3 is no problem for the kernel module, but it is a problem for higher layers
in userspace. They should all produce an error when such packet would finally arrive..
> 
> 
> Now it responses with this:
> 0X1CEC9F00 0xFF 0x05 0xFF 0xFF 0xFF 0x00 0xEE 0x00
yep.
> 
> and I get this message:
> $j1939xtp_rx_bad_message, pgn 0ee00
> $j1939xtp_rx_abort 2, 0ee00
yep
> 
> 
> I am pretty sure I did something wrong, can you please correct?
> 
> Is it possible if everything is done right to bridge the TP.CM and TP.DT
> directly with the previous implementation?
The bridge you're making will bridge the packets on j1939 level, which is
for transport protocol different than bridging on CAN level.
This means that after the entire transport protocol is received on can0,
transmission starts on can1.
> 
Kurt

Transport Protocol: example

[Kurt Van Dijck]

On Fri, Feb 24, 2012 at 03:23:10PM +0000, Wolfgang Wagner wrote:
> Hi Kurt,
> 
> I try to bridge a Multi Packet Message. 
> 
> 
> I set can0 on j1939 and started it
> 
> $echo can0 > /proc/net/can-j1939/net
> $ip link set can0 up type can bitrate 500000
> $ip addr add j1939 0x00 dev can0
> 
> I am still working with the simulator software.
> Now sent the TP.CM 0x1CEC009F 0x16 0x00 0xF0 0x30 0xFF 0x00 0xEE 0x00
> 

I setup a demo using $ jsr.
So I did:

$ ip link add vcan0 type vcan
# equivalent of $ echo vcan0 > /proc/net/can-j1939/net on pre-2.6.3? kernel
$ ip link set vcan0 j1939 on
$ ip addr add j1939 0x80 dev vcan0
$ ip addr add j1939 0x00 dev vcan0

I now will send & receive by the same box over a virtual CAN bus.
This was much easier to run a simulation :-)

So I did:
$ jsr vcan0:80,00ee00 :00 < moose.txt (dummy text file)

with candump:
 (000.000000)  vcan  18EC0080  [8] 10 60 00 0E 0E 00 EE 00
 (000.000092)  vcan  18EC8000  [8] 11 0E 01 FF FF 00 EE 00
 (000.000139)  vcan  18EB0080  [8] 01 5C 5F 5C 5F 20 20 20
 (000.000151)  vcan  18EB0080  [8] 02 20 5F 2F 5F 2F 0A 20
 (000.000162)  vcan  18EB0080  [8] 03 20 20 20 5C 5F 5F 2F
 (000.000174)  vcan  18EB0080  [8] 04 0A 20 20 20 20 28 30
 (000.000185)  vcan  18EB0080  [8] 05 30 29 5C 5F 5F 5F 5F
 (000.000196)  vcan  18EB0080  [8] 06 5F 5F 5F 0A 20 20 20
 (000.000207)  vcan  18EB0080  [8] 07 20 28 5F 5F 29 5C 20
 (000.000219)  vcan  18EB0080  [8] 08 20 20 20 20 20 20 29
 (000.000230)  vcan  18EB0080  [8] 09 5C 2F 5C 0A 20 20 20
 (000.000242)  vcan  18EB0080  [8] 0A 20 20 20 20 20 7C 7C
 (000.000253)  vcan  18EB0080  [8] 0B 2D 2D 2D 2D 57 20 7C
 (000.000265)  vcan  18EB0080  [8] 0C 0A 20 20 20 20 20 20
 (000.000275)  vcan  18EB0080  [8] 0D 20 20 7C 7C 20 20 20
 (000.000288)  vcan  18EB0080  [6] 0E 20 20 7C 7C 0A
 (000.000604)  vcan  18EC8000  [8] 13 60 00 0E FF 00 EE 00

I now realize I was a bit fast in my previous post by saying you send
0xf0 bytes, since you tried to send 0xf000 bytes, which is only
possible with the extended transport protocol as defined in
iso11783-6 (and supported by your kernel).

I also used PGN 0x00ee00, which I already said was not a good idea, but
it may not fail the demonstration ...

To make the story complete, I also did a broadcasted transport protocol.
$ jsr vcan0:80,00ee00 < moose.txt
Note the timestamps! A broadcasted session may only send a packet each 50 msec.

 (000.000000)  vcan  18ECFF80  [8] 20 60 00 0E FF 00 EE 00
 (000.050133)  vcan  18EBFF80  [8] 01 5C 5F 5C 5F 20 20 20
 (000.100178)  vcan  18EBFF80  [8] 02 20 5F 2F 5F 2F 0A 20
 (000.150217)  vcan  18EBFF80  [8] 03 20 20 20 5C 5F 5F 2F
 (000.200259)  vcan  18EBFF80  [8] 04 0A 20 20 20 20 28 30
 (000.250298)  vcan  18EBFF80  [8] 05 30 29 5C 5F 5F 5F 5F
 (000.300338)  vcan  18EBFF80  [8] 06 5F 5F 5F 0A 20 20 20
 (000.350379)  vcan  18EBFF80  [8] 07 20 28 5F 5F 29 5C 20
 (000.400423)  vcan  18EBFF80  [8] 08 20 20 20 20 20 20 29
 (000.450465)  vcan  18EBFF80  [8] 09 5C 2F 5C 0A 20 20 20
 (000.500508)  vcan  18EBFF80  [8] 0A 20 20 20 20 20 7C 7C
 (000.550552)  vcan  18EBFF80  [8] 0B 2D 2D 2D 2D 57 20 7C
 (000.600598)  vcan  18EBFF80  [8] 0C 0A 20 20 20 20 20 20
 (000.650642)  vcan  18EBFF80  [8] 0D 20 20 7C 7C 20 20 20
 (000.700688)  vcan  18EBFF80  [6] 0E 20 20 7C 7C 0A

I believe that these examples may answer a lot of your questions :-).

Kurt

> 
> Now it responses with this:
> 0X1CEC9F00 0xFF 0x05 0xFF 0xFF 0xFF 0x00 0xEE 0x00
> 
> and I get this message:
> $j1939xtp_rx_bad_message, pgn 0ee00
> $j1939xtp_rx_abort 2, 0ee00
> 
> 
> I am pretty sure I did something wrong, can you please correct?
> 
> Is it possible if everything is done right to bridge the TP.CM and TP.DT
> directly with the previous implementation?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Transport Protocol: example

[Wolfgang Wagner]

Hi Kurt,

thanks I lot, I think I got it.

> I now realize I was a bit fast in my previous post by saying you send
> 0xf0 bytes, since you tried to send 0xf000 bytes, which is only
> possible with the extended transport protocol as defined in
> iso11783-6 (and supported by your kernel).

Acutally I wanted to send 0x00f0 bytes, I am still confused with msb and lsb.
 
> I also used PGN 0x00ee00, which I already said was not a good idea, but
> it may not fail the demonstration ...

Ok this was an accident, acutally I should know that 00ee00 is for ac!

>So I did:
>$ jsr vcan0:80,00ee00 :00 < moose.txt (dummy text file)

Yes, this is working - when I am fast enough sending with the simulator 
software the TP.CM_CTS. Of course with can0 or can1.



> To make the story complete, I also did a broadcasted transport protocol.
> $ jsr vcan0:80,00ee00 < moose.txt

This is working as well!

> 
> I believe that these examples may answer a lot of your questions .

Definitely. 
 
> > Is it possible if everything is done right to bridge the TP.CM and TP.DT
> > directly with the previous implementation?
> > 
> >The bridge you're making will bridge the packets on j1939 level, which is
> >for transport protocol different than bridging on CAN level.
> >This means that after the entire transport protocol is received on can0,
> >transmission starts on can1.

I should be no problem!

Just whether I understood it right:

My "ECU" makes the negotiation with the sending node and write the TP.CM_RTS 
and the TP.DT in the socket and after the complete reception it makes the 
negotiation with the other node with sending the TP.CM_RTS and than sends the
TP.DT?

--Wolfgang

Re: Transport Protocol: example

[Kurt Van Dijck]

On Tue, Feb 28, 2012 at 03:21:17PM +0000, Wolfgang Wagner wrote:
> Hi Kurt,
> 
> Just whether I understood it right:
> 
> My "ECU" makes the negotiation with the sending node and write the TP.CM_RTS 
> and the TP.DT in the socket and after the complete reception it makes the 
> negotiation with the other node with sending the TP.CM_RTS and than sends the
> TP.DT?

Yes.

Kurt
> 
> --Wolfgang
> 
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html