* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-07-29 14:45
> Subscription is a netlink socket option, which, if enabled, ends up
> in direct message delivering, but not multicast one.
I don't get this, you introduce a new option which basically
changes the subscription schema from a bitmask to a sing
* Harald Welte <[EMAIL PROTECTED]> 2005-07-30 12:30
> This (long-awaited) patch adds the generic nfnetlink-based userspace
> logging. nfnetlink_log can be used for any protocol family, and
> supports upt to 65535 logging groups (that could go to separate logging
> daemons, e.g.).
Same very minor
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-08-07 15:19
> On Sun, Aug 07, 2005 at 01:12:19PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > I don't get this, you introduce a new option which basically
> > changes the subscription schema from a bitmask to a singl
* Harald Welte <[EMAIL PROTECTED]> 2005-08-07 17:03
> On Sun, Aug 07, 2005 at 01:20:39PM +0200, Thomas Graf wrote:
> > Same very minor issues as nfnetlink regarding some of the
> > new netlink message construction policies. I'll "fix" them
> > du
* Anand SVR <[EMAIL PROTECTED]> 2005-08-08 15:07
> I am happy to know that there is a way of achieving http level packet
> classification once the connection tracking is also in place. We can
> even think of other string combinations for url based classification,
> not just what I mentioned in my
* Herbert Xu <[EMAIL PROTECTED]> 2005-08-08 21:49
> On Mon, Aug 08, 2005 at 12:46:30PM +0200, Patrick McHardy wrote:
> >
> > part on top of netlink). Right now there are none, so this won't cause
> > any trouble, the question is if we want to retain the possibility or
> > just don't care about this
* Ralf Baechle <[EMAIL PROTECTED]> 2005-08-12 14:39
> On Fri, Aug 12, 2005 at 02:27:59PM +0100, Ralf Baechle wrote:
>
> > > Something I noticed doing the tty work. the 6pack driver calls
> > > netif_start_queue() before it calls register_netdev. I'm curious if this
> > > is allowed ?
> >
> > As p
* David S. Miller <[EMAIL PROTECTED]> 2005-08-13 15:20
> From: Tommy Christensen <[EMAIL PROTECTED]>
> > First thing I'd try is to remove the ! from these two tests.
>
> Duh, thanks for catching that obvious error :-)
I guess my mind was or still is lost in the woods of Alaska.
-
To unsubscribe f
* David S. Miller <[EMAIL PROTECTED]> 2005-08-13 14:10
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Sat, 13 Aug 2005 11:32:39 +1000
>
> > I actually had a play with the fast clone stuff. However, eventually
> > I gave up because of this dilemma: I needed to either introduce an extra
> > atomic
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:36
> [NETLINK]: Support dynamic number of multicast groups per netlink family
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
> - if ((err = __netlink_create(sock, protocol) < 0))
> + nlk->groups = kmalloc(NLGRPSZ(groups), GFP_
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:35
> besides a small bugfix, this patchset adds support for dynamic number
> of groups to netlink. To support an arbitary number of groups a couple
> of changes had to me made, I'll explain them below. The patches are
> only sent to netdev to avoi
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-14 15:30
> Thomas Graf wrote:
> > * Patrick McHardy <[EMAIL PROTECTED]> 2005-08-13 02:36
> >
> >>[NETLINK]: Support dynamic number of multicast groups per netlink family
> >>
> >>Signed-off-by: Pat
* David S. Miller <[EMAIL PROTECTED]> 2005-08-14 17:56
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 15 Aug 2005 10:42:44 +1000
>
> > Well I don't think I understand the new skb->user solution yet :)
> >
> > For a start, skb->users will prevent the skb->data area from being
> > freed as wel
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -400,7 +400,7 @@ int ip_rcv(struct sk_buff *skb, st
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -279,6 +279,58 @@ int ip_local_deliver(struct sk_buf
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_output.c
===
--- net-2.6.14.orig/net/ipv4/ip_output.c
+++ net-2.6.14/net/ipv4/ip_output.c
@@ -200,7 +200,7 @@ static inline int ip_finish_output
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -361,6 +361,7 @@ drop:
int ip_rcv(struct sk_buff *skb,
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/include/asm-i386/checksum.h
===
--- net-2.6.14.orig/include/asm-i386/checksum.h
+++ net-2.6.14/include/asm-i386/checksum.h
@@ -83,7 +83,7 @@ static inline un
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv4/ip_input.c
===
--- net-2.6.14.orig/net/ipv4/ip_input.c
+++ net-2.6.14/net/ipv4/ip_input.c
@@ -333,16 +333,16 @@ drop:
static inline int ip_rcv_finish(
* Andi Kleen <[EMAIL PROTECTED]> 2005-08-20 03:33
> On Sat, Aug 20, 2005 at 03:14:15AM +0200, Thomas Graf wrote:
> > + len = ntohs(iph->tot_len);
> > + if (skb->len < len || len < (iph->ihl*4))
> > + goto inhdr_error;
>
> If you re
* Thomas Graf <[EMAIL PROTECTED]> 2005-08-20 15:44
> I can't see how a <= b <= c can be enforced in less than two
> branches.
Without using a flag risking to have 4 branches when there is
no such thing as cmov that is.
-
To unsubscribe from this list: send the line &quo
Pablo,
* Pablo Neira <[EMAIL PROTECTED]> 2005-08-20 16:35
> Attached the implementation of the Boyer-Moore[1] string search
> algorithm for brand new textsearch infrastructure.
Are you aware that this implementation is only correct under
the assumption that a pattern is never spread over mutlipl
* David S. Miller <[EMAIL PROTECTED]> 2005-08-22 10:07
> I don't want to create too much conflicts with your MIPV6
> work. Would you prefer to integrate Thomas's cleanups into
> your tree? Please let me know.
We can also wait and I'll merge those patches once you're
both in sync again, no proble
cking
requirements of qdisc_destroy() but since the qdisc could
never be seen by the outside world this doesn't matter
and it can stay as-is until the locking of pkt_sched
is cleaned up.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/sch
Collection of cleanups for fib6_lookup() that used to live in my tree
for a while now.
Yoshfuji-san, what's the plan for CONFIG_IPV6_SUBTREES? Is MIPL
going to use it or can we remove it? For now I manually compiled
with CONFIG_IPV6_SUBTREES=1 but I have no idea how to actually
test it.
-
To unsu
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/include/net/ip6_fib.h
===
--- net-2.6.14.orig/include/net/ip6_fib.h
+++ net-2.6.14/include/net/ip6_fib.h
@@ -124,6 +124,11 @@ struct rt6_statistics {
#define RT
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -623,18 +623,12 @@ static struct fib6_node * fib6_lo
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -198,6 +198,10 @@ static __inline__ void rt6_release
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -617,11 +617,10 @@ static inline struct fib6_node *fib6_des
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.14/net/ipv6/ip6_fib.c
===
--- net-2.6.14.orig/net/ipv6/ip6_fib.c
+++ net-2.6.14/net/ipv6/ip6_fib.c
@@ -588,33 +588,35 @@ struct lookup_args {
struct in6_addr
* Patrick McHardy <[EMAIL PROTECTED]> 2005-08-22 23:38
> @@ -1364,7 +1365,7 @@ fn_trie_lookup(struct fib_table *tb, con
> }
>
> if (IS_LEAF(n)) {
> - if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
> res, &ret))
> + if ((re
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 09:15
> There are actually some non-trivial issues wrt. this. We would
> need to loop inside of the packet scheduler, and netfilter, to do
> correct traffic classification and firewalling.
>
> But I guess we could deal with that by supporting chain
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 10:35
> Currently NETIF_F_SG drivers do not wake up the TX queue
> until MAX_SKB_FRAGS descriptors are ready, now they'll
> have to defer until (N * MAX_SKB_FRAGS) are available.
>
> And even for a low value of "N" like 3 this is a whopping _54_ TX
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 10:48
> @@ -1508,7 +1508,7 @@ fn_trie_lookup(struct fib_table *tb, con
> continue;
> }
> if (IS_LEAF(n)) {
> - if (check_leaf(t, (struct leaf *)n, key, &plen, flp,
> res, &ret))
>
* Patrick McHardy <[EMAIL PROTECTED]> 2005-11-05 05:28
> The reason why all routes are deleted is because their prefered
> source addresses is the primary address. fn_flush_list should
> probably send the missing notifications for the deleted routes.
> Changing address promotion to not delete the o
> > Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
> > any notification.
>
> Flushes do not generate notifications. The reason is technical: they
> are usually massive, do overflow buffer, get lost and listeners have
> to do painful resynchronization. The justification: they are
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-07 00:42
> -userspace interaction, including userspace supplicant + locking of
> operstate_useroverride
> -migrate VLAN + BONDING to use OPER_LOWERLAYERDOWN
I think that bonding should check on the administrative status of
its slaves as well. Why not che
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-07 17:41
> > Can't we put the driver, stacked interface, etc. in charge for dropping
> > packets which shouldn't be let through yet? I would favour this and have
> > the dormant state limited to link layer responsibilities.
>
> Imagine this situation:
>
* Krzysztof Halasa <[EMAIL PROTECTED]> 2005-11-07 18:04
> Thomas Graf <[EMAIL PROTECTED]> writes:
> > void netif_carrier_on(struct net_device *dev)
> > {
> > + if ((dev->flags & IFF_WAIT) &&
> > + test_bit(__LINK_STATE_NOCARRI
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-07 20:25
> dose:~ # ip addr add 192.168.200.1/24 dev eth1
> dose:~ # ip link set eth1 up
> dose:~ # ifconfig eth1 | fgrep UP
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> dose:~ # ip route show 192.168.200.0/24
> 192.168.200.0/24 dev eth1 proto
* Thomas Graf <[EMAIL PROTECTED]> 2005-11-05 14:46
> Assuming this is a separate bug, I'm not sure if this is the right
> way to fix it. I think it would be better to rewrite the preferred
> source address of all related local routes and only perform a
> remove-and-add o
* Hasso Tepper <[EMAIL PROTECTED]> 2005-11-08 14:55
> Thomas Graf wrote:
> > Then how are you going to implement OSPF which has its own link state
> > detection?
>
> OSPF doesn't have any link state detection. If carrier is up, hello
> packets are sent out to th
* Hasso Tepper <[EMAIL PROTECTED]> 2005-11-08 15:39
> The same is true for any OSPF link. Only periodical hellos are used for
> that in standard case. Demand circuits are there to suppress periodical
> hellos and link state update refreshes - ie. if there is no real
> application traffic going over
* Hasso Tepper <[EMAIL PROTECTED]> 2005-11-08 17:14
> OSPF doesn't care if there is connected route or not if !IFF_RUNNING. And
> it doesn't matter if it's demand circuit or usual one. If kernel reports
> link down (!IFF_RUNNING), no any packets are sent over this link -
> hellos, LS updates etc. H
g
--- a/ChangeLog 2005-03-19 00:49:52 +01:00
+++ b/ChangeLog 2005-03-19 00:49:52 +01:00
@@ -1,3 +1,8 @@
+2005-03-19 Thomas Graf <[EMAIL PROTECTED]>
+
+ * Warn about wildcard deletions and provide IFA_ADDRESS upon
+ deletions to enforce prefix length validation for IPv4.
+
2005-
> > We're talking about the auto routes in the main table, right? There
> > is no reason for the addresses to be configured as a prefix, they
> > can, and in my opinion should, be added as /~0 if the net is not
> > guaranteed to be reachable at exactly this interface at all times.
> > e.g. a user a
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-09 17:13
> Am Mittwoch 09 November 2005 15:25 schrieb Thomas Graf:
>
> > It's still behind eth3 but not reachable at the moment. If you know
> > that the network can be reached via other interfaces then just don't
> &
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-09 15:13
> The link change notification should be handled by the fib code as if it
> was an admin notification.
Something like this should do the job, although it doesn't take care
of taking things up again for now. Now all supporters of this should
t
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-09 22:02
> My main concern here are dial on demand interfaces. Routes pointing to them
> must be considered even if the interface is !OPER_UP. Routes pointing to
> "permanent" interfaces in !OPER_UP should not.
Right, we do need a dormant state with all
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 00:09
> + OPER_UNKNOWN = 0,
> + OPER_NOTPRESENT, /* unused, placeholder */
> + OPER_DOWN = 16,
> + OPER_LOWERLAYERDOWN,
> + OPER_TESTING = 32,
> + OPER_DORMANTL3DOWN = 48, /* OS queue start from here */
> + OPER
> > Index: linux-2.6/net/ipv4/fib_frontend.c
> > ===
> > --- linux-2.6.orig/net/ipv4/fib_frontend.c
> > +++ linux-2.6/net/ipv4/fib_frontend.c
> > @@ -630,8 +630,13 @@ static int fib_netdev_event(struct notif
> > case NETDEV_DOW
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-09 18:49
> Historically we point such routes to the dummy device. Remember diald
> and good ole SLIP dial on demand? I would suspect it should still work
> the same way.
> Actually, probably use a blackhole route which will swallow such packets
> alive
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/xfrm/xfrm_user.c
===
--- net-2.6.orig/net/xfrm/xfrm_user.c
+++ net-2.6/net/xfrm/xfrm_user.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#i
setting
the error pointer to 0 in which case netlink_run_queue() will
return with a qlen != 0.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/af_netlink.c
===
--- net-2.6.orig/net/netlink/af_net
Most netlink families make no use of the done() callback, making
it optional gets rid of all unnecessary dummy implementations.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/af_netlink.c
===
--- n
.
The resulting netlink code should be smaller, less error prone
and easier to understand.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/attr.c
===
--- /dev/null
+++ net-2.6/net/netlink/attr.c
@@ -0,0
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/core/rtnetlink.c
===
--- net-2.6.orig/net/core/rtnetlink.c
+++ net-2.6/net/core/rtnetlink.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#i
Dave,
This patchset adds a type-safe netlink interface and the generic
netlink family for simplified netlink usage. I did not include
any transformations patch as some of them showed issues. The code
posted here is tested and already in use by external users (TIPC).
-
To unsubscribe from this li
to the current multicast implementation of netlink, the number
of generic netlink modules is restricted to 1024 to avoid wasting
memory for the per socket multiacst subscription bitmask.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/netlink/Ma
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-10 11:00
> Dave - ACK on all 6. Both Thomas and I have tested these and the TIPC
> folks have been playing with them for sometime now; if we get them in
> for 2.6.15 it would help to encourage them to change their API on their
> stable release to use t
* James Morris <[EMAIL PROTECTED]> 2005-11-10 10:15
> For SELinux, we'll need to track genl ID assignment and deletion, so we
> can determine what the Netlink family number means when we see a Netlink
> message. We'll have to assume that the sysadmin has not changed the
> module name.
>
> Forgo
* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-10 10:45
> from inspection: Whats wrong with what netif_carrier_ok() tells you?
> i.e to extrapolate what you have (it seems to be out
> fib_netdev_event())- something along:
>
> case NETDEV_CHANGE:
> rt_cache_flush(0);
>
* Paul Jakma <[EMAIL PROTECTED]> 2005-11-10 23:10
> Why would an on-demand dialup device go ~IFF_RUNNING? The whole point
> of such a device is to /hide/ whether the physical layer is up or
> not.
The state of an on-demand interface must be visible, typically an
on-demand interface is in dormant
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 19:46
> fib_disable_ip() evicts all routes pointing to that interface, including
> userspace generated ones, doesn't it? If so, we don't get away that easy.
Right, the patch represents Jamal's interpretation. Once in a while
I please him by providing
* Herbert Xu <[EMAIL PROTECTED]> 2005-11-12 15:15
> The recent change to netlink dump "done" callback handling broke IPv6
> which played dirty tricks with the "done" callback. This causes an
> infinite loop during a dump.
Absolutely right, thanks.
-
To unsubscribe from this list: send the line "u
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/ipv6/route.c
===
--- net-2.6.orig/net/ipv6/route.c
+++ net-2.6/net/ipv6/route.c
@@ -1732,7 +1732,7 @@ int inet6_dump_fib(struct sk_buf
* jamal <[EMAIL PROTECTED]> 2005-11-13 10:09
> Issue-1)
> We have agreed to implement based on 2863.
> Stefan has gone one step further and suggested extra states for L3
> status. The idea for the extra states being to resolve in this fix old
> standing issue (since 2.2 days) of higher metric rout
> My suggestion is at this point to ignore any L3 issues and have people
> post their patches. RFC 2863 states MUST be taken into consideration.
> Proper naming must be taken into account.
Split up in 3 patches, not implementing the bits allowing userspace to
trigger leaving dormant state.
[NET]
* Pekka Savola <[EMAIL PROTECTED]> 2005-11-16 12:46
> On Mon, 14 Nov 2005, John W. Linville wrote:
> > http://people.redhat.com/linville/kernels/fedora-netdev/
>
> I guess the test can be termed a 'success' because after updating from
> 2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 1
* jamal <[EMAIL PROTECTED]> 2005-11-15 21:16
> 3) There is a kernel dev->operstate_kernel which is accessible via
> user space in the same manner IFF_UP flags are set etc.
Just be careful about synchronization, that's one issue with the
currently proposed implementation. The callers cannot be mad
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2005-11-18 09:47
> In article <[EMAIL PROTECTED]> (at Fri, 18 Nov 2005 08:44:27 +0800), Yan
> Zheng <[EMAIL PROTECTED]> says:
>
> > I get follow message when switch to single user mode and the kernel version
> > is 2.6.15-rc1-git5.
> :
> > No
* Herbert Xu <[EMAIL PROTECTED]> 2005-11-19 22:48
> Thomas Graf <[EMAIL PROTECTED]> wrote:
> >
> > I did. I think it was right, why would an allocation be necessary on
> > the second call to inet6_dump_fib()? The walker allocated in process
> > context on
* David S. Miller <[EMAIL PROTECTED]> 2005-11-22 14:37
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Mon, 21 Nov 2005 17:16:18 +0100
>
> > Adrian Bunk wrote:
> > > This patch therefore changes NET_CLS back to the 2.6.14 status quo of
> > > being an user-visible option.
> >
> > I disagree w
* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-28 14:15
> Hi,
>
> ok, at least some progress has happened:
Looks good, it would be nice if you could separate the vlan part as a
separate patch for later on though.
> -Replaced device-specific oper_state method with NETIF_F_STACKED flag to
> select be
The receive path for fib_lookup netlink messages is lacking sanity
checks for header and payload and is thus vulnerable to malformed
netlink messages causing illegal memory references.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/fib_fron
* Greg KH <[EMAIL PROTECTED]> 2005-12-01 14:21
> On Thu, Dec 01, 2005 at 11:05:12PM +0100, Thomas Graf wrote:
> > The receive path for fib_lookup netlink messages is lacking sanity
> > checks for header and payload and is thus vulnerable to malformed
> > netlink mess
Stefan,
This looks better with every iteration, I'm still lacking a few minor
things though:
The implementation of the rule "if admin status down operational status
should be down" only exists in the sysfs code. I would absolutely favour
one clear interface representing the operational status of
* jamal <[EMAIL PROTECTED]> 2005-12-07 07:56
> How is this different, conceptually, from any other flag setting being
> lost - for example a promisc or admin up/down?
> In other words if you want to reliably transmit state, shouldnt the
> "responsible system" have to worry about the reliability?
>
> > I realized that in fib_rules.c the inet_rtm_new_rule()
> > function adds rules without checking if they already
> > exist. This may result in duplicate rules being added.
> > It makes it difficult to remove a rule when it is
> > added multiple times (with the intention that it would
> > be adde
* Michael Buesch <[EMAIL PROTECTED]> 2006-01-12 18:24
> This is an attempt to rewrite the Wireless Extensions
> userspace API, using netlink sockets.
> There should also be a notification API, to inform
> userspace for changes (config changes, state changes, etc).
> It is not implemented, yet.
I'l
* Patrick McHardy <[EMAIL PROTECTED]> 2006-01-12 06:25
> David S. Miller wrote:
> >From: jamal <[EMAIL PROTECTED]>
> >Date: Tue, 10 Jan 2006 23:02:45 -0500
> >
> >
> >>So it is an optimization - not a bug then, correct?
> >
> >
> >It is only an optimization in as much as it avoids duplicate
> >work
* Per Liden <[EMAIL PROTECTED]> 2006-01-13 09:27
> Increasing the module ref count at registration will block the module from
> ever being unloaded. In fact, genetlink should not care about the owner at
> all. This patch removes the owner field from the struct registered with
> genetlink.
Why shou
This information is already available via /proc/net/bonding/*
therefore it doesn't make sense to require CAP_NET_ADMIN
privileges.
Original patch by Laurent Deniel <[EMAIL PROTECTED]>
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-09-21 14:30
> In article <[EMAIL PROTECTED]> (at Mon, 18 Sep 2006 20:57:46 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
> > Same here, it doesn't make sense to export macros only of functional
> &
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-09-21 12:57
> -int netlbl_netlink_snd_multicast(struct sk_buff *skb, u32 pid, u32 group)
> +int netlbl_netlink_snd_multicast(struct sk_buff *skb,
> + void *buf,
> + u32 pid,
> +
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-09-21 12:57
> At the suggestion of Thomas Graf, rewrite NetLabel's use of Netlink attributes
> to better follow the common Netlink attribute usage.
>
> Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
> ---
> net/n
* Paul Moore <[EMAIL PROTECTED]> 2006-09-25 10:13
> >>- ret_val = netlbl_netlink_snd(ans_skb, info->snd_pid);
> >>+ switch (doi_def->type) {
> >>+ case CIPSO_V4_MAP_STD:
> >>+ nla_a = nla_nest_start(ans_skb, NLBL_CIPSOV4_A_MLSLVLLST);
> >>+ if (nla_a == NULL) {
> >>+
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-09-25 14:04
> This is an updated patchset which takes into account Thomas' comments. This
> includes the addition of two new patches in the patchset which add a new
> Netlink interface as well as correct the list of interfaces in the large
> comment blo
* Johannes Berg <[EMAIL PROTECTED]> 2006-09-26 09:25
> This patch adds an NLA_CUSTOM_CHECK type for netlink attributes
> in order to be able to centrally define new attribute structures
> instead of having to check these special types in each function
> that uses such an attribute.
Thinking it ove
Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund <[EMAIL PROTECTED]>
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/sched/cls_basic.c
===
---
* Patrick McHardy <[EMAIL PROTECTED]> 2006-09-26 15:32
> Thomas Graf wrote:
> > Prevents filters from being added if the first generated
> > handle already exists.
> >
> > Signed-off-by: Kim Nordlund <[EMAIL PROTECTED]>
> > Signed-off-by: Thomas Gra
* Nordlund Kim (Nokia-NET/Helsinki) <[EMAIL PROTECTED]> 2006-09-27 11:50
> basic_change() won't work without this patch if we compile the
> kernel with the GCC version in RHEL5...
>
> gcc version 4.1.1 20060817 (Red Hat 4.1.1-18)
>
> which optimizes the code like this (objdump -S inttest.c) ...
>
* Patrick McHardy <[EMAIL PROTECTED]> 2006-09-27 11:44
> Thomas Graf wrote:
> > * Nordlund Kim (Nokia-NET/Helsinki) <[EMAIL PROTECTED]> 2006-09-27 11:50
> >
> >>So I would suggest to apply this patch to be compatible with the
> >>GCC version in R
* Johannes Berg <[EMAIL PROTECTED]> 2006-09-27 14:18
> On Tue, 2006-09-26 at 11:44 +0200, Thomas Graf wrote:
>
> > Thinking it over I'm still not completely happy with this. A
> > small subset of all the validation tasks is simply too complex
> > to be put into
source address is available.
Thanks to Kim Nordlund <[EMAIL PROTECTED]> for working
on this patch with me.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/net/ipv6/fib6_rules.c
===
--- net-2.6.orig/net/ipv6/
* Ville Nuorvala <[EMAIL PROTECTED]> 2006-10-17 03:27
> @@ -123,7 +111,7 @@ static int fib6_rule_match(struct fib_ru
> return 0;
>
> if (r->src.plen) {
> - if (!(flags & RT6_LOOKUP_F_HAS_SADDR) ||
> + if (flags & RT6_LOOKUP_F_HAS_SADDR &&
>
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-10-17 20:00
> In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 12:14:02 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
>
> > * Ville Nuorvala <[EMAIL PROTECTED]> 2006-10-17 03:27
> > >
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-10-17 21:17
> In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 13:35:11 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
>
> :
> > different logic. In order to solve this, rules must be restricted to
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/include/net/ip_fib.h
===
--- net-2.6.orig/include/net/ip_fib.h 2006-10-17 14:35:00.0 +0200
+++ net-2.6/include/net/ip_fib.h2006-10-17 14:36:16.000
Lookups resolving to ip6_blk_hole_entry must result in silently
discarding the packets whereas an ip6_pkt_prohibit_entry is
supposed to cause an ICMPV6_ADM_PROHIBITED message to be sent.
Thanks to Kim Nordlund <[EMAIL PROTECTED]> for noticing
this bug.
Signed-off-by: Thomas Graf &
901 - 1000 of 1030 matches
Mail list logo
