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

question on error behavior #27

Open
slowCoder72 opened this issue Feb 29, 2024 · 5 comments
Open

question on error behavior #27

slowCoder72 opened this issue Feb 29, 2024 · 5 comments

Comments

@slowCoder72
Copy link

the following might not be a real issue, but i would like to discuss the observation. We have a situation in which we act as a tester and the other nodes go into reboot/health check after an update. We then poll repeatedly to be aware when the nodes have rebooted. We needed to request idle in this situation, otherwise the lib stayed in UDS_ERR_BUSY even after the nodes had been back - no issue this is according to the examples.
However when we repeatedly send SendRDBI requests to get the status of the nodes while they are still not present, we get an oscillating pattern of errors: UDS_ERR_TIMEOUT, UDS_ERR_TPORT, UDS_ERR_TIMEOUT, UDS_ERR_TPORT etc.
we tried to understand how this happens and enabled the debug outputs:
client state: AwaitSendComplete (2) -> AwaitResponse (3)
read failed: -1 with errno: 70
timeout: 1
client state: AwaitResponse (3) -> Idle (0)
client state: Idle (0) -> Sending (1)
Condition met: client->send_size (3, 3), == ret (3)
Sending (1) -> AwaitSendComplete (2)
client state: AwaitSendComplete (2) -> AwaitResponse (3)
timeout: 1
client state: AwaitResponse (3) -> Idle (0)
awaiting idle failed with err = 1 and msg = 'UDS_ERR_TIMEOUT'
client state: Idle (0) -> Sending (1)
tport err: -1, nsend=3 bytes
Condition met: client->send_size (3, 3), == ret (3)
client state: Sending (1) -> AwaitSendComplete (2)
awaiting idle failed with err = 6 and msg = 'UDS_ERR_TPORT'
in the code imho this happens in:
case kRequestStateSending: {
UDSTpAddr_t ta_type = client->_options_copy & UDS_FUNCTIONAL ? UDS_A_TA_TYPE_FUNCTIONAL
: UDS_A_TA_TYPE_PHYSICAL;
UDSSDU_t info = {
.A_Mtype = UDS_A_MTYPE_DIAG,
.A_TA_Type = ta_type,
};
ssize_t ret = UDSTpSend(client->tp, client->send_buf, client->send_size, &info);
if (ret < 0) {
client->err = UDS_ERR_TPORT;

UDS_DBG_PRINT("tport err: %zd\n", ret);
} else if (0 == ret) {
UDS_DBG_PRINT("send in progress...\n");
; // 等待发送成功
} else if (client->send_size == ret) {
changeState(client, kRequestStateAwaitSendComplete);
} else {
client->err = UDS_ERR_BUFSIZ;
}
break;
and we are puzzled how ret < 0 can be true and shortly after client->send_size == ret??
Any idea from your experience?

@driftregion
Copy link
Owner

Hi @slowCoder72 . Please share an example client code noting expected and actual behavior.

@slowCoder72
Copy link
Author

slowCoder72 commented Mar 6, 2024 via email

@driftregion
Copy link
Owner

I do not see UDSClientInit() called in your snippet. See example client code here: https://github.com/driftregion/iso14229/blob/main/examples/linux_server_0x27/client.c

@slowCoder72
Copy link
Author

In the lua script we do "initUDSClient" and this via our wrapper executes UDSClientInit() in the lib. The communication to the targets also works and we took the above client.c as an inspiration. It is just the error behavior when there is no communication partner that i wanted to mention and probably discuss.

@driftregion
Copy link
Owner

Hi @slowCoder72 , are you still having this issue?

Using the information you've provided I cannot tell whether the issues is in iso14229 or in the transport layer. Please post a c-only implementation of a client that produces the error behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants