-
Notifications
You must be signed in to change notification settings - Fork 103
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
fix pcn-iptables interface matching issue #252
Conversation
f39cd24
to
4cd5e8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@goldenrye I don't think this is the right way to go.
As you can see here the wildcard, if exists, is embedded directly into the data plane; then, it is not even needed to perform a lookup into the map.
This issue you have found is related to the control plane, that should use a different port (e.g., -1
) to save the wildcard and then embed the corresponding bit-vector.
What you should do is to change this line with a special
port number (e.g., -1) containing the wildcard and then modify this line to check if there is a wildcard with that special
port and embed it into the code.
In this way you don't have to change anything internally to polycube, which btw may break the existing applications, and you are allowed to use port 0
into the filtering set of iptables interface.
4cd5e8f
to
f14bed2
Compare
Ok thanks for all the comments and suggestions. I have modified the wild card from 0 to 0xffff and add some static assert to ensure no conflicting with regular port. BTW I think we should decouple the port id with the value _POLYCUBE_MAX_PORT, there is no reason to assume the port id is less than _POLYCUBE_MAX_PORT - I didn't actually see any code depends on this assumption. |
Each cube has an array map that saves the relationship polycube/src/polycubed/src/cube.cpp Lines 309 to 310 in d303462
The result of the lookup in that table is a pair of values, the destination cube and port of the packet, based on that a tail call is done to the next cube: polycube/src/polycubed/src/cube_tc.cpp Line 301 in ac2e21d
In order to remove the requirement that Could you please clarify why you think this constraint should be removed? |
If the forwarding table use port id as the index, the modification is not worthy, I don't have very strong case to support the modification. My argument is based on that port id is only used as value and any user referring to the value shouldn't have any assumption the range of the value. |
ddafe51
to
a9fc287
Compare
I don't know how pcn-iptables works but in the general cube idea the |
a9fc287
to
2a2cc70
Compare
… rule will be mistakenly regarded as wild-card rule, so even a packet from a diffrent port will be allowed passing by mistake. There are 2 changes in this commit: - update the iptables submodule pointing to the latest code base so interface parameter can be supported - change the wild-card index from 0 to 0xffff for pcn-iptables service because id 0 could be conflicting with a regular port, and recover the original failed test case. Signed-off-by: Jianwen Pi<jianwpi@gmail.com>
2a2cc70
to
c53deef
Compare
@mauriciovasquezbernal @sebymiano all the tests are passed, please review the code, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me now.
pcn-iptables uses 0 as wild card in port's hash map, which conflicts if
a port was assigned with id 0. Don't assign port id 0 to any port should
be able to fix the issue #233 .