[fix] LOCAL_IFNAME and GUEST_IFNAME max name size #205
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A bug fix for the automatic creation logic of the LOCAL_IFNAME and GUEST_IFNAME vars values.
Pipework always automatically computes the value of the $GUEST_IFNAME var. This var is used to define the name of the guest interface before it's added to the guest's NS and it's subsequently renamed to the value of the $CONTAINER_IFNAME. The actual value is computed as follow:
However, specifying a long but valid $CONTAINER_IFNAME (up to i.e. IF_NAMSIZ chars in linux) does rise and error, because the concatenated string for the $GUEST_IFNAME var will be then larger than the maximum allowed value (again IF_NAMSIZ in the linux case).
The same issue arises in this scenario if a -i option isn't passed to pipework to specify a valid $LOCAL_IFNAME, as the value for this var is computed in the exact same way described above (using "pg" instead of "pl" in the concatenated string)
pipework br_pub_5 -i pub_lan_7 base 192.168.4.27/24
Error: argument "vpub_lan_7pl28223" is wrong: "name" too long
To fix this issue, the algorith to compute the value of $GUEST_IFNAME and $LOCAL_IFNAME has been modified in this way:
The $GUEST_IFNAME var is automatically computed also if the $IFTYPE var is "ipoib". The same issue could potentially arise if $IFNAME is as long as IF_NAMSIZ, as the $GUEST_IFNAME is computed longer than $IFTYPE. However I'm unsure about the interface naming requirements for this networking layer and cannot test it. So this case should be checked and the automatic value should be computed accordingly