CCP protocol implementation #1858
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1858 +/- ##
==========================================
- Coverage 85.77% 85.75% -0.03%
==========================================
Files 185 185
Lines 42473 42473
==========================================
- Hits 36430 36421 -9
- Misses 6043 6052 +9
|
Codecov Report
@@ Coverage Diff @@
## master #1858 +/- ##
==========================================
- Coverage 85.76% 85.75% -0.02%
==========================================
Files 185 185
Lines 42473 42473
==========================================
- Hits 36429 36421 -8
- Misses 6044 6052 +8
|
|
Hey @polybassa, some of the ISOTP tests are a bit unstable. Do you think you could have a look ? Thanks ! Edit: My bad.. I restarted the test which destroyed the logs... sorry will come back to you when it fails again We have a |
|
Hi @gpotter2 I’ll have a look. Unfortunately the link from you doesn’t give me any information. Could you please specify, which tests are failing the most.
We also discovered, that high load on Travis makes some of our tests more likely to fail. I wonder if this could be simulated, to find failing tests better.
… On 19. Feb 2019, at 14:12, Gabriel Potter ***@***.***> wrote:
Hey @polybassa, some of the ISOTP tests are a bit unstable. Do you think you could have a look ? Thanks !
https://travis-ci.org/secdev/scapy/jobs/495430130
We have a retry_test function in scapy.tools.UTscapy in last resort, if the failure isn’t related to your test (what we use when pinging servers / doing dns), but I don’t think you should be using it for local tests
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Just saw your edit. Alright.
… On 19. Feb 2019, at 14:12, Gabriel Potter ***@***.***> wrote:
Hey @polybassa, some of the ISOTP tests are a bit unstable. Do you think you could have a look ? Thanks !
https://travis-ci.org/secdev/scapy/jobs/495430130
We have a retry_test function in scapy.tools.UTscapy in last resort, if the failure isn’t related to your test (what we use when pinging servers / doing dns), but I don’t think you should be using it for local tests
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Here’s a failure: https://travis-ci.org/secdev/scapy/jobs/495745915 And here’s a backup of the logs: https://pastebin.com/Fz1fxT0T |
more work on ccp finish implementation of ccp more unit tests more unit tests fix minor bug to support the basecls parameter in pythoncan-sockets add ccp documentation
|
This PR is complete, from my side. |
There was a problem hiding this comment.
Looking good !
PS: Note that we’re currently having a global test failure due to a python-can update. Any new test will fail, they’re working on it.
| data = bytes(self.load) | ||
| self.remove_payload() | ||
| self.add_payload(new_pl_cls(data)) | ||
| self.payload_cls = new_pl_cls |
There was a problem hiding this comment.
Could you document a bit what this is doing ?
I don’t think one would expect answers() to edit the packets, it is commonly only a test
|
I saw this bug with python-can. Is there something I can do for you? Would it be a solution, to use a fixed version of python-can? |
|
This PR fails the spelling check: |
|
Thanks for your work ! |
|
Thanks for your work, as well!
… On 26. Feb 2019, at 14:57, Gabriel ***@***.***> wrote:
Thanks for your work !
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
No description provided.