[LARTC] How to get src and dest IP from packet
Dear All, I am trying to get src and dest IP from packet send from IP to TC via struct sk_buff *skb; In enqueue function in sch_myqueue, I get my IP like this struct iphdr* iph=skb-nh.iph; printk(KERN_ALERT %u::%u\n,iph-saddr,iph-daddr); but it turned out to be that I always get the same number and it's not an IP. The following are some of my result Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Please feel free to contribute any ideas you guys have got. Any sources should I consult? Thank you very much in advance for your help. Sincerely, Sipat Triukose -- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] How to get src and dest IP from packet
Dear All, I am trying to get src and dest IP from packet send from IP to TC via struct sk_buff *skb; In enqueue function in sch_myqueue, I get my IP like this struct iphdr* iph=skb-nh.iph; printk(KERN_ALERT %u::%u\n,iph-saddr,iph-daddr); but it turned out to be that I always get the same number and it's not an IP. The following are some of my result Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Mar 25 04:07:26 darth kernel: 1250891393::1194021458 Please feel free to contribute any ideas you guys have got. Any sources should I consult? Thank you very much in advance for your help. It is an IP, but not in a way you want it to be. Try: printk (KERN_INFO %u.%u.%u.%u - %u.%u.%u.%u\n, NIPQUAD (iph - saddr), NIPQUAD (iph - daddr)); Good luck! Sincerely, Sipat Triukose -- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux) BOIE [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Would the problem with queue lengths also exist if CONFIG_HZ=1000 in .config? (it certainly improves latency) I've configured rates from 10kbit/s...2Mbit/s on one machine, so changing the kernel code for low rates would probably effect the high rates too. Or, in other words, what is exactly the problem with an SFQ length of 128 for low rates? Cheers, Jeroen. On Thu, 25 Mar 2004 17:17:44 +1100 Andrew Hall [EMAIL PROTECTED] wrote: You need to recompile the kernel after altering this value in linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf qdisc, then the queue length may cause delay problems if it's too long (default is 128). Changing this to 32 for rates below 100kb/s, I have found to help things considerably. This change needs to be done in linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. - Original Message - From: Simon Byrnand [EMAIL PROTECTED] To: Jeroen Vriesman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 4:36 PM Subject: Re: [LARTC] HTB speed At 11:14 14/03/2004, Jeroen Vriesman wrote: Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on jiffies is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, Which pkt_sched.h are you refering to ? /usr/src/linux/include/linux/pkt_sched.h or /usr/src/linux/include/net/pkt_sched.h ? And after changing it what did you do ? Recompile the kernel ? Or recompile tc ? I too see the same problems with htb (very poor accuracy of speed, significantly too slow, also very jerky) while cbq is very accurate and smooth. (But lacks some features I need) Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Does anyone know a PPPoE Server for Bering ?
Does anyone know a PPPoE Server for Bering ? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] MRTG and IPP2P - Iptables
Hi all, I'm trying to use MRTG to monitor and make graphs of my P2P traffic. I'm using IPP2P 0.5c - Iptables 1.2.9 The IPP2P was configured like this: example three:01# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark 02# iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT 03# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --edk -j MARK --set-mark 1 04# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --dc -j MARK --set-mark 2 05# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --gnu -j MARK --set-mark 3 06# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --kazaa -j MARK --set-mark 4 07# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --apple -j MARK --set-mark 5 08# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --save-mark 09# iptables -t mangle -A POSTROUTING -m mark --mark 1 -j ACCEPT 10# iptables -t mangle -A POSTROUTING -m mark --mark 2 -j ACCEPT 11# iptables -t mangle -A POSTROUTING -m mark --mark 3 -j ACCEPT 12# iptables -t mangle -A POSTROUTING -m mark --mark 4 -j ACCEPT 13# iptables -t mangle -A POSTROUTING -m mark --mark 5 -j ACCEPT I have only added the --soul and --bit networks, with mark 6 and 7... And the command iptables -t mangle -L -n -v -x is working fine SHowing all my P2P traffic of each different network : iptables -t mangle -L -n -v -xChain PREROUTING (policy ACCEPT 31197 packets, 5559838 bytes) pkts bytes target prot opt in out source destination 33059 9516328 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 12001 5091047 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 MARK match !0x0 153 32656 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --edk MARK set 0x1 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --dc MARK set 0x2 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --gnu MARK set 0x3 57 24854 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --kazaa MARK set 0x4 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --apple MARK set 0x5 2 154 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --soul MARK set 0x6 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.5c --bit MARK set 0x7 20324 4360417 CONNMARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save Chain INPUT (policy ACCEPT 16997 packets, 3182031 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 26178 packets, 7467918 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 17072 packets, 3252442 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 31071 packets, 5596377 bytes) pkts bytes target prot opt in out source destination 11106 4799465 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x1 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x2 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x3 657 269207 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x4 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x5 436 60031 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x6 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x7 MRTG is already working fine, monitoring my eth0 andeth1 traffic. Alsomy CPU / Memory usage.. Can someonehelp me ? Best regards, LEANDRO TRAVAGLIA ---Outgoing mail is certified Virus Free.Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.639 / Virus Database: 408 - Release Date: 22/3/2004
RE: [LARTC] HTB speed
Thanks, Andrew, it's intresting... - (default is 128). Changing this to 32 for rates below 100kb/s, I - have found you mean that try change linux/net/sched/sch_sfq.c this: ? #define SFQ_DEPTH 128 #define SFQ_HASH_DIVISOR1024 for this. #define SFQ_DEPTH 32 #define SFQ_HASH_DIVISOR1024 I 've 2 questions about it 1) what is I use various rates (from 8k to 256k) 2) how I must proceed in Esfq ?? (in order to work with those htb classes) Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ] [ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE] Where: HASHTYPE := { classic | src | dst } Thankyou! andres - - You need to recompile the kernel after altering this value in - linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf - qdisc, then the queue length may cause delay problems if it's too long - (default is 128). Changing this to 32 for rates below 100kb/s, I - have found - to help things considerably. This change needs to be done in - linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. - - - Original Message - - From: Simon Byrnand [EMAIL PROTECTED] - To: Jeroen Vriesman [EMAIL PROTECTED]; [EMAIL PROTECTED] - Sent: Thursday, March 25, 2004 4:36 PM - Subject: Re: [LARTC] HTB speed - - - At 11:14 14/03/2004, Jeroen Vriesman wrote: - Hi, - - just putting the answer to my own question here, for those - who have the - same problem, and read the mailing list archive. - - The timing of the P4 based on jiffies is hopeless, it's - different for - every processor, and can be a wrong by a factor 3. - - If the tsc (time stamp counter) is used, the htb works fine, - the error in - speed is now only about 1 %. - - It's set by: - - in pkt_sched.h: - - #define PSCHED_CLOCK_SOURCE PSCHED_CPU - - that's all, I wonder why it's not default to do this, or maybe it's an - idea to make the packet scheduler detect the presence of tsc when the - module is loaded. - - Hi, - - Which pkt_sched.h are you refering to ? - /usr/src/linux/include/linux/pkt_sched.h or - /usr/src/linux/include/net/pkt_sched.h ? - - And after changing it what did you do ? Recompile the kernel ? - - Or recompile tc ? - - I too see the same problems with htb (very poor accuracy of speed, - significantly too slow, also very jerky) while cbq is very accurate and - smooth. (But lacks some features I need) - - Regards, - Simon - - ___ - LARTC mailing list / [EMAIL PROTECTED] - http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ - - ___ - LARTC mailing list / [EMAIL PROTECTED] - http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ - ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/