ipt_connmark is broken

Bug #112611 reported by GSMD on 2007-05-05
Affects Status Importance Assigned to Milestone
linux-source-2.6.22 (Ubuntu)

Bug Description

Binary package hint: linux-server

# modprobe ipt_connmark
# lsmod | grep connmark
xt_connmark 3328 0
nf_conntrack 62728 1 xt_connmark
x_tables 16388 3 xt_connmark,xt_multiport,ip_tables
# iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables: No chain/target/match by that name

So connmark seems to be broken.

GSMD (gsmdib) wrote :

P.S. Feisty, server kernel

GSMD (gsmdib) wrote :

ok, in kernel config I found a line
I've changed it to
and recompiled the kernel. For now 'iptables: No chain/target/match by that name' is not thrown, though I don't know yet whether connmark actually works ;).

Kees Cook (kees) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Changed in linux-meta:
status: Unconfirmed → Confirmed
karlbowden (karlbowden) wrote :

Is it possible to get this enabled in Gutsy Gibbon and future revisions of the kernel?
I am using xt_CONNMARK for a site that serves to two ADSL connections and xt_CONNMARK is the simplest way to keep route correct for the two connections.

Chuck Short (zulcss) wrote :


Changed in linux-source-2.6.20:
importance: Undecided → Wishlist
GSMD (gsmdib) wrote :

So, is it going to get fixed for Gutsy?

Bill Michaelson (ubuntu-bill) wrote :

I sold a load-balancing scheme to a client. When I moved my scripts over from my testing (SuSE with kernel) to client production (Feisty, canned), this chomped at my posterior. Is -j CONNMARK considered unstable? There seems to be evidenced of topns of folks using it for quite a while now...

Changed in linux-source-2.6.22:
assignee: nobody → ubuntu-kernel-team
Jeremy Jackson (jerj) wrote :

I'd consider this a regression, since i'm using it for several years on Debian, then switching my routers to Ubuntu last month, I felt a knife in my back....not as welcoming as I had hoped.

saresca (saresca) wrote :

I've download last ubuntu kernel 2.6.20-29, modify the config and add this modules:
recompile the kernel and now is working.

Should be added in the next kernel release.

GSMD (gsmdib) wrote :

Yes, that's a straightforward workaround.
Recompiling the kernel every time in order to enable a feature that should have been enabled by default sucks bad though.
Things remain the same in the latest Gutsy kernel.

karlbowden (karlbowden) wrote :

So how do we go about getting this fixed then?
I can confirm that the above change mentioned by saresca is all that I need to do before compiling kernel modules to get the module I need. I do not know where to start in making a patch for the kernel package though.
The module is about 4.0k after compiling and striping and I know that I have seen stability issues in the past for this module, but that was a long time ago (couple of years). So I dont think size or stability are the issue. It's should now just be a matter of getting someone to accept a patch for the kernel.
I do sorely miss this module from Debian.

tuxinvader (tuxinvader) wrote :

Still broken in the latest ubuntu kernel, release 2.6.22-11-generic.

As the Beta freeze is now on, and this bug is marked as wishlist, I guess this is not going to be fixed in Gutsy?

Looks like I'll have to use Debian Etch for any server deployments that require any clever firewalling or advanced routing rules for now.

Please enable *all* of the NetFilter modules in your kernel and iptables packages in future.

Ubuntu is currently unusable in advanced-routing deployments :(

GSMD (gsmdib) wrote :

Yeah, the attitude of Ubuntu maintainers plain sucks for this matter.
Having connmark enabled by default can't brake anything. I don't mind recompiling the kernel by hand, but this would break automatic kernel security updates and add more headache. Just don't get it.

Tim Gardner (timg-tpi) on 2007-09-21
Changed in linux-source-2.6.22:
assignee: ubuntu-kernel-team → timg-tpi
status: Confirmed → In Progress

Speaking of advanced routers, I'm setting up Quagga on Debian, and
looking to do the same on 2 Ubuntu routers. When configuring BGP
sessions to 1 upstream provider's Blackhole route server, Linux > is required for TCP_MD5 passwords.

What's interesting, is the debate about the kernel side, and it's
bleeding edge status... and how I find it's in Ubuntu's kernel, Feisty
and Gutsy, but *not* in Debian etch or testing.

How would a conservative Ubuntu kernel have such a bleeding edge
feature, that's pretty deep in the network stack, but not something
that's been in Debian for *years*, which is an isolated module?


On Fri, 2007-09-21 at 13:16 +0000, GSMD wrote:
> Yeah, the attitude of Ubuntu maintainers plain sucks for this matter.
> Having connmark enabled by default can't brake anything. I don't mind recompiling the kernel by hand, but this would break automatic kernel security updates and add more headache. Just don't get it.
Jeremy Jackson
Coplanar Networks

Tim Gardner (timg-tpi) on 2007-09-22
Changed in linux-source-2.6.22:
assignee: timg-tpi → nobody
status: In Progress → Fix Released
karlbowden (karlbowden) wrote :

Yip, I found Ubuntu's support for questionably bleeding edge software supprisingly good too. Just look at compiz and usplash when they first came to light.

I'd just put this one down to a bug.

Good to see it fixed in the current Gutsy kernel now.

Cheers guys.

Jeremy Jackson (jerj) wrote :

I just found that xt_NOTRACK is also missing, as reported in Bug# 125512, I just thought I'd mention that here since they're basically the same issue, and maybe I can help expedite it's inclusion in Gutsy, same as this bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers