On di, 28 mei 2019 16:27:57 +0200, David Jander wrote: > On Tue, 28 May 2019 15:13:44 +0200 > Kurt Van Dijck <dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > On di, 28 mei 2019 13:54:35 +0200, Oleksij Rempel wrote: > > > Hi all, > > > > > > when receiving j1939 control messages, the current code looks up the > > > session by DA and SA only, not taking the PGN (which is part of the > > > control messages' data) into account. > > > > > > When it comes to error control messages the session is aborted, even if > > > the PGN doesn't match. In EOMA the session is aborted, too. This means > > > receiving control messages with non matching PGNs lead to session abort. > > > > > > Is this in general a good behavior? > > Tl;DR: Yes, if PGN does not match the (E)TP session should be aborted. > > > It is indeed a bit stupid. > > > > If 2 ends are talking to each other, and 1 of those 2 talks about > > something else, that implies that you talk not about the same thing > > either, and you probably want to abort soon. It would be better if > > you only abort 'probably soon' and not 'immediately' in such case, since > > you're right that reception of another PGN control frame does not imply > > that you're current session became invalid. > > If the session is with me and I see conflicting PGN (not start of a new > session), why not send an abort immediately? > > > In j1939 however, the data part does not carry PGN info, since only 1 > > session can be open. This implies 2 things: > > * Ignoring PGN difference in control frames makes you blind to the data > > consistency, so you may think in certain cases that you continue to receive > > data while it's actually the data that belongs to another PGN. > > The sender cannot start sending data without the receiver acknowledging that > with a CTS message first. If the CTS contains a different PGN than the RTS, > then the sender should abort immediately. > For ETP, if the receiver sees a DPO frame with a different PGN, it should also > send an abort for that PGN immediately. > > > * If node A talks to node B on a different PGN that node B thinks that > > node A is talking, then this is AFAIK considered as protocol > > violation because you risk data corruption. > > > > The PGN in all-but-1st control frame could be considered redundant, but > > since it's there, it should match. > > Ack. > > > So, it's still not a good behaviour, but j1939 IMHO requires you to do so. > > > > So you think this is bad, let's make it even worse :-) > > Between 2 nodes, actually 2 sessions may exist, 1 recv & 1 send. > > Actually four in this case: ETPrx, TPrx, ETPtx and ETPrx, right? Right, I tend to forget ETP for simplicity :-) > > > Still, control frames that to RTS, CTS, DPO, ... are uni-directional, > > i.e. they map to only 1 of those 2 sessions exclusively. > > This is not the case for an abort message. > > _If I'm not mistaken_, the PGN info should be ignored for abort frames, > > since it may be unclear what exactly you abort: a old PGN, or a newly > > requested PGN. And due to that, it's also unclear if it applies to the > > send or recv path, so you abort, AFAIK, both directions at once. > > But I have not the specifications around now, I can't verify. > > The abort message also contains the PGN of the packeted message, so AFAICS, you > can abort any one specific of the 4 theoretically simultaneous sessions, > because the should have different PGN's for the different directions (rx/tx). > > That's probably one of the reasons why there is always a different PGN used to > talk in one direction than in the other. I see. I did not implement that very nice, I think. Kind regards, Kurt
