| |
| |
| |
|
Comments:
<0> gug
<1> gug :)
<0> Octavian: thanks for the patches
<0> Octavian: I'll commit them to SVN as soon as time permits
<0> Octavian: they're already in my private GNU Arch repo, but I was way too sleepy last night to commit them to SVN, too
<1> Hidden: thanks
<1> Hidden: I will send some other patches in the next couple of days
<0> Octavian: cool :)
<1> Hidden: there is another ct_sync bug which I am looking for
<1> Hidden: seems like a deadlock, currently only on SMP
<0> Octavian: I suspect there are a lot of bugs in the code, as basically you're the only one testing it
<1> _ct_sync_update_conntrack Unknown conntrack helper `#', ignoring.
<1> I suspect this to be another bug
<1> By chance it didnt crash at this point, the helper does not contain a valid value
<0> definitely looks like a bug
<1> _ct_sync_update_conntrack want to put conntrack in hash but is already there
<1> This may be another one
<0> sure
<2> hi there
<0> hello
<2> my problem is the following; I've dumped some traffic and now I need to rewrite it but with some (random) fragmentation. About now, I am able to fragment the traffic using tcpreplay + fragrouter: the problem is that the kernel defragments all packages and disturbs my work :-)
<2> any suggestion would be appreciated
<0> you mean ip_conntrack re***embles fragments?
<2> Hidden: probably
<0> then maybe you should try it without ip_conntrack
<2> Hidden: do you mean /proc/net/ipv4/ip_conntrack?
<2> Hidden: does it control defragmentation of packets?
<0> no, don't load the ip_conntrack module (if it's a module)
<2> Hidden: didn't load it
<2> Hidden: sure that's all about it?
<3> that should be it yes
<3> ip_conntrack defrags and then refrags (if neccessary) all packets
<4> does sending a packet to NOTRACK in the raw table prevent the defragmentation?
<3> yes
<3> then ip_conntrack won't touch the packet at all
<3> the problem can be to match the correct fragments with the iptables rule... :)
<0> chentschel: hello
<5> hidden: Hi!
<5> how's it going! ?
<0> still working... :(
<0> gonna' be a long night... (it's 20:09 here)
<5> :(
<5> sip implementation! ?
<0> no, we're preparing a beta release for zorp
<0> but hopefully (almost) all bugs related to the SIP module are in resolved state now
<5> :)
<5> cool
<0> so I'm hunting kernel bugs at the moment
<5> hidden: i'm thinking about deribate the ifindex from conntrack info .. :S
<5> hidden: any idea!?
<5> hidden: i;m logging flows info with ulogd2 and thinking that it woud be nice to have that info :)
<3> you can always find the outgoing interface if you perform a routelookup, but the incoming interface is worse
<3> asymmetric routing...
<5> hi gandalf!
<3> hi chentschel, how is it?
<5> fine thanks!
<5> u !?
<3> I'm about to start chasing two bugs in quagga, probably off-by-one bugs
<5> :).
<3> it doesn't install all ospf routes into kernel, and it doesn't notice all kernelroutes that exist when you start quagga
<3> there's one missing in both cases
<5> i thought about routelookup.. but i was thinking a way to know better the directions of the flows.
<3> I have a little over 500 routes in my ospf, maybe that's uncommon
<5> let's say if they go inside or outside the network.. ie.
<5> nice, and how does quagga performs!?. i've never used it.
<3> I can't say it's the most stable software I've ever used
<5> jejej
<3> it comes with a daemon called 'watchquagga'
<3> to make sure quagga is alive :)
<5> :P
<3> and they just fixed a problem with fragmented LSA's in ospf on linux which made quagga crash when you had a lot of routes
<5> i thought the level of development of that was a little bit _stopped_
<3> maybe you are thinking about zebra which quagga was forked from?
<3> but the quagga development doesn't seem be very fast
<5> well quagga also .. i thought
<5> yeap.. i mean slow..
<3> there's also xorp (not to be confused with zorp) but the ospf part is a bit buggy
<6> xorp? xorg?
<3> xorp.org
<5> i was thinking about the interfaces also becose maybe u can use the box as a bridge.
<5> and if you have one interface marked as outside and the other as inside, then u can say i want to see all flows from outside to inside.
<3> use the nfmark :)
<3> mark the connection and use that to determine the interface-pairs
<5> ahhh nice idea :)
<7> how do i turn this: iptables -A tcp_outbound -p TCP -s 0/0 --destination-port 5190 -j REJECT into a command that bans multiple ports as in port range 5000:65000
<3> --dport 5000:65000
<7> let me test that
<7> works:)
<3> great :)
<7> how about a reverse startegy... reject everything then accept ports?
<7> what would the --dport be for reject all?
<7> or no --dport, just -j reject, and then -dport xxx -j accept?
<4> yes, do it that way
<3> or ! --dport xxx -j reject
<3> there's several ways to do it
<3> the best way for the INPUT chain is to accept what you want and then drop/reject everything else
<3> works for most applications
<7> the thing is, it's for maquerading
<7> so if i put it in the input chain, will it work?
<7> dude
<7> it dont work
<7> #$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 21 -j ACCEPT
<7> #$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 25 -j ACCEPT
<7> #$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 110 -j ACCEPT
<7> #$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 80 -j ACCEPT
<7> #$IPT -A tcp_outbound -p TCP -s 0/0 --destination-port 445 -j ACCEPT
<7> $IPT -A tcp_outbound -p TCP -s 0/0 -j ACCEPT
<7> $IPT -A tcp_outbound -p TCP -s 0/0 -j DROP
<7> even with -j ACCEPT it didnt work?
<7> Gandalf_, ?
<7> $ipt = iptables
<8> here is not #iptables
<7> sorry mate
Return to
#netfilter
or
Go to some related
logs:
mysql get type Myisam innodb
#gentoo
#asm
#math
#perl
#kde
mythtv vmalloc
ppm2mpeg: command not found
#oe
gumbyno
|
|