Re: [LARTC] HTB stalling

2005-04-23 Thread Krystian Antoni
so i checked using your way: HTB init, kernel part version 3.17.
On 4/23/05, gypsy [EMAIL PROTECTED] wrote:
Krystian Antoni wrote: How to check version of HTB?? I have standart one which came with kernel 2.6.11.7, my tc says I have TC HTB version 3.3. Is this my HTB version? :-)
No, it isn't.3.3 is the TC version.The only ways I know to find out the HTB version are:1) if it loads as a module, it will record in your logs its version.2) read the source.'grep HTB_VER /usr/src/linux/net/sched/sch_htb.c'
should return something like0x30011That 11 at the end is hex, so in decimal it = 17, making the exampleabove 3.17 Im not using FC3 kernel but a vanilla one so there is no much beta in
 it :) besides I cut most of the stuff out just for experimentation and still no luck :)But it is still a 2.6 kernel, not a 2.4 kernel?In 2.4.x,linux/include/net/pkt_sched.h specifies the timer.(I can't help you
with 2.6.Until it appears as standard in Slackware current, it is notstable enough for my production servers.).--gypsy On 4/22/05, gypsy [EMAIL PROTECTED]
 wrote: hareram wrote: Hi all iam also facing the same problem what Mr Antoni have even i have done many kind of experment, but i could not
resolve is this bug in FC3, but when i does the FC1 its working fine I found difference from FC1 to FC3 is FC1 iptables 
1.2.8 HTB 3.12 FC3 iptable 1.2.11 htb 3.16 can some experts coment on this hareAlthough this stalling issue may still be a timer problem
rather thanHTB, there are bugs in versions of HTB  3.17 so you MUSTpatch thekernel so HTB is at least 3.17.I don't know aboutiptables.
Do remember that FC3 contains much BETA; you really shouldbe usingsomething less bleeding edge for a server.--gypsy___
LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
 -- Miego Dnia Krystian Antoni-- Miego DniaKrystian Antoni
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] Suspicious Attachment

2005-04-23 Thread Alexander Samad
On Sat, Apr 23, 2005 at 01:58:00AM +0200, Arjen Meek wrote:
 On Tue, Apr 19, 2005 at 10:15:19AM +0200, Michael Renzmann wrote:
  I agree, but I also see no reason to have this discussion arising over 
  and over again. Local filtering should do the trick until that moron 
  understands that it is a bad idea to automatic ansers to the spoofed 
  sender of a virus mail.
 
 My mailserver runs qmail (actually mailfront for SMTP) and rejects any
 message that ClamAV thinks to contain a virus with a 554 Message
 refused, which in my opinion is the correct SMTP reply for any
 message I don't want on my server (silently dropping the mail seems
 like a risky thing to do). No bounce message is sent by my server.
 
 However, I recieved this from the mailinglist manager:
  Your membership in the mailing list LARTC has been disabled due to
  excessive bounces The last bounce received from you was dated
  21-Apr-2005.  You will not get any more messages from this list until
  you re-enable your membership.  You will receive 3 more reminders like
  this before your membership in the list is deleted.
 
 Looking at my logs it must be outpost.ds9a.nl actually generating the
 bounce message.
 
 If 554 is not the right reply for such a message, what would be a better
 way to indicate that the message is concidered utacceptable by my
 server?
 If it is the best reply, what should I do to avoid being kicked off the
 list because my mail server doesn't say that's fine with me when it
 gets sent a virus message?

I am having the same problem but using debian + exim  clamav

 
 Sorry for replying to an offtopic thread, but since the virus problem
 is apparently known here I figured someone might be able to tell me the
 correct way to handle such situations.
 
 Personally, I think it would be a very good thing for any system that
 distributes e-mail, especially one that multiplies it as well like a
 mailing list does, to refuse distributing content that is clearly of a
 malicious nature, to avoid increasing the size of the problem.
 
 regards,
 Arjen
 ___
 LARTC mailing list
 LARTC@mailman.ds9a.nl
 http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
 


signature.asc
Description: Digital signature
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[LARTC] a good real time network speed meter

2005-04-23 Thread Rani Ahmed
hi all.
i know that most of u are unix users, and some hate to speak of windows 
here. but i found a good realtime speed meter.
this the link.
http://www.google.com/url?sa=Ustart=1q=http://www.trogdor-aln.com/Utilities/index.phpe=10129
thanks.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[LARTC] Spill over

2005-04-23 Thread Kenneth Kalmer
List

I need some help, advice or just a starting point on the following situation:

Link A - 64kbps leased line
Link B - 512kbps ADSL line

Is it possible to have Link A saturated constantly and have the excess
traffic spill over onto Link B? I know it's possible to have packets
sent down links in a round-robin fashion and I've read in the howto on
load sharing over multiple interfaces
(http://lartc.org/howto/lartc.loadshare.html), but I do not have
control over the termination of the link at the ISP's (two different
one as well). Also note that splitting different protocols over each of
these links are not possible in our case.

Reason being, Link A is a more reliable and more expensive link, so I
need to over-use it's capacity if it we're, and use the cheaper ADSL
(link B) offering to keep al services running when the leased line (A)
is saturated.

Any tips, suggestions and comments would be welcomed.

Regards-- Kenneth Kalmer[EMAIL PROTECTED]http://opensourcery.blogspot.com
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] Spill over

2005-04-23 Thread Taylor Grant
List
I need some help, advice or just a starting point on the following 
situation:

Link A - 64kbps leased line
Link B - 512kbps ADSL line
Is it possible to have Link A saturated constantly and have the excess 
traffic spill over onto Link B? I know it's possible to have packets 
sent down links in a round-robin fashion and I've read in the howto on 
load sharing over multiple interfaces 
(http://lartc.org/howto/lartc.loadshare.html), but I do not have control 
over the termination of the link at the ISP's (two different one as 
well). Also note that splitting different protocols over each of these 
links are not possible in our case.

Reason being, Link A is a more reliable and more expensive link, so I 
need to over-use it's capacity if it we're, and use the cheaper ADSL 
(link B) offering to keep al services running when the leased line (A) 
is saturated.

Any tips, suggestions and comments would be welcomed.
Regards
Off hand the thing that comes to mind would be to use an IPTables rule to 
estimate the rate of flow (I'm not sure what match this is (limit?) but I do 
think there is one.) and reset the route or mark traffic and have the routing 
table reroute traffic that is marked.  Keep in mind that this will only roughly 
saturate your 64 kbps link on your outbound traffic.  It will do nothing to 
control the % utilization on the traffic that comes back in to you.
Can I ask why you are wanting to saturate tech 64 kbps leased line?  Are you 
trying to encourage management that you need a faster leased line by going to 
them with graphs stating that the ADSL they purchased did not really solve the 
problem like they were wanting it to?  ;)
Another not so nice trick that you could do is just send bogus traffic, via 
packet gen, out the 64k at a lower priority than the rest of your legitimate 
traffic thus insurring that the 64 kbps line is full all the time even if you 
don't have that much legitimate traffic on it.  Yes I should probably be 
thumped or at least pelted with Nerf Darts for this idea, but it is an answer 
if you are just trying to saturate the 64 kbps line.  (Time to run and hide as 
I hear the Nerf guns being pumped up!)

Grant. . . .
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] Spill over

2005-04-23 Thread Chris Bennett



You can't split a particular IP connection 
between two links, but can instead only determine which link a 
particularconnection will occur on. Given this, it sounds like you 
want to have some way to detect that Link A is already saturated and then send 
all further connections to Link B until Link A is no longer 
saturated.

Maybe someone can tell you how to do that 
if that's really what you want to do (others here know far more about this than 
me), but my guess is you really don't want to do that.With the 
hugebandwidth disparity between the two links,route cacheing, and 
the inabilityknow how much bandwidth any particular conneciton will 
consume, I think you'd end up with a giant mess... those people with connections 
unlucky enough to end up on Link A would probably be very unhappy people 
indeed.

Generally speaking I think it would make 
more sense to put all traffic over Link B, and then use Link A only for 
emergencies. Maybe route the most critical traffic over Link A if you 
really want to feel like its being utilized as something other than a pure 
backup, but personally I wouldn't even do that.

Just because Link A is more reliable and 
more expensive doesn't mean it makes sense to use it as your primary 
conduit. With Link B havingeight times the bandwidth, it 
seemsthe obvious choice as the primary. Use it, and keep the users 
happy most of the time (instead of making them miserable mostof the 
time). On the rare ocassions it goes down, use bandwidth shaping to make 
sure the highest priority traffic gets access to Link A first.

In all the time I've used DSL, I've 
hadsevereoutagestwice for reasons other than standard 
maintenance. In both cases (in two separate locations), the cause was the 
ILEC phone company mistakingly dropping the wire pair while doing other work 
(freakin took over a week in each case to get my connectivity back!!). 
This sort of thing could just as easily happen with a leased line though, so I'm 
not really sure I buy that the leased line is really more reliable than DSL line 
from a high quality ISP. Although maybe a particularSLA makes it so 
in some legal sense since you can then sue someone. Personally, if your 
leased line really costs more than the DSL, I'd get rid of it and get a 2nd DSL 
line from another provider and use that as your backup instead.

Anyway, I guess my main point is that the 
high cost of your leased line might be clouding your thinking on this. I 
wouldn't let the comparitive costbe your guiding light here. Go with 
what makes sense from a technology perspective, and don't guilt yourself into 
trying to get full utilization out of the slow link just because it costs 
more.


  - Original Message - 
  From: 
  Kenneth Kalmer 
  To: lartc 
  Sent: Saturday, April 23, 2005 4:34 
  PM
  Subject: [LARTC] Spill over
  ListI need some help, advice or just a starting point 
  on the following situation:Link A - 64kbps leased lineLink B - 
  512kbps ADSL lineIs it possible to have Link A saturated constantly 
  and have the excess traffic "spill over" onto Link B? I know it's possible to 
  have packets sent down links in a round-robin fashion and I've read in the 
  howto on load sharing over multiple interfaces (http://lartc.org/howto/lartc.loadshare.html), 
  but I do not have control over the termination of the link at the ISP's (two 
  different one as well). Also note that splitting different protocols over each 
  of these links are not possible in our case.Reason being, Link A is a 
  more reliable and more expensive link, so I need to over-use it's capacity if 
  it we're, and use the cheaper ADSL (link B) offering to keep al services 
  running when the leased line (A) is saturated.Any tips, suggestions 
  and comments would be welcomed.Regards-- Kenneth 
  Kalmer[EMAIL PROTECTED]http://opensourcery.blogspot.com 
  
  

  ___LARTC mailing 
  listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc