| |
| |
| |
|
Page: 1 2
Comments:
<0> what's the outgoing interface for packets that originate from a process on my machine?
<0> i was ***uminh it would be lo, but.. i don't think so
<1> it's whatever interface they are going out
<0> er..
<0> sorry
<0> i mean the source interface..
<0> like if i want to restrict access to services running on 127.0.0.1 to local stuff
<0> should the source be lo/127.0.0.1 ?
<1> that's done already
<0> and the dst will also be lo/127.0.0.1?
<0> done already?
<1> the incoming interface (filtering in INPUT) will be lo
<1> well, if an application is bound to 127.0.0.1:port, you can't get to it from the internet
<0> what if someone on my subnet spoofs packets or something?
<1> if you want to, you can only allow the packets if they come in on lo
<1> anyway, they can't spoof a TCP connection
<0> so it's a waste eh
<2> I'm having some trouble with the new stateful ipv6 stuff... i have a rule to match everything that's NEW, RELATED,ESTALISHED, but it's only matching the occasional SYN/ACK
<1> what kernel? do you have nf_conntrack_ipv6 loaded?
<2> 2.6.16.2 and.. let me check
<2> CONFIG_NF_CONNTRACK_IPV6=y
<1> ah, no modules...
<2> straight from /proc/config.gz
<2> nope =p
<1> are they all INVALID?
<2> how would i tell? other than inserting a log target?
<2> i have two packets in a row. one matched the stateful rule, coming from outside to inside, port 80 to something. SYN/ACK. the one after it is the same in those regards, but doesn't match
<1> counters - just add a rule for INVALID with any/no target and look at ip6tables -vL
<2> yep, invalid
<1> how is your network setup? packets coming in a tunnel interface?
<2> packets come in a udp tunnel on brahma. they get forwarded to maya, where these rules are.
<2> brahma doesn't block anything
<2> hexago -> brahma -> maya -> network. and the default route for the network is maya. and the default route for maya is brahma. and so forth
<1> you could try setting /proc/sys/net/netfilter/nf_conntrack_log_invalid to 255 to see why the packets are invalid, but I'm out of ideas
<2> what exactly does that do?
<1> logs the invalid packets to the kernel log
<2> humm, it's not logging anything
<2> $ sysctl net.netfilter.nf_conntrack_log_invalid
<2> net.netfilter.nf_conntrack_log_invalid = 255
<2> perhaps it's worth noting that the forwarding is all taking place on one interface
<1> jhujhiti: looks like you need CONFIG_SYSCTL set to have the logging work; is it?
<2> yes
<2> (should be appearing in dmesg, right?)
<1> yes
<2> grr
<3> gug
<4> gug
<4> Hidden: on friday I started writing a ctsyncd, using ctnetlink... just for testing purposes
<5> gug
<5> Octavian: yay, how far have you come?
<4> Gandalf: I now a working master-side and did some performance tests yesterday...
<4> Gandalf: I did the test on an 2 CPU system with HT enabled
<4> Gandalf: I tested with as many HTTP connections the performance setup can handle, load was about 20-30 % of the system (top)
<4> Gandalf: as expected the load is higher of course, but still satisfactory
<5> Octavian: ok
<4> Gandalf: and there is still room for performance improvements
<5> Octavian: is there some kernel side modifications needed on at least the slave side for it to work like the old ctsync? I mean, new entries added shouldn't timeout and all that...
<4> Gandalf: e. g. I use iovecs just on the writing side to send the CT events via multicast
<3> Gandalf_: AFAIK current ctnetlink code does not support these "features"
<4> Gandalf: as I said, I only have the master side currently
<3> unfortunately they are potentially dangerous
<4> Hidden: why?
<5> Hidden: that's why I said kernel side modifications :)
<3> ie. you can easily generate entries which will never disappear
<3> for example, imagine that the daemon dies without proper cleanup (SIGSEGV, for example)
<3> of course this could be handled somehow
<5> one solution would be to ***ign the daemon an identifier that it uses when it creates the entries
<3> exactly, that's what I was thinking about
<5> and at startup it cleans up all the entries it finds that has this identification (and are in "slave" state)
<4> Hidden: so the problem is a dying master-side ctsyncd?
<3> no, mainly the client side
<4> Gandalf: yes, that seems solveable
<3> the master side does not have stopped conntrack entries without running timers
<4> oko
<3> another thing to think about is how you detect that the nodes are out-of-sync
<3> I really dislike the "protocol" used by ct_sync
<3> the recovery code in there is basically unusable
<3> and we shouldn't reinvent the weel anyway
<4> Hidden: i dislike the cts_buffs, they seem to me overly complicated
<3> Octavian: yes, it's hard to follow
<3> Octavian: but you don't need those for userspace anyway
<4> Hidden: why do the CTs on slave side dont have timers?
<4> or more exactly: why dont they timeout?
<4> Hidden: do we need the slave-side "marking" really? wouldnt it be an option just do delete all conntracks on restart and start an init-sync right away?
<5> the question is if we want to support the case where one machine is slave for two diffrent masters (don't know why one would want that but...)
<5> why not just skip the master-slave support and go directly for master-master?
<3> how do you load-balance traffic between masters?
<5> that's another matter :)
<4> no, not yet
<4> let's go in small steps please :)
<5> heh
<4> Gandalf: I currently do not know how costly it is for userspace to find out whether an conntrack exists or net
<5> Octavian: fairly cheap
<4> anyway, I will finish my work on this prototype and will post it on the ML
<5> Octavian: but there might be room for improvement there as well, I believe the old ctnetlink was faster than the current code but I don't have any data to back that up yet
<5> Octavian: I can perform 100k lookups/s on my laptop
<4> Gandalf: think so too, since i saw during the performance tests that ~60% of the time was spent in softirq context
<5> yes
<5> I remember that with the old ctnetlink code I could perform 100k lookups/s on a pIII 600
<5> and 200k/s on a dual pIII 600
<3> do you still have that machine?
<5> no :(
<5> it was a machine I borrowed
<5> but I have a dual pII 300 :)
<5> I'll see if I can get that machine running and test it, the biggest problem is probably hunting down the old patches :)
<5> I think I have them here somewhere
<3> :)
<5> but it will have to wait a while
<3> I guess you've a couple of more important things on your todo list :)
<5> Hidden: my todo list has been out of control for past 2 years :)
<5> Hidden: and I've moved twice in the past year so my "server room" is a complete mess
<6> morning all. Have any of you guys seen Chrisitian Hentschel around lately?
<5> I don't think he's been around for a week or two (possibly longer)
<6> last time he shows up in my logs in february 8... i almost always here...
<6> last time i spoke to him he would rewrite the sip helper, but that is quite some time ago now
<5> ok, maybe it was that long ago, my time perception is way off these days
<6> :)
<5> (and that's usually a bad sign...)
<6> yeah
<6> it could be that you guy knew he is making a trip around the world or something :)
<6> s/guy/guys
<7> maybe this channel needs an infobot :)
<8> Is the pserver for netfilter broken, or did someone simply change the public p***word
<5> it was changed to subversion
<8> ah
<8> So who didn't bother to update the howto ?
<5> someone
<5> look at http://netfilter.org/downloads.html
<8> bleah
<5> there are snapshots on the ftpserver
<5> ftp://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/
<8> go ipt_time
<9> hrm
<9> Gandalf_: remember the problem i was having with connecting to a certain host? another one does it, but a different message:
<9> Apr 11 08:09:04 lothlorien kernel: ip_ct_tcp: SEQ is under the lower bound (already ACKed data retr
<9> i get like 8 of those when the transfer fails
<9> and ssh portforwarding doesn't work for some reason, like it does for the other host :-(
<9> ip_ct_tcp: SEQ is under the lower bound (already ACKed data retransmitted) IN= OUT= SRC=24.59.44.17
<9> there, the full msg
<5> hmm
<9> i'm guessing the server uses an alt port for the file transfer, but i don't know what that is atm
<9> stupid program :-(
<9> i'm still on 13.3, but i downloaded 16.2
<5> please obtain tcpdump traces of the sessions that fail like this
<9> what's the best way?
<10> netfilter now uses svn
<10> oops
<5> tcpdump -nw /tmp/trace.pcap host 24.59.44.17
<5> something like that, and then reproduce the problem
<5> maybe add -i eth0 as well...
Return to
#netfilter
or
Go to some related
logs:
teenyvids night
kubuntu keyboard iso-8859-15
#fedora
#fedora
#lisp
spinlock lockup bad magic fedora
ubuntu fschk not found
#qemu
gtkpod *ctx NULL
asoundconf usage
|
|