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

Session Initialization Response Incorrect Parsing #6

Open
soxrok2212 opened this issue Nov 20, 2020 · 3 comments
Open

Session Initialization Response Incorrect Parsing #6

soxrok2212 opened this issue Nov 20, 2020 · 3 comments
Labels
bug Something isn't working

Comments

@soxrok2212
Copy link

Hey again, I'm doing some more testing and it looks like the session initialization response is not being parsed correctly. It seems that the Destination Up message is parsed as a MAC address data item in the response message.

I attached a screenshot to show what I mean.
Screen Shot 2020-11-19 at 5 16 02 PM

The following messages also appear to be exchanged as raw TCP packets and not DLEP. Am I missing something here?
Thank you!

@soxrok2212
Copy link
Author

Setting line 528 in dlepsession.py to item = None temporarily resolves the issue.

@lawa23
Copy link
Collaborator

lawa23 commented Nov 24, 2020

This problem occurs when more than a single DLEP message arrives in the TCP buffer, correct?

I found out this week that the current DLEPard implementation does not support reassembling DLEP packets.
Which is a serious bug in my opinion. I will fix this soon.

An additional hint if you need a quick workaround:
I will implement an additional buffer either in DLEPSession.on_tcp_receive() or in TCPProxy.connection_made().

@lawa23 lawa23 added the bug Something isn't working label Nov 24, 2020
@soxrok2212
Copy link
Author

This problem occurs when more than a single DLEP message arrives in the TCP buffer, correct?

That would make sense as there is nothing else between Session Initialization Response and Destination Up.

I found out this week that the current DLEPard implementation does not support reassembling DLEP packets.
Which is a serious bug in my opinion. I will fix this soon.

Great, thank you!

An additional hint if you need a quick workaround:
I will implement an additional buffer either in DLEPSession.on_tcp_receive() or in TCPProxy.connection_made().

Ironically the issue stopped presenting itself in my testing yesterday, but I be if I try again it'll show up eventually. For now, I don't think the MAC address is used anywhere as a data item so leaving it commented out is enough of a bandaid for the time being.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants