kytos-ng / sdntrace_cp

MIT License
1 stars 6 forks source link

Internal server error 500 on `/api/amlight/sdntrace_cp/traces` #88

Closed viniarck closed 1 year ago

viniarck commented 1 year ago

I managed to find the root cause of the bug that @gretelliz and I were discussing on this review/comment. It turns out that it's a very specific bug related to a corner case that's been around for years in the code base. In summary, find_endpont(switch, port) when calling switch.get_interface_by_port_no(port) it's always assuming that the interface will be found, which in most cases will be true, but there's cases such as when OpenFlow port description hasn't been received yet and it's a new topology that hasn't been loaded from DB, then it can result in this issue. So, it needs to handle the case when the interface isn't found.

For the record here's the traceback:

Apr  6 06:44:57 runner-rmtk68xb-project-107-concurrent-0 2023-04-06 06:44:57,827 (Thread-619) kytos.core.controller:ERROR app:1449:  Exception on /api/amlight/sdntrace_cp/traces [PUT]#012Traceback (most recent call last):#012  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 2073, in wsgi_app#012    response = self.full_dispatch_request()#012  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1519, in full_dispatch_request#012    rv = self.handle_user_exception(e)#012  File "/usr/local/lib/python3.9/dist-packages/flask_cors/extension.py", line 165, in wrapped_function#012    return cors_after_request(app.make_response(f(*args, **kwargs)))#012  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1517, in full_dispatch_request#012    rv = self.dispatch_request()#012  File "/usr/local/lib/python3.9/dist-packages/flask/app.py", line 1503, in dispatch_request#012    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)#012  File "/usr/local/lib/python3.9/dist-packages/kytos/core/helpers.py", line 402, in wrapper_validate#012    return func(*args, data=data, **kwargs)#012  File "//var/lib/kytos/napps/amlight/sdntrace_cp/main.py", line 82, in get_traces#012    results.append(self.tracepath(entry, stored_flows))#012  File "//var/lib/kytos/napps/amlight/sdntrace_cp/main.py", line 109, in tracepath#012    result = self.trace_step(switch, entries, stored_flows)#012  File "//var/lib/kytos/napps/amlight/sdntrace_cp/main.py", line 181, in trace_step#012    endpoint = find_endpoint(switch, port)#012  File "//var/lib/kytos/napps/../napps/amlight/sdntrace_cp/utils.py", line 59, in find_endpoint#012    if interface.link:#012AttributeError: 'NoneType' object has no attribute 'link'

@gretelliz can you add this to your radar for 2023.1 version? Thanks.

gretelliz commented 1 year ago

Good to see the cause of the error @viniarck. Now, when there is no link at the endpoint found, None is returned, which will result in a last type (Success trace). My question is: Should it happen when there is no endpoint?

I can work it out now if you think it fixes the error.

viniarck commented 1 year ago

Good to see the cause of the error @viniarck. Now, when there is no link at the endpoint found, None is returned, which will result in a last type (Success trace). My question is: Should it happen when there is no endpoint?

I can work it out now if you think it fixes the error.

When this happens, it should be considered an incomplete trace and not a last type sucess, since currently sdntrace_cp is expecting to find an existing interface/link to derive the in_port given an outgoing port, so if you don't have information to derive the port you can't assume that it's a successful trace. I suppose it should be equivalent to when trace_step early returns if not flow or not port: return None (which also results in the incomplete) case, right?