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

nat46-module: Add support for Netlink sockets #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

srsmiraato
Copy link

The module uses procfs for communication between the
user and kernel space.

Add support to use Netlink, and updated README.md for
instructions to enable this support.

The module uses procfs for communication between the
user and kernel space.

Add support to use Netlink, and updated README.md for
instructions to enable this support.
Copy link
Owner

@ayourtch ayourtch left a comment

Choose a reason for hiding this comment

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

Overall question: "why?" Netlink/ioctl-type configuration is traditionally done with the structs, with userspace tools parsing the data, and that is the whole point of it, and why I did not do it. This patch just moves the same string-based API into netlink - why ?

@@ -50,6 +57,10 @@
#define NAT46_VERSION __DATE__ " " __TIME__
#endif

#ifdef PROTO_NETLINK
#define NETLINK_USER 31
Copy link
Owner

Choose a reason for hiding this comment

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

What is the source of the magic value "31" ? Does the code work if you change it "42" here ? If not - it is probably defined somewhere as 31, so that file would need to be included instead of the #define here...

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the feedback. I'll keep your suggestion in mind as I update my patch.

struct netlink_kernel_cfg nl_cfg = {
.input = nat46_nl_recv_msg
};
printk("nat46: module (version %s) loaded.\n", NAT46_VERSION);
Copy link
Owner

Choose a reason for hiding this comment

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

Two places printing the exact same content is confusing. If anything, this place should print something about procfs support not present, please use netlink.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the feedback. I'll keep your suggestion in mind as I update my patch.

nl_sk = netlink_kernel_create(&init_net, NETLINK_USER, &nl_cfg);
if (!nl_sk)
{
printk(KERN_ALERT "nat46: error creating socket\n");
Copy link
Owner

Choose a reason for hiding this comment

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

Should be more descriptive. Mention that it is a netlink control socket.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the feedback. I'll keep your suggestion in mind as I update my patch.

pid = nl_hdr->nlmsg_pid;
cmd = (char *) nlmsg_data (nl_hdr);

nat46_proc_cmd(cmd);
Copy link
Owner

Choose a reason for hiding this comment

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

nat46_proc_cmd assumes a zero-terminated string which it is always the case for the procfs case. Here the code takes an arbitrary pointer from the message and passes it to the string parsing function without validation. You have to make sure here that the user can trigger the parsing code go beyond the boundary of the cmd.

Also, the whole point of using the netlink and similar structures is to have the parsing of the data done in the user space, and supply well-defined data structures to the kernel space. So - could you describe a little, what is the rationale to use the netlink to pass the strings vs. just using procfs ?

Copy link
Author

Choose a reason for hiding this comment

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

Our system uses Netlink as the interface between kernel and user space, so I thought of having a Netlink socket support for this module to keep things consistent. Thanks for your feedback. I'll keep your suggestions in mind as I update my patch.

To use Netlink sockets instead, add the following to nat46/nat46/modules/Makefile
when compiling:
```
EXTRA_CFLAGS += -DPROTO_NETLINK
Copy link
Owner

Choose a reason for hiding this comment

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

The define should be a bit more specific for NAT46 module and more self-descriptive. NAT46_USE_NETLINK_CONFIG or something like that.

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for your feedback. I'll keep your suggestion in mind as I update my patch.

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