Re: J1939: problem in CM mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi again,
i've found my problem, in fact we added some filtering for some
special test, and the CTS sent frame was not deliverered to the
transport layer.

removing this special code makes it works
sorry for the inconvenience

Laurent

On Wed, Jan 23, 2019 at 11:24 AM laurent vaudoit
<laurent.vaudoit@xxxxxxxxx> wrote:
>
> thanks Oleksij
> i will have a look
>
> Laurent
>
> On Wed, Jan 23, 2019 at 11:23 AM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:
> >
> >
> >
> > On 23.01.19 11:13, laurent vaudoit wrote:
> > > Hi,
> > >
> > > On Wed, Jan 23, 2019 at 10:02 AM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 23.01.19 08:45, laurent vaudoit wrote:
> > >>> Hi all,
> > >>> no feedback about this "problem"
> > >>>
> > >>> Regards
> > >>> Laurent
> > >>>
> > >>> On Wed, Jan 16, 2019 at 4:26 PM laurent vaudoit
> > >>> <laurent.vaudoit@xxxxxxxxx> wrote:
> > >>>>
> > >>>> Hi all,
> > >>>> i'm using the old J1939 kernel implementation (with iproute2 specific),
> > >>>> but it seems transport layer as not change a lot.
> > >>
> > >> Did you tested latest code?
> > >>
> > >>>> Here is my problem:
> > >>>> on my board i setup an interface, with 0x4a as SA.
> > >>>>
> > >>>> On a canalyzer i send a 0x0F segmented packet:
> > >>>> 0x18EC214Ax: 10 0F 00 03 FF CD FF 00 ==> RTS
> > >>>> 0x18EC4A21x: 11 03 01 FF FF CD FF 00 ==> CTS
> > >>>> 0x18EB214Ax: 01 B2 1E 78 4D 61 72 6B ==> DT
> > >>>> 0x18EB214Ax: 02 73 74 68 65 73 70 6F  ==> DT
> > >>>> 0x18EB214Ax:  03 74 FF FF FF FF FF FF==> DT
> > >>>>
> > >>>> instead of sending an acknowledge, the board send an abort frame, with
> > >>>> 0x05 reason:
> > >>>> 0x18EC4A21x: FF 05 FF FF FF CD FF 00.
> > >>>>
> > >>>> After activating some debug log in the kernel, i see that when i
> > >>>> receive the first Data Transfer frame, i get the error message:
> > >>>> j1939xtp_rx_dat: last 10
> > >>>>
> > >>>> if i look into the function j1939xtp_rx_dat, i see that the switch on
> > >>>> last_cmd wait BAM (0x20 or CTS 0x11), but for me it should wait RTS
> > >>>> (0x10, as last_cmd is not modified when sending the CTS (last_tx_cmd
> > >>>> is updated at this step)
> > >>
> > >> I don't know what code version are you using. Current code is updating
> > >> last_cmd for CTS.
> > >>
> > >>>> i've tried to modify but the behaviour is worst as there is some
> > >>>> retrasnmission of the CTS frame
> > >>>>
> > >>>> Would you have an idea on this behaviour?
> > >>
> > >> please use latest version.
> > >
> > > you are right i use an old j1939 stack, for 3.10 kernel wich needs
> > > iproute2 modified.
> > > i know there is some new implementation, but when i look on the kurt
> > > github, i see that latest commits are in 2017, and i do not see any
> > > change on the last_cmd updated for CTS.
> > > Did the code has changed of location?
> >
> > Yes, please use this, more verbose repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=j1939-individual
> >
> > or the less verbose:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=j1939



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux