Re: Proposed interface for per-packet mesh-ttl
On 7/30/07, Stephen Hemminger [EMAIL PROTECTED] wrote: it would need an IP ttl to mesh mapping. The fundamental thing is to try and avoid topology specific options bleeding all the way up the socket layer, especially since the network layer is involved and may need to multipath. I think the cleanest way would be to add a ll_ttl (ll for link layer) field to struct sock and a SO_LL_TTL socket option that sets both the field and a flag in sk-flags. This way it is useful for any driver that can do mesh or any other protocol that involves a ttl at link layer (not that I'm aware of any). However I guess you are not supposed to add new socket options nor modify struct socket too often so I'd appreciate feedback on whether this would be considered a good approach. -- Luis Carlos Cobo Rus GnuPG ID: 44019B60 cozybit Inc. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Thu, 16 Aug 2007 12:21:14 -0700 Luis Carlos Cobo [EMAIL PROTECTED] wrote: On 7/30/07, Stephen Hemminger [EMAIL PROTECTED] wrote: it would need an IP ttl to mesh mapping. The fundamental thing is to try and avoid topology specific options bleeding all the way up the socket layer, especially since the network layer is involved and may need to multipath. I think the cleanest way would be to add a ll_ttl (ll for link layer) field to struct sock and a SO_LL_TTL socket option that sets both the field and a flag in sk-flags. This way it is useful for any driver that can do mesh or any other protocol that involves a ttl at link layer (not that I'm aware of any). However I guess you are not supposed to add new socket options nor modify struct socket too often so I'd appreciate feedback on whether this would be considered a good approach. -- Luis Carlos Cobo Rus GnuPG ID: 44019B60 cozybit Inc. The problem with socket options is how does the application know the correct policy? Pushing configuration to application is just deferring the problem, not solving it. You want some policy to be done by the infrastructure; that means kernel, libraries, daemons, etc. Doing it in the application is often inflexible and unusable. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On 8/16/07, Stephen Hemminger [EMAIL PROTECTED] wrote: The problem with socket options is how does the application know the correct policy? Pushing configuration to application is just deferring the problem, not solving it. You want some policy to be done by the infrastructure; that means kernel, libraries, daemons, etc. Doing it in the application is often inflexible and unusable. The policy will usually be done by the kernel. If the flag is not set, which will happen most of the time, the driver will use a sensible default ttl. The socket option would only be used by applications that are specifically interested in a configurable ttl (like an application to plot neighbors within an specific diameter). A per-interface setting is not good enough, since we do not want the neighbor-plotting tool to affect the ttl of other connections (e.g. a ssh session) that might be going on at the same time. -- Luis Carlos Cobo Rus GnuPG ID: 44019B60 cozybit Inc. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
Hi Stephen, On 7/27/07, Stephen Hemminger [EMAIL PROTECTED] wrote: In this case perhaps you can have a table that maps skb-priority to mesh ttl? priorty can already by handled by existing setsockopt calls, and modified by netfilter and QoS managements. Thanks for the feedback. IMHO overloading the [SOL_SOCKET] SO_PRIORITY sockoption for something as different as changing the mesh-ttl is quite a stretch. But I admit that it meets the driver requirements of never add sockopt and not [ab]use netfilter hooks. If that's acceptable to all, I'll modify the patch in that direction. Cheers, Javier - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Mon, 30 Jul 2007 13:37:20 -0700 Javier Cardona [EMAIL PROTECTED] wrote: Hi Stephen, On 7/27/07, Stephen Hemminger [EMAIL PROTECTED] wrote: In this case perhaps you can have a table that maps skb-priority to mesh ttl? priorty can already by handled by existing setsockopt calls, and modified by netfilter and QoS managements. Thanks for the feedback. IMHO overloading the [SOL_SOCKET] SO_PRIORITY sockoption for something as different as changing the mesh-ttl is quite a stretch. But I admit that it meets the driver requirements of never add sockopt and not [ab]use netfilter hooks. If that's acceptable to all, I'll modify the patch in that direction. Cheers, Javier Take it as idea not a proscription. You can use TC rules to rewrite the priority. It is kind of like how priority is being mapped to TOS already in softmac. Alternatively, the TTL can be set with sockopt, but it is a IP so it would need an IP ttl to mesh mapping. The fundamental thing is to try and avoid topology specific options bleeding all the way up the socket layer, especially since the network layer is involved and may need to multipath. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Fri, 27 Jul 2007 18:22:22 -0400 Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote: On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: I'm currently working on per-packet mesh ttl. My plan is to register new mesh sockopts through netfilter. The user interface will be: NACK. Drivers should never add sockopt, and drivers should not abuse netfilter hooks. Do you have a suggestion for a better way to approach per-packet options that userspace programs can set? Thanks, Dan In this case perhaps you can have a table that maps skb-priority to mesh ttl? priorty can already by handled by existing setsockopt calls, and modified by netfilter and QoS managements. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: I'm currently working on per-packet mesh ttl. My plan is to register new mesh sockopts through netfilter. The user interface will be: NACK. Drivers should never add sockopt, and drivers should not abuse netfilter hooks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote: On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: I'm currently working on per-packet mesh ttl. My plan is to register new mesh sockopts through netfilter. The user interface will be: NACK. Drivers should never add sockopt, and drivers should not abuse netfilter hooks. Do you have a suggestion for a better way to approach per-packet options that userspace programs can set? Thanks, Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Tue, 2007-07-03 at 12:29 -0700, Javier Cardona wrote:
David Woodhouse suggested that this list is a more appropriate forum
for my message...
Attached is Javier's proposed patch for this. Please flame away.
Dan
---
Resent per Dan's request.
Support for using setsockpt() to change the mesh-ttl on a network flow, i.e.
snip
sock = socket (PF_INET, SOCK_STREAM, 0);
setsockopt(sock, SOL_IP, MESH_SO_SET_TTL, ttl, optlen);
ttl = 0;
getsockopt(sock, SOL_IP, MESH_SO_GET_TTL, ttl, optlen);
/snip
Signed-off-by: Javier Cardona [EMAIL PROTECTED]
---
drivers/net/wireless/Kconfig |7 +
drivers/net/wireless/libertas/Makefile|1 +
drivers/net/wireless/libertas/decl.h |3 +
drivers/net/wireless/libertas/hostcmd.h |6 +
drivers/net/wireless/libertas/mesh_opts.c | 174 +
drivers/net/wireless/libertas/mesh_opts.h |5 +
drivers/net/wireless/libertas/tx.c| 46 +++-
include/linux/in.h|3 +
8 files changed, 241 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 1146f3d..f4123c3 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -294,6 +294,13 @@ config LIBERTAS_USB
---help---
A driver for Marvell Libertas 8388 USB devices.
+config LIBERTAS_MESH_OPTS
+ tristate Mesh Configuration Options for Libertas USB 802.11b/g cards
+ depends on LIBERTAS_USB NETFILTER
+ ---help---
+ This module enables the configuration of mesh parameters on a
+ per-socket basis, via setsockopt() calls.
+
config LIBERTAS_DEBUG
bool Enable full debugging output in the Libertas module.
depends on LIBERTAS
diff --git a/drivers/net/wireless/libertas/Makefile
b/drivers/net/wireless/libertas/Makefile
index 71c5a25..a31d4f7 100644
--- a/drivers/net/wireless/libertas/Makefile
+++ b/drivers/net/wireless/libertas/Makefile
@@ -18,3 +18,4 @@ usb8xxx-objs += if_usb.o
obj-$(CONFIG_LIBERTAS) += libertas.o
obj-$(CONFIG_LIBERTAS_USB) += usb8xxx.o
+obj-m += mesh_opts.o
diff --git a/drivers/net/wireless/libertas/decl.h
b/drivers/net/wireless/libertas/decl.h
index 4d553da..2cbc137 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -14,6 +14,7 @@
struct wlan_private;
struct sk_buff;
struct net_device;
+struct mesh_options;
extern char *libertas_fw_name;
@@ -86,6 +87,8 @@ int libertas_activate_card(wlan_private *priv, char *fw_name);
int libertas_remove_card(wlan_private *priv);
int libertas_add_mesh(wlan_private *priv, struct device *dev);
void libertas_remove_mesh(wlan_private *priv);
+int libertas_register_mesh_opts(struct mesh_options *);
+int libertas_unregister_mesh_opts(struct mesh_options *);
#endif /* _WLAN_DECL_H_ */
diff --git a/drivers/net/wireless/libertas/hostcmd.h
b/drivers/net/wireless/libertas/hostcmd.h
index 0f67cba..bc86ed0 100644
--- a/drivers/net/wireless/libertas/hostcmd.h
+++ b/drivers/net/wireless/libertas/hostcmd.h
@@ -34,6 +34,12 @@ struct txpd {
u8 reserved1;
};
+struct txpd_mesh {
+ __le16 reserved;
+ /* mesh ttl */
+ u8 ttl;
+} __attribute__ ((packed));
+
/* RxPD Descriptor */
struct rxpd {
/* Current Rx packet status */
diff --git a/drivers/net/wireless/libertas/mesh_opts.c
b/drivers/net/wireless/libertas/mesh_opts.c
new file mode 100644
index 000..118eaed
--- /dev/null
+++ b/drivers/net/wireless/libertas/mesh_opts.c
@@ -0,0 +1,174 @@
+/*
+ * mesh_opts
+ *
+ * Author: Javier Cardona [EMAIL PROTECTED]
+ * Copyright: Marvell Semiconductors Inc., 2007
+ *
+ * Apply mesh-layer specific configuration to network flows. Currently this
+ * only supports the mesh TTL parameter.
+ *
+ * Users call setsockopt on sockets to configure mesh parameters. This module
+ * maintains a list of sockets (mesh_sks) that have different mesh parameters
+ * than the per-interface defaults. The driver will modify the mesh
+ * configuration for each outgoing frame that belongs to one of the sockets in
+ * the mesh_sks list.
+ */
+
+#include linux/module.h
+#include linux/list.h
+#include linux/net.h
+#include linux/in.h
+#include linux/netfilter.h
+#include linux/netfilter_ipv4.h
+#include linux/netfilter_ipv6.h
+#include linux/spinlock.h
+#include net/sock.h
+
+#include asm/uaccess.h
+
+#include mesh_opts.h
+
+#define MESH_SO_BASE_CTL MESH_SO_SET_TTL
+
+static struct list_head mesh_sks = LIST_HEAD_INIT(mesh_sks);
+static DEFINE_RWLOCK(mesh_sks_lock);
+
+struct mesh_sock {
+ struct list_head list;
+
+ struct sock *sk;
+ unsigned char ttl;
+ void (*orig_sk_destruct) (struct sock *sk);
+};
+
+static struct mesh_sock * lookup_socket(struct sock *sk)
+{
+ struct mesh_sock *mesh_sk;
+ struct mesh_sock *found_sk = NULL;
+
+ read_lock(mesh_sks_lock);
