Skip to content
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

added support for Foo-over-UDP netlink calls #285

Merged
merged 1 commit into from
Nov 13, 2017

Conversation

skoef
Copy link
Contributor

@skoef skoef commented Oct 18, 2017

The Foo-over-UDP patches from Tom Herbert added some netlink calls to the kernel. Here is the support for these calls, similar to ip fou add and ip fou del as well as a list function based on FOU_CMD_GET, to my knowledge currently not (yet) implemented in iproute2.

@skoef
Copy link
Contributor Author

skoef commented Oct 18, 2017

Looking at this error (https://travis-ci.org/vishvananda/netlink/builds/289425912#L541) and some other tests complaining about travis' kernel being too old, I think the same goes for TestFouAddDel or fou support in general as fou was merged in 3.18.

@skoef
Copy link
Contributor Author

skoef commented Oct 20, 2017

@vishvananda how is checking for TRAVIS_BUILD_DIR related to kernel 3.13? I'll be happy to add a decent check around TestFouAddDell but I'm not sure it makes a lot of sense.

@skoef
Copy link
Contributor Author

skoef commented Oct 26, 2017

I’m not quite happy with this result so far. Am I corect that next to managing Route Attributes there currently is no support for using ‘regular’ netlink attributes (like I’m parsing for FOU in this request)? I would rather implement that and use it for FOU than implement this specifically for FOU.

fou_linux.go Outdated
var fouFamilyId int

func FouFamilyId() (int, error) {
if fouFamilyId == 0 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make this more readable as

func FouFamilyId() (int, error) {
    if fouFamilyId != 0 {
       return fouFamilyId, nil
    }

    fams, err := GenlFamilyList()
    if err != nil {
        return -1, err
    }

    for _, f := range fams {
        if f.Name == FOU_GENL_NAME {
          fouFamilyId = int(f.ID)
          return fouFamilyId, nil
        }
    }

    return -1, fmt.Errorf("could not find genl family %s", FOU_GENL_NAME)
}

FOU_ENCAP_MAX = FOU_ENCAP_GUE
)

var fouFamilyId int
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if Handle would be a good place where to store the generic netlink families ids.

Copy link
Contributor Author

@skoef skoef Nov 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean adding a map of netlink families to the Handle struct?

fou_linux.go Outdated

func FouFamilyId() (int, error) {
if fouFamilyId == 0 {
fams, err := GenlFamilyList()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, any reason for not using GenlFamilyGet() ?

fou_linux.go Outdated
for _, m := range msgs {
if f, err := deserializeFouMsg(m); err != nil {
return fous, err
} else {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the else is not needed

fou_linux.go Outdated
return nil, err
}

fous := []Fou{}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to avoid reallocation of the slice at each append, you can define this as

fous := make([]Fou, 0, len(msgs))

fou_test.go Outdated
}

func TestFouAddDel(t *testing.T) {
tearDown := setUpNetlinkTest(t)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the call to minKernelRequired(t, M, N) so that this test only runs on kernel which knows about FOU

@aboch
Copy link
Collaborator

aboch commented Nov 10, 2017

Please squash the commits into one as they are all about the same feature.

@skoef
Copy link
Contributor Author

skoef commented Nov 10, 2017

@aboch thanks for your suggestions, I've applied them. As you seem invested, what do you think regarding the implementation of parsing regular netlink attributes? It seems foolish to implement it just for decoding FOU attributes while it applies to more non-routing attributes as well.

I'll squash the commits when everything is ok.

@aboch
Copy link
Collaborator

aboch commented Nov 10, 2017

I think we can get this PR in as is.
You can come back later to implement generic parsing methods other could use.

Are you sure you can't use nl.ParseRouteAttr() ?
I have seen it being used to parse attributes from genl messages.

@skoef skoef force-pushed the FooOverUDP branch 3 times, most recently from 9e9dada to 6603cd9 Compare November 10, 2017 19:42
@skoef
Copy link
Contributor Author

skoef commented Nov 10, 2017

hmm, I think something went wrong rebasing. I merged master in between my development and I see all those commits as well instead of 1 merge commit. Should I squash all these commits into 1?

@aboch
Copy link
Collaborator

aboch commented Nov 10, 2017

git fetch <upstream> master && git rebase <upstream> master, fix conflicts, git rebase --continue, git push origin <branch>:<branch> -f

@aboch
Copy link
Collaborator

aboch commented Nov 10, 2017

Thanks @skoef . Please --signoff your commit.

Signed-off-by: Reinier Schoof <reinier@skoef.nl>
@skoef
Copy link
Contributor Author

skoef commented Nov 11, 2017

I just did, happy to help!

@skoef
Copy link
Contributor Author

skoef commented Nov 13, 2017

Not sure how this TestRuleAddDel test fails since I've signed-off the commit, I didn't touch that code at all.

@aboch
Copy link
Collaborator

aboch commented Nov 13, 2017

Thanks @skoef , LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants