Is it possible to negate the "match" to the ip? I want to match all
traffic to dport 80 NOT going to dst 1.2.3.4:
$TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \
match ip protocol 0x6 0xff \
match ip dport 80 0xffff \
match ip dst 1.2.3.4/32 \
classid 1:14
I can''t find it in the docs. I tried "!" "\!" and
"not" in several
places, but always resulting in a "illegal match".
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
With u32 you cannot negate, that''s why it is lame...
Use iptables for marking packets
$TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip handle 14 fw
classid 1:14
Iptables -t mangle -A PREROUTING -p TCP --dport 80 -d ! 1.2.3.4 -j MARK
--set-mark 14
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl]
On Behalf Of richard lucassen
Sent: 2006 m. vasario 21 d. 18:25
To: lartc@mailman.ds9a.nl
Subject: [LARTC] invert u32 match selector
Is it possible to negate the "match" to the ip? I want to match all
traffic to dport 80 NOT going to dst 1.2.3.4:
$TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \
match ip protocol 0x6 0xff \
match ip dport 80 0xffff \
match ip dst 1.2.3.4/32 \
classid 1:14
I can''t find it in the docs. I tried "!" "\!" and
"not" in several
places, but always resulting in a "illegal match".
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
__________ NOD32 1.1415 (20060221) Information __________
This message was checked by NOD32 antivirus system.
http://www.nod32.com
On Wed, 22 Feb 2006 11:43:40 +0200 "Vaidas" <admin@vdx.lt> wrote:> With u32 you cannot negate, that''s why it is lame...And why doesn''t this work? (I send all port 80 to 1.2.3.4 to class 14 /before/ I send the rest to classid 13): $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ match ip protocol 0x6 0xff \ match ip dport 80 0xffff \ match ip dst 1.2.3.4/32 \ classid 1:14 $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ match ip protocol 0x6 0xff \ match ip dport 80 0xffff \ classid 1:13 Any ideas?> Use iptables for marking packets > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip handle 14 > fw classid 1:14 > > Iptables -t mangle -A PREROUTING -p TCP --dport 80 -d ! 1.2.3.4 -j > MARK --set-mark 14Ok, thnx. That''s of course a solution, but I just wondered if this were possible with u32... R. -- ___________________________________________________________________ It is better to remain silent and be thought a fool, than to speak aloud and remove all doubt. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht | | Public key and email address: | | http://www.lucassen.org/mail-pubkey.html | +------------------------------------------------------------------+
You should change the prios. The first filter should have a lower prio number than the second. That means that it is processed first and whatever is not matched by it is passed on to filters with higher prio number.> On Wed, 22 Feb 2006 11:43:40 +0200 > "Vaidas" <admin@vdx.lt> wrote: > >> With u32 you cannot negate, that''s why it is lame... > > And why doesn''t this work? (I send all port 80 to 1.2.3.4 to class 14 > /before/ I send the rest to classid 13): > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > match ip protocol 0x6 0xff \ > match ip dport 80 0xffff \ > match ip dst 1.2.3.4/32 \ > classid 1:14 > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > match ip protocol 0x6 0xff \ > match ip dport 80 0xffff \ > classid 1:13 > > Any ideas? > >> Use iptables for marking packets >> >> $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip handle 14 >> fw classid 1:14 >> >> Iptables -t mangle -A PREROUTING -p TCP --dport 80 -d ! 1.2.3.4 -j >> MARK --set-mark 14 > > Ok, thnx. That''s of course a solution, but I just wondered if this were > possible with u32... > > R. > > -- > ___________________________________________________________________ > It is better to remain silent and be thought a fool, than to speak > aloud and remove all doubt. > > +------------------------------------------------------------------+ > | Richard Lucassen, Utrecht | > | Public key and email address: | > | http://www.lucassen.org/mail-pubkey.html | > +------------------------------------------------------------------+ > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >-- Anton Glinkov network administrator
richard lucassen wrote:> On Wed, 22 Feb 2006 11:43:40 +0200 > "Vaidas" <admin@vdx.lt> wrote: > > >>With u32 you cannot negate, that''s why it is lame... > > > And why doesn''t this work? (I send all port 80 to 1.2.3.4 to class 14 > /before/ I send the rest to classid 13): > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > match ip protocol 0x6 0xff \ > match ip dport 80 0xffff \ > match ip dst 1.2.3.4/32 \ > classid 1:14 > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > match ip protocol 0x6 0xff \ > match ip dport 80 0xffff \ > classid 1:13 > > Any ideas?Looks OK to me - try what Anton suggested to be safe but order is usually enough. I guess IFB means this is ingress - if you are doing nat / or the ip you match is on that machine maybe it not passing ifb with the address you expect. Andy.
On Sat, 25 Feb 2006 16:04:06 +0000 Andy Furniss <andy.furniss@dsl.pipex.com> wrote:> > And why doesn''t this work? (I send all port 80 to 1.2.3.4 to class > > 14 /before/ I send the rest to classid 13): > > > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > > match ip protocol 0x6 0xff \ > > match ip dport 80 0xffff \ > > match ip dst 1.2.3.4/32 \ > > classid 1:14 > > > > $TC filter add dev ${DEV_IFB} parent 1:0 prio 2 protocol ip u32 \ > > match ip protocol 0x6 0xff \ > > match ip dport 80 0xffff \ > > classid 1:13 > > > > Any ideas? > > Looks OK to me - try what Anton suggested to be safe but order is > usually enough.ok, thnx.> I guess IFB means this is ingress - if you are doing nat / or the ip > you match is on that machine maybe it not passing ifb with the address > you expect.Hmm, I don''t think so because the ip is the machine itself and it won''t be translated... R. -- ___________________________________________________________________ It is better to remain silent and be thought a fool, than to speak aloud and remove all doubt. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht | | Public key and email address: | | http://www.lucassen.org/mail-pubkey.html | +------------------------------------------------------------------+
richard lucassen wrote:>>I guess IFB means this is ingress - if you are doing nat / or the ip >>you match is on that machine maybe it not passing ifb with the address >>you expect. > > > Hmm, I don''t think so because the ip is the machine itself and it won''t > be translated...Yes it should still have the interface address of the device it came in on - are you sure the packets are getting to ifb alright? Andy.