[LARTC] ip conflict with proxy arp
HI, I've got a proxy arp setup with iptables and tc. on eth0 i have a route to 172.16.2.0/24 network on eth1 is the LAN of 172.16.1.0/24 network I have enabled proxy arp on both interfaces. Now accordingly, the interface will respond to all ARP requests for which it has a route to. Noy my setup is such, that a user on the LAN, would like to have an ip from the 172.16.2.0/24 network. But unfortunately, when he tries to allocate an ip like 172.16.2.1 he gets an ip conflict. I also know why he is getting it! But is there any way out of this?? Something like, tell the linux server to respond for ARP requests for the 172.16.2.0/24 network but at the same time if a machine is trying to use an ip for itself, then it should not respond. Help! -- arc_of_descent ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] the routing cache and route selection; is this correct?
Hello all, I do not read C very well (especially kernel C). Though I have tried to muddle my way through an understanding of what's going on in fib_hash.c, fib_rules.c, and route.c, I have not succeeded to my satisfaction, hence my post. I'm trying to document the general process of route selection, and have come up with the following overview. Could somebody point out any flaws in my understanding of the use of the routing cache during route selection and the route selection process? Starting point: packet enters the routing stage. - Attempt a lookup in the routing cache according to the following: + destination address + source address + type of service (tos) + fwmark (fwmark) + interface on which packet was received (iif) - If a routing cache entry exists, we're done: the route has been selected. - If there is no routing cache entry, we continue with route selection by consulting the RPDB and routing tables. 1 start traversing the RPDB at the highest priority 2 keep traversing the RPDB for the next matching entry 3 when a match is found, try to find a match for the destination in the designated table 4 if there is no matching route in the specified routing table continue to traverse the RPDB (skip back to step 2) 5 if there is a matching route, the route has been selected So, my question: Is the routing cache actually keyed on the above items? If I understand Arthur's post of last Friday properly (http://mailman.ds9a.nl/pipermail/lartc/2002q4/005641.html), he's suggesting that the keys in the routing cache are src, dest, and tos. If I understand my empirical evidence properly, and have muddled enough understanding of fib_rules.c, this statement is accurate, but not complete. My empirical evidence: I know I'm using fwmark routing on a particular host, and packets are transmitted out the "correct" interfaces when I generate traffic for all of the fwmark'd routes. What confuses me is the output of "ip route show cache ip.ad.dr.es". There is no reference whatsoever to fwmark in this output. Can somebody confirm (as the evidence suggests) that the routing cache is keyed on the above five elements? -Martin -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] ingress works with this iproute version (src)
Okay, for those who have problems with ingress: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz is your version of iproute+tc that you want. Versions below that didn't work for me either. I used kernel 2.4.19 and if you are looking for CONFIG_NETLINK or CONFIG_RTNETLINK - forget it. You are okay with CONFIG_NETLINK_DEV. -- Robert Felber ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Shell Account in .NL and .DE for me ?
Hi, please is someone willing to gine me SSH account on some server with .DE nd .NL reverse DNS ? Replies to private mail please. Thanks, devik ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Deleting ingress tbf
Quick question: How do I delete an ingress tbf? [root@atlas root]# tc qdisc qdisc tbf : dev eth0 rate 50Kbit burst 2999b lat 1us [root@atlas root]# tc qdisc del dev eth0 ingress RTNETLINK answers: Invalid argument ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 2-NIC DMZ?
*smacks forehead* I'm an idiot. I actually had all of the rules correct, including those two you listed. However, I had them in the opposite order from what you listed. This was a problem, since both my NAT network and my workstation IP are all on the 192.168.0.x network. Therefore, since the first rule matched packets coming from my desktop as coming from the "internal" network, that rule executed and it went on its merry way. Seeing your post made me re-examine my script more closely, and that showed the problem. Thank you! -- Justin - Original Message - From: "Ken Price" <[EMAIL PROTECTED]> To: "'Justin Richer'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 28, 2002 5:05 PM Subject: RE: [LARTC] 2-NIC DMZ? > *VERY* easy. No routing rules involved, just IPTABLES: > > For your workstation: > # iptables -t nat -A POSTROUTING -s 192.168.0.5 (your workstation statis IP) > -o eth0 -j SNAT --to PUBLIC_IP_1 > Then, for everyone else: > # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to PUBLIC_IP_2 > > > -Ken > > > -Original Message- > From: Justin Richer [mailto:ru2def@;whoever.com] > Sent: Monday, October 28, 2002 11:28 AM > To: [EMAIL PROTECTED] > Subject: [LARTC] 2-NIC DMZ? > > > Hi all, > > I have two static IPs from my ISP. I would like one of these IPs to be > directed to my desktop box all the time, and the other to be directed to a > DHCP-served NAT network. I've nearly gotten it working using iptables and > iproute2, but one problem is that i would like packets coming from my > desktop box via the firewall to be printed with my desktop's external IP. > They are currently being seen as from the NAT-hosted IP, which is the main > IP address of the firewall box's external NIC. My setup looks like this: > > DSL Bridge -> [eth0] Firewall [eth1] -> 8-port-switch -> static desktop > \-> (NAT cloud) > > is it possible to send packets from the firewall looking like they came from > a different external IP address based on which internal IP they were routed > from? it seems to me it really should be possible to do ... just, how? > > Thanks, > -- Justin > > ___ > 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/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 28 Oct 2002, Vincent Jaussaud wrote: > My question is, if we ensure that EVERY packets, whatever path they use > to arrive, finally pass through a single peer doing NAT, is this suppose > to work around my TOS problem ? Sounds correct. The requirement is each packet from one connection to be NAT-ed only from one NAT router and to same masquerade address and port. The routing cache can not guarantee that. It can be done only from the patched masquerade. > What about the rp_filter kernel value ? Could it be a problem in such > setup ? The patches are designed to work with rp_filter enabled. You can safely use it, it is changed to work only with the defined paths. > Thanks again. > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] 2-NIC DMZ?
*VERY* easy. No routing rules involved, just IPTABLES: For your workstation: # iptables -t nat -A POSTROUTING -s 192.168.0.5 (your workstation statis IP) -o eth0 -j SNAT --to PUBLIC_IP_1 Then, for everyone else: # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to PUBLIC_IP_2 -Ken -Original Message- From: Justin Richer [mailto:ru2def@;whoever.com] Sent: Monday, October 28, 2002 11:28 AM To: [EMAIL PROTECTED] Subject: [LARTC] 2-NIC DMZ? Hi all, I have two static IPs from my ISP. I would like one of these IPs to be directed to my desktop box all the time, and the other to be directed to a DHCP-served NAT network. I've nearly gotten it working using iptables and iproute2, but one problem is that i would like packets coming from my desktop box via the firewall to be printed with my desktop's external IP. They are currently being seen as from the NAT-hosted IP, which is the main IP address of the firewall box's external NIC. My setup looks like this: DSL Bridge -> [eth0] Firewall [eth1] -> 8-port-switch -> static desktop \-> (NAT cloud) is it possible to send packets from the firewall looking like they came from a different external IP address based on which internal IP they were routed from? it seems to me it really should be possible to do ... just, how? Thanks, -- Justin ___ 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/
Re: [LARTC] 2-NIC DMZ?
Hi AFAIK, you can do all of this by using FIAIF: http://fiaif.fugmann.dhs.org/ which is a VERY nice and highly customizable script for setting up an iptables based firewall. It has traffic shaping too. Regards Lars Munch On Mon, Oct 28, 2002 at 11:27:37AM -0500, Justin Richer wrote: > Hi all, > > I have two static IPs from my ISP. I would like one of these IPs to be > directed to my desktop box all the time, and the other to be directed to a > DHCP-served NAT network. I've nearly gotten it working using iptables and > iproute2, but one problem is that i would like packets coming from my > desktop box via the firewall to be printed with my desktop's external IP. > They are currently being seen as from the NAT-hosted IP, which is the main > IP address of the firewall box's external NIC. My setup looks like this: > > DSL Bridge -> [eth0] Firewall [eth1] -> 8-port-switch -> static desktop > \-> (NAT cloud) > > is it possible to send packets from the firewall looking like they came from > a different external IP address based on which internal IP they were routed > from? it seems to me it really should be possible to do ... just, how? > > Thanks, > -- Justin > > ___ > 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/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
On Mon, 28 Oct 2002, Don Cohen wrote: > > > I'd like to ask for some clarifications, if not quoting, in the tutorial > > on page x321.html (not sure of section numbers) re: syn cookies. > > I don't understand what the question is here. The question is that I state that turning on syncookies may wreak havoc on the TCP stack, which Dan Bernstein totally disagrees with. > > > Dan Bernstein (everyone's favorite mathematician :-) ) makes it very > > I was not aware of that. Well, he is rather interesting:). Has a lot of interesting ideas and was/is the original author of qmail and tinydns and a couple of other projects if I am not totally off base. According to himself, he has published some 200k rows of code/text online. > > > clear on http://cr.yp.to/syncookies.html that your warnings are > > primarily FUD. For the sake of quoting: > > A few people (notably Alexey Kuznetsov, Wichert Akkerman, and Perry > > Metzger) have been spreading misinformation about SYN cookies. Here are > > some of their bogus claims: > > I was also not aware of any such controversy, but I think the points > below are correct. To an extent, but... most of what he is using to prove his point on that page is taken from 1996, and in computer terms, that is ancient:). My main doubts are neither of the below points actually, but the fact that syn cookies seem to shred up SACK and T/TCP support. In 1996 this was no problem since it wasn't implemented in Linux, but today it is... and turned on per default... My question hence is, how is the state of syn cookies today? How does it actually affect SACK, T/TCP, ECN, and other new extensions? That's what I want to find out before making a more final statement in the document. (erh, ok it sounds kind of final as it looks right now, but I want to check it up at least before doing any final statements). > > > * SYN cookies ``present serious violation of TCP protocol.'' > > Reality: SYN cookies are fully compliant with the TCP protocol. > > Every packet sent by a SYN-cookie server is something that could > > also have been sent by a non-SYN-cookie server. > > * SYN cookies ``do not allow to use TCP extensions'' such as large > > windows. Reality: SYN cookies don't hurt TCP extensions. A > > connection saved by SYN cookies can't use large windows; but the > > same is true without SYN cookies, because the connection would > > have been destroyed. > > * SYN cookies cause ``massive hanging connections.'' Reality: With > > or without SYN cookies, connections occasionally hang because a > > computer or network is overloaded. Applications deal with this by > > simply dropping idle connections. > > * SYN cookies cause ``serious degradation of service.'' Reality: SYN > > cookies /improve/ service. They do take a small amount of CPU time > > to compute, but that CPU time has to be spent anyway for > > hard-to-predict sequence numbers; see RFC 1948. > > * SYN cookies cause ``magic resets.'' Reality: SYN cookies never > > cause resets. > > > > These people also have the annoying habit of crediting their bogus > > claims to other people, such as me. I don't know whether to attribute > > this to malice or stupidity; either way, I would like the record to be > > set straight. > > > > I invited Kuznetsov to either retract or defend his claims. He refused > > to do so. I'm sure he's aware by now that his claims are false, and that > > any attempted defense will be promptly ripped to shreds; but he's still > > not admitting his errors. It's unfortunate that he doesn't have more > > respect for the truth. > > > > I also invited Akkerman to either retract or defend his claims. He did > > not respond. > > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Oskar Andreasson http://www.frozentux.net http://iptables-tutorial.frozentux.net http://ipsysctl-tutorial.frozentux.net mailto:blueflux@;koffein.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 2-NIC DMZ?
Hi AFAIK, you can do all of this by using FIAIF: http://fiaif.fugmann.dhs.org/ which is a VERY nice and highly customizable script for setting up an iptables based firewall. It has traffic shaping too. Regards Lars Munch On Mon, Oct 28, 2002 at 11:27:37AM -0500, Justin Richer wrote: > Hi all, > > I have two static IPs from my ISP. I would like one of these IPs to be > directed to my desktop box all the time, and the other to be directed to a > DHCP-served NAT network. I've nearly gotten it working using iptables and > iproute2, but one problem is that i would like packets coming from my > desktop box via the firewall to be printed with my desktop's external IP. > They are currently being seen as from the NAT-hosted IP, which is the main > IP address of the firewall box's external NIC. My setup looks like this: > > DSL Bridge -> [eth0] Firewall [eth1] -> 8-port-switch -> static desktop > \-> (NAT cloud) > > is it possible to send packets from the firewall looking like they came from > a different external IP address based on which internal IP they were routed > from? it seems to me it really should be possible to do ... just, how? > > Thanks, > -- Justin > > ___ > 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/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
bert hubert wrote: Please keep this stuff off lartc.org. There has been enough flaming regarding SYN cookies and whatnot. Put that on the mailing list FAQ then; otherwise its fair game. I actually know some of the people mentioned on DJBs page in real life and they are bone tired of it all too. I'm not quite convinced that my being tired of something or not prevents you from telling me I'm wrong about something or requesting discussion about it -- especially when its material relevant to the subject of the list. PS, assuming they are tired of it, why have I never seen a good (well-prepared / documented) commentary on the issue from any of them? However, So give it a rest. Please do not respond to this message Obviously, I replied -- but I'm sure you expected as much when you sent your message. You're free of course to boot me from the list if you feel that my desiring clarification on a long-standing issue (in two whole messages; three with this one) is too much for you to handle. In case you're wondering, I'm not much of a DJB supporter myself, but I do appreciate (and usually demand) accuracy, especially where it affects my servers and my work. FUD, on either side, is not appreciated, in the least, nor is complete silence. Your Kind List Administrator -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
On Mon, Oct 28, 2002 at 03:16:45PM -0500, Michael T. Babcock wrote: > It isn't a question (thus the lack of question mark). I asked for > either a clarification or a quotation of the page mentionned in the FAQ > to avoid confusion (or add some?) about syn cookies. Please keep this stuff off lartc.org. There has been enough flaming regarding SYN cookies and whatnot. I actually know some of the people mentioned on DJBs page in real life and they are bone tired of it all too. So give it a rest. Please do not respond to this message Regards, Bert Hubert Your Kind List Administrator -- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
Don Cohen wrote: > I'd like to ask for some clarifications, if not quoting, in the tutorial > on page x321.html (not sure of section numbers) re: syn cookies. I don't understand what the question is here. It isn't a question (thus the lack of question mark). I asked for either a clarification or a quotation of the page mentionned in the FAQ to avoid confusion (or add some?) about syn cookies. > Dan Bernstein (everyone's favorite mathematician :-) ) makes it very I was not aware of that. DJB, as he is known, tends to be a bit strong minded and has a habit of thinking that everyone should want what he wants. He also has a tendancy to write secure software and is a pretty good number cruncher too (has his own hash library, does cryptography, etc.) Some love him, some hate him, but if you search for 'DJB' on Google, I'm sure you'll find plenty. I was also not aware of any such controversy, but I think the points below are correct. I have a good feeling they're correct too, since I've been using syn cookies "forever" now without any problems of which I'm aware. I'm surprised those mentionned haven't said anything (or that I haven't read it yet) that contradicts DJB (who was involved in the design of SYN cookies). -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
> I'd like to ask for some clarifications, if not quoting, in the tutorial > on page x321.html (not sure of section numbers) re: syn cookies. I don't understand what the question is here. > Dan Bernstein (everyone's favorite mathematician :-) ) makes it very I was not aware of that. > clear on http://cr.yp.to/syncookies.html that your warnings are > primarily FUD. For the sake of quoting: > A few people (notably Alexey Kuznetsov, Wichert Akkerman, and Perry > Metzger) have been spreading misinformation about SYN cookies. Here are > some of their bogus claims: I was also not aware of any such controversy, but I think the points below are correct. > * SYN cookies ``present serious violation of TCP protocol.'' > Reality: SYN cookies are fully compliant with the TCP protocol. > Every packet sent by a SYN-cookie server is something that could > also have been sent by a non-SYN-cookie server. > * SYN cookies ``do not allow to use TCP extensions'' such as large > windows. Reality: SYN cookies don't hurt TCP extensions. A > connection saved by SYN cookies can't use large windows; but the > same is true without SYN cookies, because the connection would > have been destroyed. > * SYN cookies cause ``massive hanging connections.'' Reality: With > or without SYN cookies, connections occasionally hang because a > computer or network is overloaded. Applications deal with this by > simply dropping idle connections. > * SYN cookies cause ``serious degradation of service.'' Reality: SYN > cookies /improve/ service. They do take a small amount of CPU time > to compute, but that CPU time has to be spent anyway for > hard-to-predict sequence numbers; see RFC 1948. > * SYN cookies cause ``magic resets.'' Reality: SYN cookies never > cause resets. > > These people also have the annoying habit of crediting their bogus > claims to other people, such as me. I don't know whether to attribute > this to malice or stupidity; either way, I would like the record to be > set straight. > > I invited Kuznetsov to either retract or defend his claims. He refused > to do so. I'm sure he's aware by now that his claims are false, and that > any attempted defense will be promptly ripped to shreds; but he's still > not admitting his errors. It's unfortunate that he doesn't have more > respect for the truth. > > I also invited Akkerman to either retract or defend his claims. He did > not respond. > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Fw: wondershaper kills eth0 :(
Hi, When i do 'wshaper start' the interface i have defined stops routing traffic for some reason. It resumes routing when i do 'wshaper stop'. I'm using debian stable (3.0 woody) with debian's default 2.4.18-686 kernel. When I run the script I get no errors, and when I do a 'status', everything looks correct. Can ANYONE please give me a little insight as to what to do? I have the variables set as follows: DOWNLINK=1450 UPLINK=180 DEV=eth0 The machine is a NAT machine. I'm using shorewall to handle the NAT stuff for me. But even with shorewall disabled, wshaper still fails. Thank you for your help. -Rob ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] 2-NIC DMZ?
Hi all, I have two static IPs from my ISP. I would like one of these IPs to be directed to my desktop box all the time, and the other to be directed to a DHCP-served NAT network. I've nearly gotten it working using iptables and iproute2, but one problem is that i would like packets coming from my desktop box via the firewall to be printed with my desktop's external IP. They are currently being seen as from the NAT-hosted IP, which is the main IP address of the firewall box's external NIC. My setup looks like this: DSL Bridge -> [eth0] Firewall [eth1] -> 8-port-switch -> static desktop \-> (NAT cloud) is it possible to send packets from the firewall looking like they came from a different external IP address based on which internal IP they were routed from? it seems to me it really should be possible to do ... just, how? Thanks, -- Justin ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
> > It seems you can safely alter the TOS for all packets > entering your box/site. > Ok, I'll dig into this tip, and see how it goes. If I can't figure out this NAT problem, I'll do this. > May be you can hunt it with tcpdump. I assume your are > using the patches because the plain kernel has the same problem > for NAT. > Yes, I am running your patch. Kernel is 2.2.22 with routes-2.2.20-7.diff patch applied. (I'm sure of this, otherwise dead gateway detection will simply not work.) My question is, if we ensure that EVERY packets, whatever path they use to arrive, finally pass through a single peer doing NAT, is this suppose to work around my TOS problem ? Eg, end services will only see packets coming from the last NAT address, which is single whatever path packets used to arrive. Something like: LAN --> Multipath Firewall | | GW1GW2 | | --- | Gateway (NAT) | - Remote Network What about the rp_filter kernel value ? Could it be a problem in such setup ? Thanks again. Vincent. > > A big thanks to both of you. I've learned a lot today :) > > > > Thanks again. > > Regards, > > Vincent. > > Regards > > -- > Julian Anastasov <[EMAIL PROTECTED]> > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Vincent Jaussaud Kelkoo.com Security Manager email: [EMAIL PROTECTED] "The UNIX philosophy is to design small tools that do one thing, and do it well." ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] CBQ broken in RedHat 8.0?
Hello, On Sun, 27 Oct 2002 09:23:52 -0800, "David Boreham" <[EMAIL PROTECTED]> wrote: > > >Why upgrading your SUSE? You can also download 2.4.19 from > ftp.kernel.org > > > and patch with the lates htb patch ?? > > I find that inserting a stock kernel into a machine originally > running a distro (RH, Mandrake etc) is often a painful and > unrewarding experience. That is only true for distros that do heavy patching of stock kernels, which is bad IMHO. For example Debain only patches the kernel to fix bad bugs discovered after kernel release and to exclude non-free data from kernel. Thus the stock kernel works perfectly fine on a Debian system AND if you run unstable you can get Debian versions of kernels in few days after kernel release. -- Best regards, Aigars Mahinovsmailto:aigarius@;debian.org #--# | .''`.| |: :' : Debian GNU/Linux | |`. `' http://www.debian.org | | `- | #--# msg02609/pgp0.pgp Description: PGP signature
[LARTC] failed shaping outgoing traffic
I used cbq in my gateway, eth1 connecting to internet, and eth0 to local network, to poll traffic in/out using ipchains accounting and mrtg. Now i have succeed shaping incoming traffic to my local network with my configuration using cbq on eth0, but when i try to shaping outgoing traffic from my local network i see it didn't workout from my mrtg. RULE=10.111.1.2 (for incoming) RULE=10.111.1.2, (for outgoing) Any body have an idea to solve this ? Best regards, >< ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
