| |
| |
| |
|
Comments:
<jhujhiti> is anyone using an ipv6 tunnel that runs over udp?
<LaF0rge> gug
<ndorotuan> hi
<xkr47> ho
<Hidden> gug
<Gandalf_> gug
<Octavian> gug
<ndorotuan> hi
<ndorotuan> can i use netfilter to limit bandwidth???
<Hidden> no, use tc for that
<ndorotuan> ok
<ndorotuan> Hidden -> u have reference for that??
<ndorotuan> limiting bandwidth on linux i mean?
<Gandalf_> http://lartc.org/
<ndorotuan> ok
<ndorotuan> thx all
<Hidden> Octavian: why?
<Octavian> see the tcpdump...
<Octavian> 12:37:39.784930 IP 10.0.11.20.1999 > 224.0.0.82.1999: UDP, length: 140
<Octavian> all seems well, but the client doesnt receive anything...
<Octavian> there is a testprogram from stevens' UNP book, which doenst work either
<Hidden> do you see the packets on the client with tcpdump?
<Octavian> the tcpdump _is_ from the client/slave
<Hidden> ah, ok
<Octavian> this is the actual join:
<Octavian> .0.11.20 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.82 to_in, 0 source(s)]
<Hidden> is this the join of the master?
<Octavian> yes
<Octavian> hmm... if i do 'tcpdump -n ether multicast' nothing is shown...
<Hidden> I have something like this, and it used to work: http://dawn.sch.bme.hu/~hidden/mc.txt
<Octavian> maybe the ethernet header is not multicast (01:00:5e prefix)
<Octavian> is there a tool to show joined multicast addresses for an eth? ethtool does not AFAIK
<Octavian> Hidden: I can see from the tcpdump that master-side properly has 01:00:54 prefix in the ethernet address...
<Octavian> so the client side is problematic somehow
<Hidden> do you see the client joining the group in tcpdump?
<Octavian> Hidden: I see the announcement
<LaF0rge> octavian: what kind of switches do you have in between?
<LaF0rge> octavian: try using a plain old non-manageable hub/switch for the beginning
<Hidden> indeed, we had some problem with a 3com switch
<Hidden> had to turn off some kind of multicast filtering
<LaF0rge> the more complex switches get, the more config options you need to know ;)
<Octavian> LaF0rge: this is between two UML instances
<Hidden> Octavian: and you see the packets sent by the master, just they don't get to the socket, right?
<Octavian> yes
<Octavian> I'll have a look at the 'uml_switch', but it's actually a hub i think
<Hidden> it can behave as both, but if you see the packet on the slave with tcpdump then probably not uml_switch is the problem
<LaF0rge> octavian: oh, uml.
<LaF0rge> octavian: what kind of networking do you use? are you sure anyone actually ever tried multicast there?
<LaF0rge> octavian: early on it was a hub, yes.
<LaF0rge> octavian: but I think what you're seeing is a uml specific problem
<Hidden> LaF0rge: I did use multicast with it
<Hidden> LaF0rge: although it was at least one year ago
<Octavian> LaF0rge: uml-switch -hub
<Octavian> LaF0rge: eth0=daemon,,unix,/var/run/uml-utilities/uml_switch.ctl
<LaF0rge> octavian: /rpoc/net/mcfilter shows you which ethernet multicast groups are programmed into the nic multicast filter
<LaF0rge> octavian: sorry, I haven't used uml in 2+ years
<Octavian> that's what i was searching for :)
<LaF0rge> octavian: /proc/net/dev_mcast ist also interesting
<Octavian> mcfilter is empty
<Octavian> this is dev_mcast...
<Octavian> 1 eth0 1 0 3333ff000a15
<Octavian> 1 eth0 1 0 333300000001
<Octavian> 1 eth0 1 0 01005e000001
<Octavian> 2 eth1 1 0 3333ff000b15
<Octavian> 2 eth1 1 0 333300000001
<Octavian> 2 eth1 1 0 01005e000001
<Octavian> yep, it's definitely UML related, mcastserver+emcast client works on my desktop but no in UML
<Hidden> uh, strange
<Hidden> use qemu instead of uml :)
<Hidden> or xen
<Octavian> I have a working qemu, I will try that :)
<LaF0rge> octavian: and file a bugreport / ml post to uml about their lack of multicast support
<Shoragan> is it normal that forwarding stops while reading /proc/net/ip_conntrack?
<Regit> Shoragan: yes use recent kernel
<Regit> >2.6.14 and conntrack tool
<Shoragan> okay
<Shoragan> is there a way to use that info for accounting?
<Shoragan> i currently use ULOG for accounting and the performance is not good enough :/
<Regit> Shoragan: ulog2 should improve this
<Shoragan> where can i get that?
<Regit> netfilter.org ?
<Shoragan> sorry...
<madclicker> ahoy, i have two DMZ zones one is a subnet from a ppp0 interface the other is a subnet of a T1 interface. The default gateway for this system is the ppp0 interface. The problem is, that when the T1 DMZ zone tries to access the ppp0 DMZ zone i get "martian source 206.248.xxx.yyy from 216.123.xxx.yyy, on dev ppp0"
<acidfoo> http://www.radio-canada.ca/radio/indicatifpresent/chroniques/71646.shtml
<acidfoo> jai retrouvé!
<acidfoo> damn
<acidfoo> wrong chans
<toxygen> hi
<toxygen> is there any other ruleset for p2p blocking (also through http) except ipp2p?
<dflow> toxygen: l7filter / iptablesp2p
Return to
#netfilter
or
Go to some related
logs:
compiz invalid file format
rug suse unable to create installation source
supermouse hack
ubuntu mousepad too sensitive
php Cannot use string offset as an array in fopen
jonttu_
difflib explanation
#perl
zcat fopen php
#osdev
|
|
