Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*IMQ\s+\/\s+new\s+Dummy\s+device\s+post\.\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*IMQ\s+\/\s+new\s+Dummy\s+device\s+post\.\s*$/: 54 ]

Total 54 documents matching your query.

1. IMQ / new Dummy device post. (score: 1): Author: an@xxxxxxxxx>; Date: Thu, 15 Apr 2004 10:42:29 +0100; I am just a user and would drop IMQ without hesitation for something you consider more elegant, but I am not sure whether or not dummy will do what I want. The only reason I use IMQ (+ NAT patch) is; /archives/netdev/2004-04/msg00243.html (9,021 bytes)
2. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxx>; Date: 15 Apr 2004 08:15:13 -0400; The summary is dummy can do what IMQ used to; it is however not related to iptables/netfilter. Yes you can attach a HTB. Look at the posted example in the previous email and replace prio with HTB. No; /archives/netdev/2004-04/msg00245.html (9,488 bytes)
3. Re: IMQ / new Dummy device post. (score: 1): Author: xxx>; Date: Thu, 15 Apr 2004 20:35:01 +0100; jamal wrote: On Thu, 2004-04-15 at 05:42, Andy Furniss wrote: The only reason I use IMQ (+ NAT patch) is that I need to shape ingress (I know I can't shape it "properly" from the wrong end of the bot; /archives/netdev/2004-04/msg00248.html (10,723 bytes)
4. Re: IMQ / new Dummy device post. (score: 1): Author: nut@xxxxxxxxxx>; Date: 15 Apr 2004 23:52:33 -0400; Just to be sure, this is not specific just to IP; it could be ARP, IPX, v6 etc. The packets are grabbed before NAT on the way in and after NAT on the way out. Coming from non-local machines before NA; /archives/netdev/2004-04/msg00251.html (11,150 bytes)
5. Re: IMQ / new Dummy device post. (score: 1): Author: @xxxxxxxxxxx>; Date: Fri, 16 Apr 2004 20:35:11 +0100; jamal wrote: On Thu, 2004-04-15 at 15:35, Andy Furniss wrote: jamal wrote: What I want to know is what state IP packets will be in if I Just to be sure, this is not specific just to IP; it could be A; /archives/netdev/2004-04/msg00261.html (13,044 bytes)
6. Re: IMQ / new Dummy device post. (score: 1): Author: er@xxxxxxxx>; Date: Sat, 17 Apr 2004 11:39:19 +0100; jamal wrote: On Fri, 2004-04-16 at 15:35, Andy Furniss wrote: This is what I wanted to know. Is it possible to make an option to get them after NAT in and pre NAT out? No i dont plan to. Why do you w; /archives/netdev/2004-04/msg00282.html (11,534 bytes)
7. Re: IMQ / new Dummy device post. (score: 1): Author: an@xxxxxxxxx>; Date: 17 Apr 2004 08:09:55 -0400; I think i am almost understanding you now. Your main concern is people using bittorrent to upload to you, correct? Is there a way to recognize packets going to/from bittorent? Dont jump into the HOW;; /archives/netdev/2004-04/msg00283.html (12,162 bytes)
8. Re: IMQ / new Dummy device post. (score: 1): Author: an Anastasov <ja@xxxxxx>; Date: Sat, 17 Apr 2004 22:56:52 +0100; jamal wrote: On Sat, 2004-04-17 at 06:39, Andy Furniss wrote: No i dont plan to. Why do you want to go that path? I think it's the only way I can shape/share my ingress traffic between a process (eg.; /archives/netdev/2004-04/msg00286.html (14,039 bytes)
9. Re: IMQ / new Dummy device post. (score: 1): Author: @xxxxxxxxxxx>; Date: 18 Apr 2004 10:28:00 -0400; You are speaking Inuit to me. What is connmark? and what is the relation to tcp slowstart. I am gonna assume that you have some way to recognize the flows destined to localhost which you want to pun; /archives/netdev/2004-04/msg00287.html (12,161 bytes)
10. Re: IMQ / new Dummy device post. (score: 1): Author: l@xxxxxxxxxxxx>; Date: Sun, 18 Apr 2004 17:35:17 +0100; jamal wrote: On Sat, 2004-04-17 at 17:56, Andy Furniss wrote: jamal wrote: I think i am almost understanding you now. Your main concern is people using bittorrent to upload to you, correct? Is there; /archives/netdev/2004-04/msg00290.html (15,545 bytes)
11. Re: IMQ / new Dummy device post. (score: 1): Author: .furniss@xxxxxxxxxxxxx>; Date: Sun, 18 Apr 2004 21:34:53 +0100; To accomodate your need for b), the idea would be as follows: packet gets demasquared, mark it with a fwmark I guess you really mean mark then demasquerade. based on some recognition you have for bit; /archives/netdev/2004-04/msg00292.html (12,676 bytes)
12. Re: IMQ / new Dummy device post. (score: 1): Author: l@xxxxxxxxxx>; Date: 18 Apr 2004 16:53:04 -0400; just from the sounds of it, appears it may be able to mark a group of related flows with the same fwmark. seems very similar in concept to what Alex (alex@xxxxxxxxxxxxx) was trying to achieve. Either; /archives/netdev/2004-04/msg00293.html (12,391 bytes)
13. Re: IMQ / new Dummy device post. (score: 1): Author: ss <andy.furniss@xxxxxxxxxxxxx>; Date: 18 Apr 2004 17:07:28 -0400; The problem is dummy had some speacial reason for existence in the old days of slip/ppp dummy acts as blackhole; some apps insist(ed) on getting a static IP address on primary interface when you are; /archives/netdev/2004-04/msg00294.html (11,973 bytes)
14. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxxx>; Date: Sun, 18 Apr 2004 23:23:52 +0200; connmark is like nfmark but it marks the connection-entry in ip_conntrack instead. And then you can "restore" that mark to the nfmark of the packet at any time you want with filter rules. with connma; /archives/netdev/2004-04/msg00295.html (12,591 bytes)
15. Re: IMQ / new Dummy device post. (score: 1): Author: i@xxxxxxxxxx>; Date: Sun, 18 Apr 2004 22:31:35 +0100; jamal wrote: On Sun, 2004-04-18 at 16:34, Andy Furniss wrote: Hmm second thoughts - if I can route packets to dummy after demasquerade then I don't need to mark - I can use u32 as I do now to seperat; /archives/netdev/2004-04/msg00296.html (13,056 bytes)
16. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxxxxxxxxx>; Date: Sun, 18 Apr 2004 22:58:33 +0100; Martin Josefsson wrote: On Sun, 2004-04-18 at 22:53, jamal wrote: On Sun, 2004-04-18 at 12:35, Andy Furniss wrote: Connmark is a netfilter patch which is required by the type of P2P limiting/marking; /archives/netdev/2004-04/msg00297.html (13,531 bytes)
17. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxxxxxxxxx>; Date: Sun, 18 Apr 2004 22:45:39 +0100; Andy Furniss wrote: I think this would still be a solution for me - I allready mark everything coming in on ppp0 in prerouting filter I meant mangle not filter of course :-) Andy.; /archives/netdev/2004-04/msg00298.html (11,543 bytes)
18. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxxxxxxxxx>; Date: Mon, 19 Apr 2004 10:14:48 +0200 (CEST); It works in all of the 5 mangle chains iirc. /Martin; /archives/netdev/2004-04/msg00299.html (11,984 bytes)
19. Re: IMQ / new Dummy device post. (score: 1): Author: xxxxxxxxxxxxx>; Date: Mon, 19 Apr 2004 14:33:16 +0200; Hmm I don't see -i option in the patches. what's the point of having a -i <inputdev> option ? does it mean I can work on egress at ppp0 and use -i eth0 to match packets that were originaly from eth0; /archives/netdev/2004-04/msg00303.html (10,969 bytes)
20. Re: IMQ / new Dummy device post. (score: 1): Author: t Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Mon, 19 Apr 2004 16:22:30 +0200; Ok it's seems to be working as expected for ipv4 traffic: Here is how i'm actually using it: (i use netfilter (for both ipv4 & ipv6) to mark packets) OUT=dummy0 $TC qdisc add dev $OUT root handle 1:; /archives/netdev/2004-04/msg00304.html (11,995 bytes)

Current List: 1 - 20
Page: [1] [2] [3]