[LARTC] How to get src and dest IP from packet

2004-03-25 Thread Sipat Triukose
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

2004-03-25 Thread Catalin BOIE
 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

2004-03-25 Thread Jeroen Vriesman

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 ?

2004-03-25 Thread Miguel
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

2004-03-25 Thread Leandro Andrade Travaglia



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

2004-03-25 Thread ThE LinuX_KiD
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/