| |
| |
| |
|
Comments:
<0> Hmmm...
<0> + /sbin/iptables -A FORWARD -o eth1 -d 10.255.1.2 -s 80.239.42.80 -m state --state NEW -j ACCEPT
<0> + /sbin/iptables -A FORWARD -p tcp -o eth1 -d 10.255.1.45 -s 80.239.42.90 --dport 22 -m state --state NEW -j ACCEPT
<0> iptables: No chain/target/match by that name
<0> I wonder why the first one works, but not the other..
<1> does 'iptables -A FORWARD -p tcp --dport 22' work?
<0> Nope. Seems to fail on the --dport
<1> try adding -m tcp in there too
<0> "iptables -A FORWARD -p tcp" works
<1> what kernel version?
<0> 2.6.16, worked fine on 2.6.14
<1> try modprobe xt_tcpudp
<0> Ah, that fixed it
<0> Didn't realise xtables changed things that much
<1> it's supposed to autoload from the old module names, but apparently that didn't work
<0> kmod is disabled here ;-)
<0> So no autoloading unless udev/hotplug kicks in.
<2> The iptables binary itself uses modprobe to load stuff. It was a command line option to use something other than the default modprobe binary.
<2> "has a", not "was a"
<3> igmp multicast... Is there something nutso about them that even with defualt DROP policies they still somehow get through iptables? The only way Im seeing to stop them is an explicit block.
<3> through meaning I see them come in on the internal interface and then go out on the external obviously traversing NAT and I would presume the FORWARD chain. INPUT, OUTPUT and FORWARD are all default DROP and there are no rules allowing the multicast ips.
<3> I obviously dont understand some at last underlying aspect here but it seems nuts to me.
<4> danieldg: I think I've found the issue with the mark not being set when you create an entry with 'conntrack'
<4> danieldg: are you using ip_conntrack or nf_conntrack? nf_conntrack right?
<4> yes now it works, but I had an oops when loading the module, doubt it has anything to do with my minor changes
<4> the oops only occurs when you unload the old nf_conntrack_netlink and loads the corrected one, not if you load the corrected one directly after boot
<4> so there's some problem when shifting between the two
<4> danieldg: your name is Daniel De Graaf?
<4> I'll ***ume it is, fits with your nick :)
<4> ok, fix for the oops I had during rmmod of the old module and insmod of the new one should be fixed now
<4> ehm, thinking about two things to write can cause weird sentences
<4> the bug is fixed and the fix is on it's way :)
<5> gug
<4> gug
<5> hi gandalf
<4> hi harald
<4> ah
<4> the motorola phones
<5> actually you can download some code (kernel, ...) into ram using the bootloader and then executing it without even having to flash it. that should speed up kernel development quite a bit
<4> nice
<4> almost like loading it from a tftpserver like pxe or sun netboot
<5> yup
<4> I played with nfnetlink today, first time in a long time that I've touched it
<5> i see
<5> want to port your ident?
<4> sure, should be easy enough. I was actually thinking about it today
<4> now we just need ipv4 NAT for nf_conntrack
<5> i have some initial patches for that somewhere, though utterly incomplete
<4> but I settled for nf_conntrack_netlink not hanging my box :)
<5> ?
<4> it wasn't unregistering the expectation notifier correctly
<5> oh
<4> so rmmod ; insmod of it would hang the machine on the next expectation created
<5> oops
<4> I've sent patches to patrick and netfilter-devel
<4> simple one-linerts
<4> -t
<4> and if you rmmod and then insmod a modified version it oopsed
<4> works fine now
<5> ok
<1> Gandalf_: thanks; I was asleep.
<4> hmm
<4> LaF0rge: is there any way to get a conntrack with libnetfilter_conntrack without using a callback function?
<4> a callback function is not what you want if you have a tuple and you want to get the corresponding conntrack entry only to get some value from it and then continue
<5> gandalf: don't think so. the problem is that nfnetlink is inherently asynchronous and stuff might overlap, kernel might answer unordered, etc.
<5> that's why we did that callback architecture
<6> LaF0rge: Did you have a look at the ct_sync patches I send on nf-devel some weeks ago?
<4> yes I know, but for a simple get there's only two possible returnvalues, either a conntrack or an error, I remember I added such a function to the old ctnetlink library and used that in oidentd, it has been working great
<6> Is there any chance of the linux-2.6 stuff to get "maintained" again or would it be wise to switch to -multigroup and update the patches therefor?
<5> barbarossa: I'm still not finished with reading through the backlog since I went on holidays on feb 27
<6> ;-)
<6> Please give me a short comment when you've read it.
<5> ok
<7> my distro keeps a hunk of old (2.4.x) kernel source around for building the iptables package against. bugs caused by this are squished as they're reported, but I can't seem to make a coherent case for building the package against the source of the distro kernel, as other distros do.
<7> is there a good argument for doing that?
<5> iptables userspace selectively compiles features based on the kernel source you give it
<5> if you compile it against a 2.4.x kernel, a number of extensions for new matches/targets will probably not be built
<4> ok, now I feel stupid, I was wondering why my test-program didn't work... you have to be root to use nfnetlink :)
<4> hmm, this doesn't seem nearly as fast as the old ctnetlink/libctnetlink with ip_conntrack
<4> I remember I could perform 100.000 lookups/s on a pIII 600MHz
<4> this gives me 10-15k lookups/s
<4> on a 1.6GHz PM
<4> ok, it helps if I loop the correct number of times...
<4> so it's not that much slower it seems :)
<5> i see
<5> that's better
<4> yes
<4> but it still feels slower than the old code, but I don't have any data to back that up
<4> it's spending 2/3 of the cpu in kernel
<4> __nfa_fill uses 12% cpu
<4> glibc uses 14% :)
<4> I hope the old stall-on-smp bug is gone these days (I never managed to find out what it was), need to get 2.6.16 onto an SMP machine here...
<7> LaF0rge: so iptables doesn't actually "build against" the kernel source, as in use its code? just looks for features available in the kernel to decide what to build?
<8> trappist: I guess, it's just using the same header files as the kernel source that include all the constant definitions needed in order to access the kernel functions
<7> florz: I ***ume that's pretty stable stuff, so there shouldn't be a real problem in building iptables for a 2.6.x distro against 2.4.x source
<8> trappist: me neither - but the constants needed in order to access functions only present in 2.6 won't be in the 2.4 header files, which is why they can't be compiled in
<7> florz: makes sense. all the bugs reported so far have been fixed, but I guess at some point we'll have to at least put 2.6 source in the iptables source package, but I guess it's not all that important to build against the source of the distributed kernel
<8> As I understand it, you only would be missing support for things that are not present in the kernel source you are building against
<7> right. my concern was that if we use an old kernel tree, stuff would get compiled and not actually work if the kernel code changed too much. but that doesn't seem to be the case.
<8> And those being left out automatically thus is just a compatibility device to ensure that you can build it against older versions at all
<8> I'd expect that for stuff that's still beta in the version you compile against, but not for anything declared stable. I don't know the policy of the netfilter project on this, but that's at least the way it makes sense and it seems to fit my obvervations so far ;-)
<7> thanks!
Return to
#netfilter
or
Go to some related
logs:
phpadmyn fedora
#perl
nagios megaraid_mbox
#debian
yum install ipw2100 no match
#python
when do you use frosh
gdm.conf-custom restore ubuntu
perl regexp XML
dd: reading `/dev/hdd': Input/output error ubuntu
|
|