| |
| |
| |
|
Comments:
<0> bbl
<1> ip6tables isn't behaving very well - if I use the policy DROP, it will drop all packets, even those explicitly allowed (in this case, all traffic over my LAN).
<1> Is this my fault, or ip6tables', you think?
<2> Robert: try logging to make sure you are matching the packets you think you are; ip6tables has always worked fine for me
<3> which tables are stateful? all, or all but RAW?
<1> danieldg: OK, will try.
<1> Are there any example ip6tables scripts floating around?
<2> Robert: if you want, I can send you one of my older ones; I'm now using IPv6 conntrack, so my current script wouldn't work
<1> I have been looking for connection tracking for IPv6... so if you've got a better solution, I'm all ears.
<2> 2.6.16 kernel
<2> you have to go enable some options in the kernel config
<1> Ah, thanks.
<1> It's in rc4, I ***ume?
<2> yes
<1> Thanks. :) And yes, if you could p*** along the scripts you use with connection tracking, that would be nice.
<2> Robert: I've got a whole lot of extra debugging rules in; http://daniel.6dns.org/info/iptables/ip6
<1> Thanks.
<2> actually, I could probably clean that up a bit...
<1> Ah, I probably should convert to those kinds of scripts... takes a little while to load on the old P200 using an iptables shell script.
<2> yeah, ip[6]tables-restore scripts are very useful - I actually have a script that generates that :)
<2> use 6to5
<2> 6to4 I mean
<1> With whom?
<2> nobody - 2002::/16 is open
<2> 2002:ipv4:inhex::/48 and use the 192.88.99.1 anycast relay
<1> I had no idea about that, actually. Thanks. :)
<2> Robert: I've got a much more cleaned-up version on there now; I removed all the hacks I had for not using conntrack
<1> Much cleaner, thanks.
<4> gug
<5> gug
<6> gug
<4> hello
<6> hi hidden
<7> hello
<7> I am trying to revive the RTSP conntrack/nat stuff
<7> and I have some troubles :)
<7> I've got it to compile on 2.6.15, it correctly see initials connection from client->server:554 and puts an expectation packet in the list of expected packets
<7> but it fails at sending the expected stream back to the client
<7> (which is UDP on client-chosen port)
<7> any idea of what I could have missed ? :)
<7> I would say that the UDP stream is not getting NAT-ed to the client, but I have no idea where to look at for that :)
<7> but the stream seems to be detected because the expected packet is removed from /proc/sys/net/ip_conntrack_expect when the stream starts
<7> source code at http://www.freenux.org/~mm/rtsp/ if you are interested :)
<8> Hi, we have some virtual hosts on virtual interfaces (xen) and i'm trying to stop them from sending out false ARP information. I am blocking IP traffic to and from ths vhosts that do not have the right IP address so the arp poisoning wont work but still i'd like them to not be able to fool the network at all . How do i do that ?
<9> LaF0rge hey
<10> Hm
<10> Hey anyone up?
<10> i'm looking for IPT_ACCEPT, or whatever
<11> ACCEPT is a built-in target, not an extension.
<10> of course
<10> say, I copy ipt_LOG.c to ipt_TLOG.c and want it to be TLOG a terminating target. Replace IPT_CONTINUE by ... what?
<10> IPT_RETURN?
<10> Hah
<10> One can return NF_ACCEPT.
<10> wooo.. it works!
<10> Hidden: The slow-internet problem I told you about a month ago is not tproxy related afaics.
<4> jengelh: ok, thanks for the info
<10> hm
<10> ping
<4> pong?
<10> yay
<10> there's a strange line in the iptables log
<10> IN=br0 OUT= MAC= SRC=172.16.60.2 DST=172.16.63.255 LEN=258 TOS=0x00 PREC=0x00 TTL=64 ID=23419 DF PROTO=UDP SPT=138 DPT=138
<4> "you've been h4xx0r3d" ;)
<10> nono, this is nmbd
<10> i just need to think of a way to accept it, because it's the culprit for the slow internet, I think
<4> why? this seems to be some windows browsing broadcast announcement
<10> Exactly.
<12> nmbd can't make internet slow, but your computer maybe thinks Your Internet is not working properly ;)
<10> The box sends it, and receives its own stuff. And because the destination address is not 60.2, it blocks the sender. Which is itself. Duh!
<12> lol
<4> :)
<10> now I just wonder why I don't see this at home where I have the exact same rule
<10> (almost)
<10> ah
<10> ah here
<10> must have to do with the br0
<10> This is really strange.
<10> said packet does not traverse the ebtables.
<10> yet it is said to come IN=br0
<12> :O
<10> i just added an ebtables rule to print everything
<10> there's nothing, but the same rule in iptables gives loads of info
<10> (-j LOG / --log)
<10> phew
<10> at least it gets through the OUTPUT chain of ebtables.
<10> don't answer but thanks for the help I think I can figure it out myself
<13> Is this the "ignore someone with a problem long enough and he might discover the solution on his own"?
<13> I vaguely recall that there is some option in the kernel that you may have to set, for iptables to see packets that come in on bridged interfaces.
<10> no it's all logical
<13> - if that had any relevance to your problem, that is.
<10> nmbd sends a packet on br0. ebtables-output sees it (once for ni0, once for ni1). ebtables-input does NOT see it, because there's no reply coming into the hardware. But iptables sees it, because ebtables saw 'aha - this is for me' and just send it back to localhost
<10> maybe i can see it in ebtables-forward, let's see
<10> nope, neither in ebtables-forward
<10> but i'm fine anyawy
<10> !@#%$^&*(
<10> yay
<14> w
<14> oops. wrong terminal;)
Return to
#netfilter
or
Go to some related
logs:
#gentoo
kdm getpwnam failed
debian pentium-m libc6-686
#css
#web
#kde
TOtorrentdeserialise. torrent is zero length
erudified
#oe
linux second loopback
|
|