These are chat archives for Exa-Networks/exabgp

21st
Sep 2016
Job Snijders
@job
Sep 21 2016 09:16
@thomas-mangin i am not so sure if common header will happen or not at this point
so wouldnt put too much effort into it until the ietf process has run its course
Thomas Mangin
@thomas-mangin
Sep 21 2016 09:23
ok
thanks for the head’s up
Ben Agricola
@benagricola
Sep 21 2016 10:07
hmm.. no matter what i change in api-nexthop-self.run, I can't get the tests to fail
i was under the impression that an unhandled exception thrown would fail the test?
Thomas Mangin
@thomas-mangin
Sep 21 2016 10:32
@benagricola sorry - could you please be more specific so I can try to help. Yes, the bug is hard to reproduce :package:
Ben Agricola
@benagricola
Sep 21 2016 10:36
sorry, i think it's because i was running qa/bin/parsing, which only runs the configuration test and then exits straight away (so doesnt handle the process advertising routes)
i'm running qa/bin/conversation qa/conf/api-nexthop-self.group now but this doesn't seem to complete, it's been sitting there for about 5 mins so far with no output - do i need a running copy of exabgp for this to communicate with or should it spawn the processes it needs automatically?
Ben Agricola
@benagricola
Sep 21 2016 11:02
hmm ok, got it running (permissions issue starting the child process, had to pass exabgp.daemon.user=root - not really sure why), anyway - it looks like even when i can get the client exabgp to crash, the test still completes because the conversation is correct (i.e. the data received by the server is correct)
Thomas Mangin
@thomas-mangin
Sep 21 2016 11:04
LISTING=1 ./qa/bin/conversation
find the letter of your test
then
SERVER=<letter/number> ./qa/bin/conversation (in on shell)
CLIENT=<same letter> ./qa/bin/conversation (in another)
Ben Agricola
@benagricola
Sep 21 2016 11:07
ahh cool, okay
will go from here :)
thanks @thomas-mangin
Ben Agricola
@benagricola
Sep 21 2016 14:55
hmm.. so it seems to be difficult to test specifically for this issue, since the server end quits directly after it's received all the messages it expects.. but this causes the client to disconnect, and then never tries to announce a duplicate route, triggering the bug
maybe i need to send a final expected 'non duplicate route' afterwards which the server quits after
Thomas Mangin
@thomas-mangin
Sep 21 2016 15:02
You can simply edit the code of the server to run ‘time.sleep(1000)’ before disconnecting
Ben Agricola
@benagricola
Sep 21 2016 15:03
sending a final route seems to work perfectly actually - the test code attempts to advertise the same route 3 times and then a final route 1 time, the 'sequence' file contains the duplicated route once, and then the final route once
reproduces the crash every time
Thomas Mangin
@thomas-mangin
Sep 21 2016 15:21
if you send me the git diff and what you ran - I will have a look later (I should be able to)
Ben Agricola
@benagricola
Sep 21 2016 15:21
yeah i'll commit it all into a branch and link you
in fact, pretty much done now
if you remove the index() method that I added to IPSelf, the test will fail
and should pass otherwise
Thomas Mangin
@thomas-mangin
Sep 21 2016 15:27
Thanks
Ben Agricola
@benagricola
Sep 21 2016 15:28
i dont know if that index method is the best fix but using the text afi seems to make more sense to me since i suppose there's a chance a packed IP address could equal an integer? (maybe)
Thomas Mangin
@thomas-mangin
Sep 21 2016 15:35
I looked into the fix for several hours over the summer (and gave up as it was complicated) - I forgot what was the outcome but I will look again.
Ben Agricola
@benagricola
Sep 21 2016 15:39
Cool