Skip to content
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

ConsecutiveFrameTimeoutError for first consecutive frame #41

Closed
MaratSabitov opened this issue Mar 12, 2021 · 5 comments
Closed

ConsecutiveFrameTimeoutError for first consecutive frame #41

MaratSabitov opened this issue Mar 12, 2021 · 5 comments
Assignees
Labels

Comments

@MaratSabitov
Copy link

I found that ConsecutiveFrameTimeoutError was not raised, although, the first consecutive frame was not received after first frame and flow control exchange:
S R
-----First Frame----->
<--- Flow Control----

Is that expected behaviour - that ConsecutiveFrameTimeoutError raises only if consecutive frame receieved with delay.
What if the first consecutive frame will not come at all?
I thought in this case ConsecutiveFrameTimeoutError should be raised.

@pylessard pylessard self-assigned this Mar 12, 2021
@pylessard pylessard added the bug label Mar 12, 2021
@MaratSabitov
Copy link
Author

Thanks for your quick answer.

Yeah, i saw this test.
And i mean that it should be raised even without incoming CF with index=1 ( line 246),
because stack received first frame, sent flow control and waits consecutive frame/frames, but it was not received on time.

In this case timer_rx_cf is already expired.
And this is checked in process_rx().
But the problem is that this method is called only if message received.
So, timer expired - but need incoming message to trigger the check and raise the exception.

So, I just have doubts that this is up to the standard (Network layer timing part),
that's why i am asking this question.

@pylessard
Copy link
Owner

Sorry I deleted my previous answer at the same time you typed yours.

You seems to be correct about this. I will fix.

@pylessard
Copy link
Owner

Fixed now. Will publish soon.
Github seems to have trouble, I am not sure if you get to see my comments.

Regards

@MaratSabitov
Copy link
Author

Yeah, i see.
Yesterday i had some troubles with comments.
Thanks.

@pylessard
Copy link
Owner

This wasn't completely fixed.
Issue still exist and logged with #63

mikisama pushed a commit to mikisama/python-can-isotp that referenced this issue Apr 29, 2022
…flow control without waiting on next CAN msg.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants