[PATCH] netbios broadcast connection tracking module

[PATCH] netbios broadcast connection tracking module

[Alexander Larsson]

I'm re-sending this, in the hope that someone will be interested enough
to at least comment on the code/approach this time.

I'd like to make the default Fedora firewall allow packets related to
SMB browsing to be accepted, so that clients such as Nautilus and
konqueror (and smbclient) can enumerate the availble SMB shares.

What happens here is that the smb browser client sends a local udp
broadcast to port 137, and then local servers reply to this from port
137 to the port the broadcast was sent to. However, since these replies
come from another address than the broadcast was sent to, the udp
conntrack module doesn't help here.

So, I've written a small conntrack helper that makes replies to such a
broadcast package be reported as a RELATED connection. This means the
default firewall will allow them through.

The module code is below. This is my first ever look at the netfilter code, 
so please look for stupid mistakes. Also, is there any other possible
solution to this problem that I've missed? I tried using the "recent"
module, but that doesn't save/match against the port, so i couldn't use
that.

Maybe the module should also verify that the replies are from the local
subnet? I'm not sure how to get the mask of the subnet the package will
be sent to though, because skbuff->dev is NULL when my helper gets
called.

----------- ip_conntrack_netbios_ns.c ---------------

#include <linux/module.h>
#include <linux/ip.h>
#include <linux/udp.h>

#include <linux/netfilter.h>
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ip_conntrack_helper.h>

MODULE_AUTHOR("Alexander Larsson <alexl@redhat.com>");
MODULE_DESCRIPTION("netbios ns conntrack helper");
MODULE_LICENSE("GPL");

#define NETBIOS_NS_PORT 137
#define NETBIOS_NS_REPLY_TIMEOUT 20

#if 0
#define DEBUGP(format, args...) printk(KERN_ERR "%s:" format, \
                                       __FUNCTION__ , ## args)
#else
#define DEBUGP(format, args...)
#endif

static int netbios_ns_help(struct sk_buff *skb,
			   struct ip_conntrack *ct,
			   enum ip_conntrack_info ctinfo)
{
	struct ip_conntrack_expect *exp;

	exp = ip_conntrack_expect_alloc();
	if (exp == NULL)
		return NF_ACCEPT;
	
	exp->tuple = ct->tuplehash[IP_CT_DIR_REPLY].tuple;
	exp->mask.src.ip = 0;
	exp->mask.dst.ip = 0xffffffff;
	exp->mask.dst.u.udp.port = 0xffff;
	exp->mask.dst.protonum = 0xffff;
	exp->expectfn = NULL;
	
	ip_conntrack_expect_related(exp, ct);
	
	return NF_ACCEPT;
}

static struct ip_conntrack_helper netbios_ns;

static int __init init(void)
{
	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));

	netbios_ns.name = "netbios-ns";
	netbios_ns.max_expected = 0; /* No maximum */
	netbios_ns.timeout = NETBIOS_NS_REPLY_TIMEOUT;
	netbios_ns.flags = IP_CT_HELPER_F_REUSE_EXPECT;
	netbios_ns.me = THIS_MODULE;
	netbios_ns.help = netbios_ns_help;
	
	netbios_ns.tuple.dst.protonum = IPPROTO_UDP;
	netbios_ns.mask.dst.protonum = 0xFFFF;
	netbios_ns.tuple.src.u.udp.port = htons(NETBIOS_NS_PORT);
	netbios_ns.mask.src.u.udp.port = 0xFFFF;
	
	return ip_conntrack_helper_register(&netbios_ns);
}

static void fini(void)
{
	ip_conntrack_helper_unregister(&netbios_ns);
}

PROVIDES_CONNTRACK(netbios_ns);

module_init(init);
module_exit(fini);


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a gun-slinging ninja sorceror from the 'hood. She's a provocative 
wisecracking politician who hides her beauty behind a pair of thick-framed 
spectacles. They fight crime! 

Re: [PATCH] netbios broadcast connection tracking module

[Martin Josefsson]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

On Tue, 2004-10-19 at 10:49, Alexander Larsson wrote:

Hi Alexander

> What happens here is that the smb browser client sends a local udp
> broadcast to port 137, and then local servers reply to this from port
> 137 to the port the broadcast was sent to. However, since these replies
> come from another address than the broadcast was sent to, the udp
> conntrack module doesn't help here.

So both source and destination port is 137 in the replies?
And by looking at your code, it's the same in the broadcast as well.
(since the source port of the broadcast is what is used as
destinationport in the reply)

> So, I've written a small conntrack helper that makes replies to such a
> broadcast package be reported as a RELATED connection. This means the
> default firewall will allow them through.

s/replies/the first reply/

The expectation will get removed from the expectation-list when a packet
matches the expectation.

And it's not possible to register multiple identical expectations since
when only thing that happens then is that the timeout of the first
expectation is updated.

> The module code is below. This is my first ever look at the netfilter code, 
> so please look for stupid mistakes. Also, is there any other possible
> solution to this problem that I've missed? I tried using the "recent"
> module, but that doesn't save/match against the port, so i couldn't use
> that.

I think it should be possible to use recent, maybe something like this?

iptables -A OUTPUT -p udp -d $broadcast --sport 137 --dport 137 -m recent --set --rsource --name netbios_ns -j ACCEPT
iptables -A INPUT -p udp --sport 137 --dport 137 -m pkttype --pkt-type unicast -m recent --rcheck --rdest --seconds 20 --name netbios_ns -j ACCEPT

That should add the sourceaddress of the outgoing broadcast to the
recent list called "netbios_ns". Unfortunately we can't use the pkttype
match for outgoing packets, that would have been neat for only adding
broadcast packets automatically without having to specify the broadcast
address.

And then destination ip of incoming udp packets from port 137 to port
137 that are unicast packets are checked against the same recent list
and if the ipaddresses match we accept the packet.
(the pkttype match isn't really needed)

Would that work?

[snip]

> static int __init init(void)
> {
> 	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));
> 
> 	netbios_ns.name = "netbios-ns";
> 	netbios_ns.max_expected = 0; /* No maximum */
> 	netbios_ns.timeout = NETBIOS_NS_REPLY_TIMEOUT;
> 	netbios_ns.flags = IP_CT_HELPER_F_REUSE_EXPECT;

IP_CT_HELPER_F_REUSE_EXPECT is only used if you have set max_expected to
a nonzero value, there's nothing to reuse when there's no maximum.

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] netbios broadcast connection tracking module

[Alexander Larsson]

On Tue, 2004-10-19 at 19:23 +0200, Martin Josefsson wrote:
> On Tue, 2004-10-19 at 10:49, Alexander Larsson wrote:
> 
> Hi Alexander
> 
> > What happens here is that the smb browser client sends a local udp
> > broadcast to port 137, and then local servers reply to this from port
> > 137 to the port the broadcast was sent to. However, since these replies
> > come from another address than the broadcast was sent to, the udp
> > conntrack module doesn't help here.
> 
> So both source and destination port is 137 in the replies?
> And by looking at your code, it's the same in the broadcast as well.
> (since the source port of the broadcast is what is used as
> destinationport in the reply)

No. Let me make an example. The client at 192.168.0.1 sends the
broadcast from a high port (lets say he gets port 55000):

192.168.0.1:55000 -> 192.168.0.255:137

The smb server at 192.168.0.2 answers:
192.168.0.2:137 -> 192.168.0.1:55000

And then the server at 192.168.0.3:
192.168.0.3:137 -> 192.168.0.1:55000

> > So, I've written a small conntrack helper that makes replies to such a
> > broadcast package be reported as a RELATED connection. This means the
> > default firewall will allow them through.
> 
> s/replies/the first reply/
> 
> The expectation will get removed from the expectation-list when a packet
> matches the expectation.
> 
> And it's not possible to register multiple identical expectations since
> when only thing that happens then is that the timeout of the first
> expectation is updated.

Hmm. I though by setting max_expected to 0 would allow me to get
multiple expected replies, but i could easily have misread the code. Is
there no way to expect multiple packets in reply to a single udp
package?

> > The module code is below. This is my first ever look at the netfilter code, 
> > so please look for stupid mistakes. Also, is there any other possible
> > solution to this problem that I've missed? I tried using the "recent"
> > module, but that doesn't save/match against the port, so i couldn't use
> > that.
> 
> I think it should be possible to use recent, maybe something like this?
> 
> iptables -A OUTPUT -p udp -d $broadcast --sport 137 --dport 137 -m recent --set --rsource --name netbios_ns -j ACCEPT
> iptables -A INPUT -p udp --sport 137 --dport 137 -m pkttype --pkt-type unicast -m recent --rcheck --rdest --seconds 20 --name netbios_ns -j ACCEPT
> 
> That should add the sourceaddress of the outgoing broadcast to the
> recent list called "netbios_ns". Unfortunately we can't use the pkttype
> match for outgoing packets, that would have been neat for only adding
> broadcast packets automatically without having to specify the broadcast
> address.
> 
> And then destination ip of incoming udp packets from port 137 to port
> 137 that are unicast packets are checked against the same recent list
> and if the ipaddresses match we accept the packet.
> (the pkttype match isn't really needed)
> 
> Would that work?

No. That doesn't work, because the INPUT rule needs to match the port of
the packet that was matched in the OUTPUT rule. We can't do this,
because recent only allows saving the source or destination ip, not the
port.

> > static int __init init(void)
> > {
> > 	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));
> > 
> > 	netbios_ns.name = "netbios-ns";
> > 	netbios_ns.max_expected = 0; /* No maximum */
> > 	netbios_ns.timeout = NETBIOS_NS_REPLY_TIMEOUT;
> > 	netbios_ns.flags = IP_CT_HELPER_F_REUSE_EXPECT;
> 
> IP_CT_HELPER_F_REUSE_EXPECT is only used if you have set max_expected to
> a nonzero value, there's nothing to reuse when there's no maximum.

Ah.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a suicidal amnesiac filmmaker haunted by memories of 'Nam. She's a 
sharp-shooting insomniac cab driver from a different time and place. They 
fight crime! 

Re: [PATCH] netbios broadcast connection tracking module

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

Hi!

First of all, let me say that I am much in favour of a conntrack helper
than an ipt_recent-based solution.

> Hmm. I though by setting max_expected to 0 would allow me to get
> multiple expected replies, but i could easily have misread the code. Is
> there no way to expect multiple packets in reply to a single udp
> package?

you just need to re-issue the expectation as soon as it is confirmed by
the first packet (from the expectfn).  If I'm not mistaken, there are
already helpers doing that, although I forgot which ones.

>  Alexander Larsson                                            Red Hat, Inc 

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] netbios broadcast connection tracking module

[Alexander Larsson]

On Fri, 2004-10-22 at 12:55 +0200, Harald Welte wrote:
> Hi!
> 
> First of all, let me say that I am much in favour of a conntrack helper
> than an ipt_recent-based solution.
> 
> > Hmm. I though by setting max_expected to 0 would allow me to get
> > multiple expected replies, but i could easily have misread the code. Is
> > there no way to expect multiple packets in reply to a single udp
> > package?
> 
> you just need to re-issue the expectation as soon as it is confirmed by
> the first packet (from the expectfn).  If I'm not mistaken, there are
> already helpers doing that, although I forgot which ones.

I've been experimenting a bit here. And it seems that it *does* accept
several packages after calling ip_conntrack_expect_related(), before the
timeout is passed (although expectfn is only called once). At least if
the packages are from the same ip.

I took a look at ip_conntrack_ftp.c, and it only calls
ip_conntrack_expect_related() from "help". Does this mean it only
accepts one related packet on the side-channel?. Actually, none of the
in-tree conntrack helpers use expectfn.

Anyway, while testing I digged a bit deeper into the netbios traffic
going on here, and it seems like we really only expect one reply anyway.
The broadcast request is basically "who has the name <foo>" or "who is
the local master browser".

Thus, something like this should work fine:

------------------------------------------------------

#include <linux/module.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <linux/delay.h>

#include <linux/netfilter.h>
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ip_conntrack_helper.h>

MODULE_AUTHOR("Alexander Larsson <alexl@redhat.com>");
MODULE_DESCRIPTION("netbios ns conntrack helper");
MODULE_LICENSE("GPL");

#define NETBIOS_NS_PORT 137
#define NETBIOS_NS_REPLY_TIMEOUT 10

#if 0
#define DEBUGP(format, args...) printk(KERN_DEBUG "%s:" format, \
                                       __FUNCTION__ , ## args)
#else
#define DEBUGP(format, args...)
#endif

static int netbios_ns_help(struct sk_buff *skb,
			   struct ip_conntrack *ct,
			   enum ip_conntrack_info ctinfo)
{
	struct ip_conntrack_expect *exp;
	
	exp = ip_conntrack_expect_alloc();
	if (exp == NULL)
		return NF_ACCEPT;

	exp->tuple = ct->tuplehash[IP_CT_DIR_REPLY].tuple;
	exp->mask.src.ip = 0;
	exp->mask.dst.ip = 0xffffffff;
	exp->mask.dst.u.udp.port = 0xffff;
	exp->mask.dst.protonum = 0xffff;
	exp->expectfn = NULL;
	
	ip_conntrack_expect_related(exp, ct);
	
	return NF_ACCEPT;
}

static struct ip_conntrack_helper netbios_ns;

static int __init init(void)
{
	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));

	netbios_ns.name = "netbios-ns";
	netbios_ns.max_expected = 0; /* No maximum */
	netbios_ns.timeout = NETBIOS_NS_REPLY_TIMEOUT;
	netbios_ns.flags = 0;
	netbios_ns.me = THIS_MODULE;
	netbios_ns.help = netbios_ns_help;
	
	netbios_ns.tuple.dst.protonum = IPPROTO_UDP;
	netbios_ns.mask.dst.protonum = 0xFFFF;
	netbios_ns.tuple.src.u.udp.port = htons(NETBIOS_NS_PORT);
	netbios_ns.mask.src.u.udp.port = 0xFFFF;
	
	return ip_conntrack_helper_register(&netbios_ns);
}

static void fini(void)
{
	ip_conntrack_helper_unregister(&netbios_ns);
}

PROVIDES_CONNTRACK(netbios_ns);

module_init(init);
module_exit(fini);


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a scarfaced pirate farmboy from the Mississippi delta. She's a 
cosmopolitan renegade former first lady from aristocratic European stock. They 
fight crime! 

Re: [PATCH] netbios broadcast connection tracking module

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Tue, Oct 26, 2004 at 11:25:57AM +0200, Alexander Larsson wrote:
> On Fri, 2004-10-22 at 12:55 +0200, Harald Welte wrote:
> > Hi!
> > 
> > First of all, let me say that I am much in favour of a conntrack helper
> > than an ipt_recent-based solution.
> > 
> > > Hmm. I though by setting max_expected to 0 would allow me to get
> > > multiple expected replies, but i could easily have misread the code. Is
> > > there no way to expect multiple packets in reply to a single udp
> > > package?
> > 
> > you just need to re-issue the expectation as soon as it is confirmed by
> > the first packet (from the expectfn).  If I'm not mistaken, there are
> > already helpers doing that, although I forgot which ones.
> 
> I've been experimenting a bit here. And it seems that it *does* accept
> several packages after calling ip_conntrack_expect_related(), before the
> timeout is passed (although expectfn is only called once). At least if
> the packages are from the same ip.
> 
> I took a look at ip_conntrack_ftp.c, and it only calls
> ip_conntrack_expect_related() from "help". Does this mean it only
> accepts one related packet on the side-channel?. Actually, none of the
> in-tree conntrack helpers use expectfn.

expectations are on a connection level, not on a per-packet level.
However, broadcast packets don't have connections, since you send
packets to .255 and receive them back from inidividual ip addresses.
Since you don't know how many clients in the broadcast domain will
reply, you need to re-create the expectation every time it is confirmed
(via expectfn).

And yes, I didn't talk about the helpers in the official kernel, more
about stuff from patch-o-matic-ng

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] netbios broadcast connection tracking module

[Martin Josefsson]

On Tue, 26 Oct 2004, Harald Welte wrote:

> expectations are on a connection level, not on a per-packet level.
> However, broadcast packets don't have connections, since you send
> packets to .255 and receive them back from inidividual ip addresses.
> Since you don't know how many clients in the broadcast domain will
> reply, you need to re-create the expectation every time it is confirmed
> (via expectfn).

The reason I didn't suggest this is that it's racy on SMP machines.
It's a very small race but it does exist. Packets may get recieved
on another cpu between the expectation matching and it beeing re-created.

/Martin

Re: [PATCH] netbios broadcast connection tracking module

[Martin Josefsson]

On Tue, 26 Oct 2004, Alexander Larsson wrote:

> > you just need to re-issue the expectation as soon as it is confirmed by
> > the first packet (from the expectfn).  If I'm not mistaken, there are
> > already helpers doing that, although I forgot which ones.
>
> I've been experimenting a bit here. And it seems that it *does* accept
> several packages after calling ip_conntrack_expect_related(), before the
> timeout is passed (although expectfn is only called once). At least if
> the packages are from the same ip.

Yes if it's the same source/destination ip/port and protocol then the
packets match the conntrack entry the first packet set up.

> I took a look at ip_conntrack_ftp.c, and it only calls
> ip_conntrack_expect_related() from "help". Does this mean it only
> accepts one related packet on the side-channel?. Actually, none of the
> in-tree conntrack helpers use expectfn.

Each command in ftp creates one data-channel. This is per connection, not
packet. the data-channels never setup more data-channels.

> Anyway, while testing I digged a bit deeper into the netbios traffic
> going on here, and it seems like we really only expect one reply anyway.
> The broadcast request is basically "who has the name <foo>" or "who is
> the local master browser".

Ok, then it might work fine to just expect one reply.

How about when machines broadcast for a domain controller to login to and
they get multiple replies and tries each one of the servers until it
succeeds? Then we might want to allow multiple replies, but on the other
hand if they answer they should be able to handle the login...

> static struct ip_conntrack_helper netbios_ns;
>
> static int __init init(void)
> {
> 	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));

This memset isn't needed as the BSS is initialized to zero by default in
kernel.

/Martin

Re: [PATCH] netbios broadcast connection tracking module

[Alexander Larsson]

On Tue, 2004-10-26 at 12:11 +0200, Martin Josefsson wrote:
> On Tue, 26 Oct 2004, Alexander Larsson wrote:
> 
> > > you just need to re-issue the expectation as soon as it is confirmed by
> > > the first packet (from the expectfn).  If I'm not mistaken, there are
> > > already helpers doing that, although I forgot which ones.
> >
> > I've been experimenting a bit here. And it seems that it *does* accept
> > several packages after calling ip_conntrack_expect_related(), before the
> > timeout is passed (although expectfn is only called once). At least if
> > the packages are from the same ip.
> 
> Yes if it's the same source/destination ip/port and protocol then the
> packets match the conntrack entry the first packet set up.

Ah.

> > I took a look at ip_conntrack_ftp.c, and it only calls
> > ip_conntrack_expect_related() from "help". Does this mean it only
> > accepts one related packet on the side-channel?. Actually, none of the
> > in-tree conntrack helpers use expectfn.
> 
> Each command in ftp creates one data-channel. This is per connection, not
> packet. the data-channels never setup more data-channels.
> 
> > Anyway, while testing I digged a bit deeper into the netbios traffic
> > going on here, and it seems like we really only expect one reply anyway.
> > The broadcast request is basically "who has the name <foo>" or "who is
> > the local master browser".
> 
> Ok, then it might work fine to just expect one reply.
> 
> How about when machines broadcast for a domain controller to login to and
> they get multiple replies and tries each one of the servers until it
> succeeds? Then we might want to allow multiple replies, but on the other
> hand if they answer they should be able to handle the login...

Is having several domain controllers on the same subnet common? Sounds
pretty unlikely to me.

> > static struct ip_conntrack_helper netbios_ns;
> >
> > static int __init init(void)
> > {
> > 	memset(&netbios_ns, 0, sizeof(struct ip_conntrack_helper));
> 
> This memset isn't needed as the BSS is initialized to zero by default in
> kernel.

Ok.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's an unconventional Catholic dog-catcher with a mysterious suitcase 
handcuffed to his arm. She's a ditzy paranoid mechanic operating on the wrong 
side of the law. They fight crime! 

Re: [PATCH] netbios broadcast connection tracking module

[Alexander Larsson]

On Tue, 2004-10-26 at 11:42 +0200, Harald Welte wrote:
> On Tue, Oct 26, 2004 at 11:25:57AM +0200, Alexander Larsson wrote:
> > On Fri, 2004-10-22 at 12:55 +0200, Harald Welte wrote:
> > > Hi!
> > > 
> > > First of all, let me say that I am much in favour of a conntrack helper
> > > than an ipt_recent-based solution.
> > > 
> > > > Hmm. I though by setting max_expected to 0 would allow me to get
> > > > multiple expected replies, but i could easily have misread the code. Is
> > > > there no way to expect multiple packets in reply to a single udp
> > > > package?
> > > 
> > > you just need to re-issue the expectation as soon as it is confirmed by
> > > the first packet (from the expectfn).  If I'm not mistaken, there are
> > > already helpers doing that, although I forgot which ones.
> > 
> > I've been experimenting a bit here. And it seems that it *does* accept
> > several packages after calling ip_conntrack_expect_related(), before the
> > timeout is passed (although expectfn is only called once). At least if
> > the packages are from the same ip.
> > 
> > I took a look at ip_conntrack_ftp.c, and it only calls
> > ip_conntrack_expect_related() from "help". Does this mean it only
> > accepts one related packet on the side-channel?. Actually, none of the
> > in-tree conntrack helpers use expectfn.
> 
> expectations are on a connection level, not on a per-packet level.
> However, broadcast packets don't have connections, since you send
> packets to .255 and receive them back from inidividual ip addresses.
> Since you don't know how many clients in the broadcast domain will
> reply, you need to re-create the expectation every time it is confirmed
> (via expectfn).

So, how exactly would you do this? I tried ip_conntrack_expect_alloc() a
new ip_conntrack_expect, set it up and called
	ip_conntrack_expect_related(exp, ct);

However, this just got me a kernel panic.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl@redhat.com    alla@lysator.liu.se 
He's a suicidal white trash boxer from the 'hood. She's an enchanted 
wisecracking detective living homeless in New York's sewers. They fight crime! 

Re: [PATCH] netbios broadcast connection tracking module

[Phil Oester]

On Tue, Oct 26, 2004 at 01:10:20PM +0200, Alexander Larsson wrote:
> Is having several domain controllers on the same subnet common? Sounds
> pretty unlikely to me.

It does happen...

Phil