Andreas,
I found some time again to stare at the changes i made. Please
find attached the changes i made againsta latest iproute2.
The way i see it is we will be bitten again because xtables is still
a moving target. There are quiet a few functions which really
should be part of xtables but are c
On Wed, 2009-01-21 at 20:19 +0100, Jan Engelhardt wrote:
> On Wednesday 2009-01-21 20:11, jamal wrote:
> >If you are on debian - you should be able to install iproute-dev package
> >and be fine I think. I just dload the tree.
>
> No, this is iproute2 which is missing some stuff.
> Specifically, d
On Wednesday 2009-01-21 20:11, jamal wrote:
>> But it is not really my problem.
>
>It is ethically my problem, unfortunately. I wrote it and there are
>users out there.
Heh.
>> >Does it compile?
>>
>> Mostly. I cannot get iproute2 compiled because it cannot find
>> the definitions for struct
On Wed, 2009-01-21 at 19:44 +0100, Jan Engelhardt wrote:
> On Wednesday 2009-01-21 19:39, jamal wrote:
> >
[..]
> >I am afraid I cant get rid of iptables as is from ipt - it is needed
> >for older kernels.
>
> Well that is bad.
I should have said i need it to work with older iptables xtensions
m
On Wednesday 2009-01-21 19:39, jamal wrote:
>
>I agree. And I have a patch which resolves the current issue with
>some preliminary testing from Yawhen Kasarzhewski
>I still need to proof-read it and probably break it into three separate
>patches before submission.
>
>I am afraid I cant get rid of
On Wed, 2009-01-21 at 18:16 +0100, Jan Engelhardt wrote:
> On Saturday 2009-01-17 20:44, jamal wrote:
> >
> >As an example of something that would work and i could use as a base,
> >see attached against git tree - compile tested.
>
> It's a lot of code at once.
I think i wasnt clear in my messag
On Saturday 2009-01-17 20:44, jamal wrote:
>
>As an example of something that would work and i could use as a base,
>see attached against git tree - compile tested.
It's a lot of code at once.
I think it is nicer to proceed in single steps (and commits),
as that shows what other problems we must
Ok, Ive to a conclusion that the issue below is a bug on lenny.
I can work around the issue of internal.h in the short term - but
it will be harder to do without libxtables being present in lenny
(as it is on sid)
cheers,
jamal
On Sat, 2009-01-17 at 10:31 -0500, jamal wrote:
> Hi Andreas,
>
> O
On Sat, 2009-01-17 at 14:12 -0500, jamal wrote:
>
> I could move everything i need into xtables.h - i am sure there will
> be a few things still left in internal.h. Would this be fine by you?
>
As an example of something that would work and i could use as a base,
see attached against git tree -
On Sat, 2009-01-17 at 17:29 +0100, Jan Engelhardt wrote:
> But only when XTABLES_INTERNAL is defined, which only ought to be
> true for iptables itself, and not iproute.
ipt is analogous to iptables in requiring access to a lot of those
things already defined in internal.h; example struct afinfo,
On Saturday 2009-01-17 17:19, jamal wrote:
>On Sat, 2009-01-17 at 17:14 +0100, Jan Engelhardt wrote:
>
>> Yes, please send patches if you are bored :-)
>
>patches against current 1.4.2 would be fine?
Patches against the git master would be best.
--
To UNSUBSCRIBE, email to debian-bugs-dist-re
On Saturday 2009-01-17 17:24, jamal wrote:
>On Sat, 2009-01-17 at 17:15 +0100, Jan Engelhardt wrote:
>
>> internal files really should not be used - they are called internal
>> for a reason, and you can't really miss that with a name
>> like "internal.h", can you? :D
>>
>> Everything that libxtab
On Sat, 2009-01-17 at 17:14 +0100, Jan Engelhardt wrote:
> Yes, please send patches if you are bored :-)
patches against current 1.4.2 would be fine?
cheers,
jamal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
On Sat, 2009-01-17 at 17:15 +0100, Jan Engelhardt wrote:
> internal files really should not be used - they are called internal
> for a reason, and you can't really miss that with a name
> like "internal.h", can you? :D
>
> Everything that libxtables.so provides is in xtables.h. Or should be, in
On Saturday 2009-01-17 16:42, jamal wrote:
>> > xtables.h is already part of iptables-dev.
>> >
>> > $ dpkg -L iptables-dev | grep xtables.h
>> > /usr/include/xtables.h
>> >
>>
>> Ok, that i have. I did not have iptables-dev before.
>>
>
>Tried to compile - with iptables-dev header and failed.
On Saturday 2009-01-17 15:52, jamal wrote:
>
>Looking at xtables at the moment - thanks for your hard work.
>There are a few routines that are shared by apps like iptables/iptables6
>etc that are defined on one and then used by others (I think it works
>because they are all compiled at the same ti
On Sat, 2009-01-17 at 10:31 -0500, jamal wrote:
> > xtables.h is already part of iptables-dev.
> >
> > $ dpkg -L iptables-dev | grep xtables.h
> > /usr/include/xtables.h
> >
>
> Ok, that i have. I did not have iptables-dev before.
>
Tried to compile - with iptables-dev header and failed.
Nee
Hi Andreas,
On Sat, 2009-01-17 at 16:18 +0100, Andreas Henriksson wrote:
> Hello Jamal!
>
> On lör, 2009-01-17 at 09:41 -0500, jamal wrote:
> > Debian Lenny has a small issue with iptables:
> >
> > 1) libxtables.so is missing
> > My opinion: I think it should be put in package iptables instead o
Hello Jamal!
On lör, 2009-01-17 at 09:41 -0500, jamal wrote:
> Debian Lenny has a small issue with iptables:
>
> 1) libxtables.so is missing
> My opinion: I think it should be put in package iptables instead of
> iptables-dev since tc will load it at runtime.
Preferably, tc should use the versio
On Sat, 2009-01-17 at 15:33 +0100, Jan Engelhardt wrote:
> $ l *TTL* *TOS*
> -rw-r--r-- 1 jengelh users 3276 Dec 25 00:09 libipt_TTL.c
> -rw-r--r-- 1 jengelh users 592 Jan 9 03:12 libipt_TTL.man
> -rw-r--r-- 1 jengelh users 11680 Jan 8 13:36 libipt_TTL.oo
> -rwxr-xr-x 1 jengelh users 14050 Ja
Andreas,
Debian Lenny has a small issue with iptables:
1) libxtables.so is missing
My opinion: I think it should be put in package iptables instead of
iptables-dev since tc will load it at runtime.
2) The headers like xtables.h etc which are part of iptables 1.4.2
should be included (maybe as par
On Saturday 2009-01-17 15:27, jamal wrote:
>Jan/Patrick,
>
>Trying to fix YABFC on ipt:
>
>Looking at iptables 1.4.2, I see that some of the libipt_*.so are
>missing compared to iptables 1.4.1 (about 50%). Example:
>libipt_TTL.so is created in both versions but libipt_TOS.so is no longer
>there.
Jan/Patrick,
Trying to fix YABFC on ipt:
Looking at iptables 1.4.2, I see that some of the libipt_*.so are
missing compared to iptables 1.4.1 (about 50%). Example:
libipt_TTL.so is created in both versions but libipt_TOS.so is no longer
there. Is this a phase to eventually replace libipt_* with l
I have some time today so will look into this.
I just tried the idea below and it works. I realize this is not the most
practical solution - but if you want temporary solution with no changes
to iproute2, this would do it.
cheers,
jamal
On Fri, 2009-01-09 at 07:59 -0500, jamal wrote:
> Yevgen
Yevgeny,
There is one workaround which i havent tried but should work with Lenny.
1. Copy from debian-etch system /lib/iptables to somewhere.
2. Set IPTABLES_LIB_DIR to this somewhere
3. Run the tc command with ipt
The proper fix which is also backwards compatible needs some thinking
through.
ch
On Thursday 2009-01-08 01:14, jamal wrote:
>
>Thanks for the tip Jan.
>Of course that change would make life a little more interesting in
>avoiding breaking backward compat.
>Is xtables the way of the future and that interface wont change?;->
Interface might change at will, but at least properly
On Thu, 2009-01-08 at 00:48 +0100, Jan Engelhardt wrote:
> On Thursday 2009-01-08 00:41, jamal wrote:
> >Just about to download iptables 1.4.2.
Ok, I was able to reproduce what both Yevgeny and Andreas have using
lenny default tc and iptables 1.4.2
> > Help me understand what you mean and i wil
On Thursday 2009-01-08 00:41, jamal wrote:
>On Thu, 2009-01-08 at 00:24 +0100, Jan Engelhardt wrote:
>
>> tc's m_ipt is not updated to use libxtables.so yet.
>
>Just about to download iptables 1.4.2. Help me understand what you mean
>and i will fix m_ipt.
Make m_ipt.o,.so use appropriate cflags a
On Thu, 2009-01-08 at 00:24 +0100, Jan Engelhardt wrote:
> tc's m_ipt is not updated to use libxtables.so yet.
Just about to download iptables 1.4.2. Help me understand what you mean
and i will fix m_ipt.
cheers,
jamal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
w
On Wednesday 2009-01-07 17:14, Yevgeny Kosarzhevsky wrote:
> Well it isn't working though, I've tried that on both PCs I have, both running
> fresh lenny/sid, amd64 and i386 respectively:
>
> r...@warp:~# export IPTABLES_LIB_DIR=/lib/xtables
> r...@warp:~# tc filter add dev lo parent : protoc
Well it isn't working though, I've tried that on both PCs I have, both
running fresh lenny/sid, amd64 and i386 respectively:
r...@warp:~# export IPTABLES_LIB_DIR=/lib/xtables
r...@warp:~# tc filter add dev lo parent : protocol ip prio 10 u32
match u32 0 0 flowid 1:1 action ipt -j MARK --se
On Wed, 2009-01-07 at 05:06 +0100, Jan Engelhardt wrote:
> v1.4.2-rc1-10-g126c136
Thanks.
It doesnt work on Lenny I think because there is an older iptables.
On Lenny as well i dont see either IPTABLES_LIB_DIR or XTABLES_LIBDIR
being set.
--
dogo:~# iptables -V
IPTABLES_LIB_DIR is deprecated
i
On Wednesday 2009-01-07 04:54, jamal wrote:
>On Wed, 2009-01-07 at 02:06 +0100, Jan Engelhardt wrote:
>
>> This has been merged into iptables.
>
>nice. Which iptables version that would be?
v1.4.2-rc1-10-g126c136
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a sub
On Wednesday 2009-01-07 04:53, jamal wrote:
>
>Ok, that explains why IPTABLES_LIB_DIR is no longer seen on lenny.
>What is the replacement for it?
>In any case it doesnt matter for now - just export it and ipt will
>read it.
XTABLES_LIBDIR.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...
Ok, that explains why IPTABLES_LIB_DIR is no longer seen on lenny.
What is the replacement for it?
In any case it doesnt matter for now - just export it and ipt will
read it.
cheers,
jamal
On Wed, 2009-01-07 at 02:52 +0200, Yawhen Kasarzhewski wrote:
> I have latest iptables here:
>
> r...@warp
On Wed, 2009-01-07 at 02:06 +0100, Jan Engelhardt wrote:
> This has been merged into iptables.
nice. Which iptables version that would be?
cheers,
jamal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.d
On Wednesday 2009-01-07 01:03, jamal wrote:
>
>Which rings a bell. Jan Engelhardt kindly added an interface to access
>xtables back in Aug/July. Unfortunately the tree from which i derived my
>version seems un-accessible (possibly because it was a -dev at the time;
>if you want to try: git://dev.m
On Tue, 2009-01-06 at 19:03 -0500, jamal wrote:
> Ok, spent a little time on it; installed latest default iproute2 on
> debian etch:
Sorry - meant debian lenny. Flu affecting some of my brain cells.
cheers,
jamal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a s
I have latest iptables here:
r...@warp:~# iptables -V
IPTABLES_LIB_DIR is deprecated
iptables v1.4.2
r...@warp:~# dpkg -S libxt_MARK
iptables: /lib/xtables/libxt_MARK.so
Same latest version is introduced on netfilter.org
jamal wrote:
On Tue, 2009-01-06 at 09:19 -0500, jamal wrote:
Hi Andre
On Tue, 2009-01-06 at 09:19 -0500, jamal wrote:
> Hi Andreas,
>
> On Tue, 2009-01-06 at 12:48 +0100, Andreas Henriksson wrote:
> > PS. For the absolutely latest iproute version (as there has been no
> > additional commits in upstream git since the last "v2.6.27" release),
> > build from debians "
Hi Andreas,
On Tue, 2009-01-06 at 12:48 +0100, Andreas Henriksson wrote:
> The problem seems to be that both libxt_MARK.so and libipt_MARK.so are
> searched for in the /lib/iptables directory, while the libxt_* files are
> actually in /lib/xtables/ ... That's why libxt_MARK.so isn't found.
>
> I
On tis, 2009-01-06 at 02:50 +0200, Yevgeny Kosarzhevsky wrote:
> Package: iproute
> Version: 20080725-2
> Severity: important
>
> Seems iproute has been built against old version of iptables:
iproute uses runtime linking to find external modules, that's why these
problems are not caught at built-
Package: iproute
Version: 20080725-2
Severity: important
Seems iproute has been built against old version of iptables:
warp:~# tc filter add dev ppp0 parent : protocol ip prio 10 u32 \
> match u32 0 0 flowid 1:1 \
> action ipt -j MARK --set-mark 1 \
> action mirred egress redirect dev i
43 matches
Mail list logo
