Hi, I note that in tcrules, RESTORE applies a default mask of 0xFFFF in
the case of running the equiv of WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=Yes
However, if you try RESTORE/MASK it''s clipped at TC_BITS (so 0x3FFF in
this case). I think this also applies to SAVE.
Seems inconsistent (you can''t specify such a large mask as the default,
when you try it manually).
I wonder though if we actually need limit the range for SAVE/RESTORE at
all? It protects against saving or restoring route mark bits, but is
that necessary? Perhaps if TC_EXPERT is set then there could be no
limit on the mask used for SAVE/RESTORE? Comments?
Not even sure why this is even worth mentioning, but:
/usr/share/shorewall/Shorewall/Chains.pm: fatal_error "Mark value
($mark) too large" if numeric_value( $mark ) > $globals{TC_MAX};
/usr/share/shorewall/Shorewall/Tc.pm: fatal_error "Invalid Mark
($mark)" unless $markval <= $globals{TC_MAX};
The code police might comment on the varying ways of expressing the same
test (but not me...)
Many thanks
Ed W
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
On 4/22/12 6:39 PM, Ed W wrote:> Hi, I note that in tcrules, RESTORE applies a default mask of 0xFFFF in > the case of running the equiv of WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=Yes > > However, if you try RESTORE/MASK it''s clipped at TC_BITS (so 0x3FFF in > this case). I think this also applies to SAVE. > > Seems inconsistent (you can''t specify such a large mask as the default, > when you try it manually).This inconsistency is the result of an unfortunate choice some time ago; see http://www.shorewall.net/PacketMarking.html#Values.> > I wonder though if we actually need limit the range for SAVE/RESTORE at > all? It protects against saving or restoring route mark bits, but is > that necessary? Perhaps if TC_EXPERT is set then there could be no > limit on the mask used for SAVE/RESTORE? Comments?Too many people who consider themselves experts are only expert at doing the wrong thing; I think I''ll leave it the way it is. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
On 23/04/2012 04:10, Tom Eastep wrote:> On 4/22/12 6:39 PM, Ed W wrote: >> Hi, I note that in tcrules, RESTORE applies a default mask of 0xFFFF in >> the case of running the equiv of WIDE_TC_MARKS=Yes, HIGH_ROUTE_MARKS=Yes >> >> However, if you try RESTORE/MASK it''s clipped at TC_BITS (so 0x3FFF in >> this case). I think this also applies to SAVE. >> >> Seems inconsistent (you can''t specify such a large mask as the default, >> when you try it manually). > This inconsistency is the result of an unfortunate choice some time ago; > see http://www.shorewall.net/PacketMarking.html#Values.I''m thinking of the latest shorewall actually. I think I wondered why you didn''t use something like provider_offset as your bits count, rather than mask_bits? (I guess it needs to be max(something, something), but I haven''t investigated the details?)>> I wonder though if we actually need limit the range for SAVE/RESTORE at >> all? It protects against saving or restoring route mark bits, but is >> that necessary? Perhaps if TC_EXPERT is set then there could be no >> limit on the mask used for SAVE/RESTORE? Comments? > Too many people who consider themselves experts are only expert at doing > the wrong thing; I think I''ll leave it the way it is.Hmm, I just found something I need this for: - Squid, DNSMasq and some apps I have written read the incoming *connection* mark, and copy that to the outgoing packet mark. The intention is that marks applied to local ips (users) get copied through such proxy servers and applied to the outgoing connection. So these "proxy" type servers look like the original user rather than an app on your router. This is helpful for certain applications, such as counting per user traffic, captive portals, etc. So I need to copy my route markings (probably the whole fwmark actually) to the connection mark... Would you mind recommending a workaround I might use for that long term, given that this might not represent your average user action? What about - an accidently undocumented option TOTAL_BITS (or better name) which defaults to the current formula, but is used to set the size of the SAVE/RESTORE mask (ideally we don''t want extra options though) - re-use TC_EXPERT to let you shoot yourself even harder? I would be grateful if we could avoid option 3: - I patch shorewall for my own requirements It''s something of a pain for deployment to keep a patchset like this... Do you have an opinion? Note I''m rather hoping this mark copying feature will become popular... Many thanks Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
On 23/04/2012 05:26, Ed W wrote:> Hmm, I just found something I need this for: > > - Squid, DNSMasq and some apps I have written read the incoming > *connection* mark, and copy that to the outgoing packet mark. > > The intention is that marks applied to local ips (users) get copied > through such proxy servers and applied to the outgoing connection. So > these "proxy" type servers look like the original user rather than an > app on your router. This is helpful for certain applications, such as > counting per user traffic, captive portals, etc. > > So I need to copy my route markings (probably the whole fwmark actually) > to the connection mark... Would you mind recommending a workaround I > might use for that long term, given that this might not represent your > average user action? What about > - an accidently undocumented option TOTAL_BITS (or better name) which > defaults to the current formula, but is used to set the size of the > SAVE/RESTORE mask (ideally we don''t want extra options though) > - re-use TC_EXPERT to let you shoot yourself even harder? >Hi, please see attached for a possible patch to allow saving routing fwmarks up into the conntrack mark. It''s almost certainly wrong, so lets assume it''s a talking point... Also attached a patch for what appears to be a typo in the configure file? I did mention it a couple of emails back, but I think it might have been in the middle of a bunch of hot air from me and you missed it? Many thanks Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
On 4/23/12 8:35 AM, Ed W wrote:> > Hi, please see attached for a possible patch to allow saving routing > fwmarks up into the conntrack mark. It''s almost certainly wrong, so > lets assume it''s a talking point...It actually looks fine.> > Also attached a patch for what appears to be a typo in the configure > file? I did mention it a couple of emails back, but I think it might > have been in the middle of a bunch of hot air from me and you missed it?I''ve also been sick in bed for most of the last week so haven''t been at my best. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
On 23/04/2012 16:55, Tom Eastep wrote:> I''ve also been sick in bed for most of the last week so haven''t been at > my best.Sorry to hear that! A lot of it about over here... Get well soon! Thanks for all you very fast responses on email, especially given your condition! Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2