rp_filter

rp_filter

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Hey all,

  Can we *please* move the rp_filter cruft into the firewalling code
  proper?  I've had yet another friend come to me asking for help after
  fighting with his iptables setup for 6 hours trying to get it to work
  to discover the whole problem was rp_filter getting in the way.  If
  rp_filter was part of the actual firewalling code where it should be
  people wouldn't run into this stupid problem.

  rp_filter is an obscure option that only the poor souls who ran into
  it know about.  I've met people who have implemented it all by hand in
  iptables because they didn't know it existed, and then didn't entirely
  trust it.  The people who need the option (those who actually run
  routers or firewalls) know they need it and will take care of having
  it enabled in their firewalling code, for most people (desktop users 
  and whatnot) it's useless anyway because they've only got one
  interface.

  	Stephen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: rp_filter

[Patrick Schaaf]

Stephen,

>   Can we *please* move the rp_filter cruft into the firewalling code
>   proper?

If that's not a joke, please take your cruisade to the linux-net mailing
list. It is not up to netfilter / iptables developers to even think
about removal of base network stack features, in my opinion. Convince
Dave Miller and Alexey Kusnetsov (speling probably wrong, sorry).

I'll refrain from speaking against the idea itself, here.

best regards
  Patrick

Re: rp_filter

[Patrick Schaaf]

Stephen & all,

>   Can we *please* move the rp_filter cruft into the firewalling code
>   proper?

Upon thinking a bit more about your request, there is one thing
that annoys me about rp_filter, and where iptables may eventually
help: there was (and probably is) the idea of a DROP table, where
you can LOG packets coming from all kinds of drop sites within
the network stack. It would be great if I had a way to LOG packets
rejected by rp_filter. IMHO the big problem to the unwary end-user,
is the _invisibility_ of the drops caused by rp_filter.

A simple net_ratelimit()ed printk() in the appropriate place, would
already help a lot. If you walk your request over to linux-net, maybe
you could make that your fallback position :-)

best regards
  Patrick

Re: rp_filter

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

* Patrick Schaaf (bof@bof.de) wrote:
> Stephen,
> 
> >   Can we *please* move the rp_filter cruft into the firewalling code
> >   proper?
> 
> If that's not a joke, please take your cruisade to the linux-net mailing
> list. It is not up to netfilter / iptables developers to even think
> about removal of base network stack features, in my opinion. Convince
> Dave Miller and Alexey Kusnetsov (speling probably wrong, sorry).
> 
> I'll refrain from speaking against the idea itself, here.

If we had the functionality in netfilter to do what rp_filter does now I
think it'd make for a much better case to get rid of it as it exists.
For that I think we'd need a match target that checked source IP and
incoming interface and compared it against the routing table.  Not
something I'd expect to be very difficult...

I'll see about bringing it up on the linux-net list if this seems like a
reasonable thing to add to netfilter.  I certainly agree about one of
the problems with rp_filter being that it's not noisy about things it
drops (by default at least, I think there may be an option to turn on
logging of it).  It would seem reasonable to me to have the parts of the
kernel that drop packets following some administrative rule be under the
firewalling framework instead of elsewhere throughout the kernel.

	Stephen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: rp_filter

[Roberto Nibali]

>>  Can we *please* move the rp_filter cruft into the firewalling code
>>  proper?

I agree with Patrick on that it is not an intelligent idea to touch core network 
stuff in the netfilter code. Especially I seem to see more and more routing 
related POM patches for netfilter while I wonder what issues people really have 
with the current routing code which is where rp_filter belongs to?

> Upon thinking a bit more about your request, there is one thing
> that annoys me about rp_filter, and where iptables may eventually
> help: there was (and probably is) the idea of a DROP table, where
> you can LOG packets coming from all kinds of drop sites within
> the network stack. It would be great if I had a way to LOG packets

I've once started it but due to the network core's diversity in handling such 
cases I've stopped doing it. You get everything from silent drop via kfree over 
skb_free over return EINVAL over goto drop and so on ...

> rejected by rp_filter. IMHO the big problem to the unwary end-user,
> is the _invisibility_ of the drops caused by rp_filter.

That is a general nuisance and setting verbose_route_log and log_martians 
already helps a bit but most of the FIB related errors don't get logged. I know 
what you're talking about, I've even once started to debug tcpdump because of a 
badly set rp_filter value while doing asymmetric routing in a load balanced 
environment. It sucks rocks!!

> A simple net_ratelimit()ed printk() in the appropriate place, would
> already help a lot. If you walk your request over to linux-net, maybe
> you could make that your fallback position :-)

netdev or linux-net might be the best place to discuss it, yes. As a start you 
could patch ../linux/net/ipv4/fib_frontend.c:fib_validate_source(). Check for 
the rpf variable and follow it's invariants.

I don't agree with putting a net_ratelimit() on every network related place for 
logging. I took them out in my kernels because I rather have a system that can 
filter less packets but log the most packets than having a packet filter that 
can filter a lot but where syslogd doesn't get enough computing time anymore to 
read the printk ringbuffer.

Best regards,
Roberto Nibali, ratz
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

rp_filter

[Leroy Tennison]

SXMgdGhlcmUgYSBkZWZpbml0aXZlIHdheSB0byB0ZWxsIHRoYXQgcnBfZmlsdGVyIGlzIGRyb3Bw
aW5nIHRyYWZmaWMgKGluIHRoaXMgY2FzZSBlY2hvIHJlcXVlc3QpIG90aGVyIHRoYW4gZGlzYWJs
aW5nIGl0IGFuZCBzZWVpbmcgdGhlIGV4cGVjdGVkIHRyYWZmaWMgKGVjaG8gcmVwbHkpPyAgSSB0
cmllZCBhbiBpcHRhYmxlcyBwYWNrZXQgdHJhY2UgYnV0IEkgZWl0aGVyIGRpZCBpdCB3cm9uZyBv
ciBpdCBzaG93ZWQgbm90aGluZy4gIFRoZSBvbmx5IGluZGljYXRpb25zIEkgaGF2ZSByaWdodCBu
b3cgYXJlOg0KDQpObyBmaXJld2FsbCBydWxlcyBibG9ja2luZyB0cmFmZmljIGJ1dCBubyByZXBs
aWVzIGVpdGhlci4NClRoZSBwcm9ibGVtIGlzIHN1Ym5ldC1zcGVjaWZpYyAob25seSBvY2N1cnMg
b24gYSBkaXJlY3RseS1jb25uZWN0ZWQgc3VibmV0KS4NCg0KRWFybHkNCkJpcmQgRXh0ZW5kZWQh
IFNhdmUgbm93IHVudGlsIEp1bHkgMjAgb24gdGhlIDIwMTggTW9tZW50dW0gVXNlcg0KQ29uZmVy
ZW5jZSENClJlZ2lzdGVyDQpoZXJlDQpMZXJveSBUZW5uaXNvbg0KTmV0d29yayBJbmZvcm1hdGlv
bi9DeWJlciBTZWN1cml0eSBTcGVjaWFsaXN0DQpFOiBsZXJveUBkYXRhdm9pY2VpbnQuY29tDQoy
MjIwIEJ1c2ggRHINCk1jS2lubmV5LCBUZXhhcw0KNzUwNzANCnd3dy5kYXRhdm9pY2VpbnQuY29t
DQpUVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNlbnQgb24gYmVoYWxmDQpvZiBhIGNvbXBhbnkgdGhh
dCBpcyBwYXJ0IG9mIHRoZSBIYXJyaXMgT3BlcmF0aW5nIEdyb3VwIG9mDQpDb25zdGVsbGF0aW9u
IFNvZnR3YXJlIEluYy4gVGhlc2UgY29tcGFuaWVzIGFyZSBsaXN0ZWQNCmhlcmUNCi4NCklmIHlv
dSBwcmVmZXIgbm90IHRvIGJlIGNvbnRhY3RlZCBieSBIYXJyaXMNCk9wZXJhdGluZyBHcm91cA0K
cGxlYXNlIG5vdGlmeSB1cw0KLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5
IGZvciB0aGUNCmluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g
VGhpcyBjb21tdW5pY2F0aW9uDQptYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIHByb3By
aWV0YXJ5LCBwcml2aWxlZ2VkIG9yDQpjb25maWRlbnRpYWwgb3Igb3RoZXJ3aXNlIGxlZ2FsbHkg
ZXhlbXB0IGZyb20gZGlzY2xvc3VyZS4gSWYgeW91IGFyZQ0Kbm90IHRoZSBuYW1lZCBhZGRyZXNz
ZWUsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8gcmVhZCwgcHJpbnQsDQpyZXRhaW4sIGNvcHkg
b3IgZGlzc2VtaW5hdGUgdGhpcyBtZXNzYWdlIG9yIGFueSBwYXJ0IG9mIGl0LiBJZiB5b3UNCmhh
dmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXINCmltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlDQpt
ZXNzYWdlLg0KDQo

Re: rp_filter

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]

On 07/13/2018 09:23 AM, Leroy Tennison wrote:
> Is there a definitive way to tell that rp_filter is dropping traffic (in 
> this case echo request) other than disabling it and seeing the expected 
> traffic (echo reply)?  I tried an iptables packet trace but I either did 
> it wrong or it showed nothing.  The only indications I have right now are:

Check dmesg.  That's the most reliable place I've seen for logs about 
(so called) "martian" packets.

> No firewall rules blocking traffic but no replies either.

It seems like reverse path filtering operates at a lower layer before 
IPTables.

> The problem is subnet-specific (only occurs on a directly-connected 
> subnet).

Odd.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]

Re: rp_filter

[Jay Vosburgh]

Grant Taylor <gtaylor@tnetconsulting.net> wrote:

>On 07/13/2018 09:23 AM, Leroy Tennison wrote:
>> Is there a definitive way to tell that rp_filter is dropping traffic (in
>> this case echo request) other than disabling it and seeing the expected
>> traffic (echo reply)?  I tried an iptables packet trace but I either did
>> it wrong or it showed nothing.  The only indications I have right now
>> are:
>
>Check dmesg.  That's the most reliable place I've seen for logs about (so
>called) "martian" packets.

	I believe they're also counted in the "in_martian_src" column of
/proc/net/stat/rt_cache.

	-J

>> No firewall rules blocking traffic but no replies either.
>
>It seems like reverse path filtering operates at a lower layer before
>IPTables.
>
>> The problem is subnet-specific (only occurs on a directly-connected
>> subnet).
>
>Odd.
>
>
>
>-- 
>Grant. . . .
>unix || die

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

Re: rp_filter

[Leroy Tennison]

VGhhbmtzIGZvciB5b3VyIHJlcGx5LCBJIGFwcHJlY2lhdGUgaXQuICBZb3UgcmVwbGllZCAib2Rk
IiBjb25jZXJuaW5nIG15IHN1Ym5ldC1zcGVjaWZpYyBzdGF0ZW1lbnQuICBJIHRoaW5rIEkgdW5k
ZXJzdGFuZCB0aGF0IHNvIEknbGwgZWxhYm9yYXRlOg0KDQpJIGhhZCBhIG9uZS1pbnRlcmZhY2Ug
Vk0gYW5kIGFkZGVkIGFuIGludGVyZmFjZSB2aWEgdmlydC1tYW5hZ2VyICh3aGljaCwgdG8gbXkg
c3VycHJpc2UsIGF1dG8tbWFnaWNhbGx5IGFwcGVhcmVkIG9uIHRoZSBWTSB3aXRob3V0IHJlYm9v
dGluZykgLSBib3RoIGludGVyZmFjZXMgY29ubmVjdCB0byB0aGUgc2FtZSByb3V0ZXIvZmlyZXdh
bGwgKGRpZmZlcmVudCByb3V0ZXIgaW50ZXJmYWNlcywgb25lIHBlciBzdWJuZXQsIGNhbGwgb25l
IGEgMTAuIGFuZCB0aGUgb3RoZXIgYSAxNzIuIHN1Ym5ldCkgIFRoZSBvcmlnaW5hbCBWTSBpbnRl
cmZhY2Ugd2FzIG9uIHRoZSAxMC4gc3VibmV0LiAgV2hlbiBJIGFzc2lnbmVkIGEgMTcyLiBhZGRy
ZXNzIHRvIHRoZSBuZXcgaW50ZXJmYWNlIHByb2JsZW1zIG9jY3VycmVkLg0KDQpBIHN5c3RlbSBv
biB0aGUgMTcyIHN1Ym5ldCBjb3VsZG4ndCBwaW5nIHRoZSBWTSdzIDEwLiBzdWJuZXQgaW50ZXJm
YWNlIGJ1dCBhIHN5c3RlbSBvbiBhIDE5Mi4gc3VibmV0IGNvdWxkLiAgSSBiZWxpZXZlIHRoZSBy
ZWFzb24gaXMgLQ0KDQpXaGVuIEkgYWRkZWQgdGhlIDE3Mi4gSVAgYWRkcmVzcyBvbiB0aGUgVk0s
IGEgcm91dGUgdG8gdGhhdCBzdWJuZXQgb24gdGhhdCBpbnRlcmZhY2Ugd2l0aCB0aGF0IGFkZHJl
c3MgYXMgc291cmNlIHdhcyBhZGRlZCB0byB0aGUgcm91dGluZyB0YWJsZS4gIEFzIGEgcmVzdWx0
LCB3aGVuIGEgMTcyLiBhZGRyZXNzIHBpbmdlZCB0aGUgMTAuIGFkZHJlc3MgdGhlIHJlcXVlc3Qg
Y2FtZSBpbiBvbiB0aGUgMTAuIGludGVyZmFjZSBhbmQgdHJpZWQgdG8gZ28gb3V0IHRoZSAxNzIu
IGludGVyZmFjZS4NCg0KSG93ZXZlciwgdGhlcmUgd2FzIG5vIHJvdXRlIGVudHJ5IGZvciB0aGUg
MTkyLiBzdWJuZXQgc28sIHdoZW4gaXQgZGlkIGEgcGluZywgdGhlIHJlcXVlc3QgY2FtZSBpbiBv
biB0aGUgMTAuIGludGVyZmFjZSBhbmQgcmV0dXJuZWQgb24gdGhlIDEwLiBpbnRlcmZhY2UgYmVj
YXVzZSB0aGUgZGVmYXVsdCByb3V0ZSB3YXMgc2V0IGZvciB0aGF0IGludGVyZmFjZS4NCg0KSG9w
ZSB0aGlzIG1ha2VzIHNlbnNlLg0KDQpFYXJseQ0KQmlyZCBFeHRlbmRlZCEgU2F2ZSBub3cgdW50
aWwgSnVseSAyMCBvbiB0aGUgMjAxOCBNb21lbnR1bSBVc2VyDQpDb25mZXJlbmNlIQ0KUmVnaXN0
ZXINCmhlcmUNCkxlcm95IFRlbm5pc29uDQpOZXR3b3JrIEluZm9ybWF0aW9uL0N5YmVyIFNlY3Vy
aXR5IFNwZWNpYWxpc3QNCkU6IGxlcm95QGRhdGF2b2ljZWludC5jb20NCjIyMjAgQnVzaCBEcg0K
TWNLaW5uZXksIFRleGFzDQo3NTA3MA0Kd3d3LmRhdGF2b2ljZWludC5jb20NClRUaGlzIG1lc3Nh
Z2UgaGFzIGJlZW4gc2VudCBvbiBiZWhhbGYNCm9mIGEgY29tcGFueSB0aGF0IGlzIHBhcnQgb2Yg
dGhlIEhhcnJpcyBPcGVyYXRpbmcgR3JvdXAgb2YNCkNvbnN0ZWxsYXRpb24gU29mdHdhcmUgSW5j
LiBUaGVzZSBjb21wYW5pZXMgYXJlIGxpc3RlZA0KaGVyZQ0KLg0KSWYgeW91IHByZWZlciBub3Qg
dG8gYmUgY29udGFjdGVkIGJ5IEhhcnJpcw0KT3BlcmF0aW5nIEdyb3VwDQpwbGVhc2Ugbm90aWZ5
IHVzDQouDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIHRoZQ0KaW5k
aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBUaGlzIGNvbW11bmlj
YXRpb24NCm1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJvcHJpZXRhcnksIHByaXZp
bGVnZWQgb3INCmNvbmZpZGVudGlhbCBvciBvdGhlcndpc2UgbGVnYWxseSBleGVtcHQgZnJvbSBk
aXNjbG9zdXJlLiBJZiB5b3UgYXJlDQpub3QgdGhlIG5hbWVkIGFkZHJlc3NlZSwgeW91IGFyZSBu
b3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwNCnJldGFpbiwgY29weSBvciBkaXNzZW1pbmF0
ZSB0aGlzIG1lc3NhZ2Ugb3IgYW55IHBhcnQgb2YgaXQuIElmIHlvdQ0KaGF2ZSByZWNlaXZlZCB0
aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRl
bHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUNCm1lc3NhZ2UuDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGxhcnRjLW93bmVy
QHZnZXIua2VybmVsLm9yZyA8bGFydGMtb3duZXJAdmdlci5rZXJuZWwub3JnPiBvbiBiZWhhbGYg
b2YgSmF5IFZvc2J1cmdoIDxqYXkudm9zYnVyZ2hAY2Fub25pY2FsLmNvbT4NClNlbnQ6IEZyaWRh
eSwgSnVseSAxMywgMjAxOCAxMToyNiBBTQ0KVG86IEdyYW50IFRheWxvcg0KQ2M6IGxhcnRjQHZn
ZXIua2VybmVsLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogcnBfZmlsdGVyDQoNCkdyYW50
IFRheWxvciA8Z3RheWxvckB0bmV0Y29uc3VsdGluZy5uZXQ+IHdyb3RlOg0KDQo+T24gMDcvMTMv
MjAxOCAwOToyMyBBTSwgTGVyb3kgVGVubmlzb24gd3JvdGU6DQo+PiBJcyB0aGVyZSBhIGRlZmlu
aXRpdmUgd2F5IHRvIHRlbGwgdGhhdCBycF9maWx0ZXIgaXMgZHJvcHBpbmcgdHJhZmZpYyAoaW4N
Cj4+IHRoaXMgY2FzZSBlY2hvIHJlcXVlc3QpIG90aGVyIHRoYW4gZGlzYWJsaW5nIGl0IGFuZCBz
ZWVpbmcgdGhlIGV4cGVjdGVkDQo+PiB0cmFmZmljIChlY2hvIHJlcGx5KT8gIEkgdHJpZWQgYW4g
aXB0YWJsZXMgcGFja2V0IHRyYWNlIGJ1dCBJIGVpdGhlciBkaWQNCj4+IGl0IHdyb25nIG9yIGl0
IHNob3dlZCBub3RoaW5nLiAgVGhlIG9ubHkgaW5kaWNhdGlvbnMgSSBoYXZlIHJpZ2h0IG5vdw0K
Pj4gYXJlOg0KPg0KPkNoZWNrIGRtZXNnLiAgVGhhdCdzIHRoZSBtb3N0IHJlbGlhYmxlIHBsYWNl
IEkndmUgc2VlbiBmb3IgbG9ncyBhYm91dCAoc28NCj5jYWxsZWQpICJtYXJ0aWFuIiBwYWNrZXRz
Lg0KDQogICAgICAgIEkgYmVsaWV2ZSB0aGV5J3JlIGFsc28gY291bnRlZCBpbiB0aGUgImluX21h
cnRpYW5fc3JjIiBjb2x1bW4gb2YNCi9wcm9jL25ldC9zdGF0L3J0X2NhY2hlLg0KDQogICAgICAg
IC1KDQoNCj4+IE5vIGZpcmV3YWxsIHJ1bGVzIGJsb2NraW5nIHRyYWZmaWMgYnV0IG5vIHJlcGxp
ZXMgZWl0aGVyLg0KPg0KPkl0IHNlZW1zIGxpa2UgcmV2ZXJzZSBwYXRoIGZpbHRlcmluZyBvcGVy
YXRlcyBhdCBhIGxvd2VyIGxheWVyIGJlZm9yZQ0KPklQVGFibGVzLg0KPg0KPj4gVGhlIHByb2Js
ZW0gaXMgc3VibmV0LXNwZWNpZmljIChvbmx5IG9jY3VycyBvbiBhIGRpcmVjdGx5LWNvbm5lY3Rl
ZA0KPj4gc3VibmV0KS4NCj4NCj5PZGQuDQo+DQo+DQo+DQo+LS0NCj5HcmFudC4gLiAuIC4NCj51
bml4IHx8IGRpZQ0KDQotLS0NCiAgICAgICAgLUpheSBWb3NidXJnaCwgamF5LnZvc2J1cmdoQGNh
bm9uaWNhbC5jb20NCi0tDQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUg
bGluZSAidW5zdWJzY3JpYmUgbGFydGMiIGluDQp0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFq
b3Jkb21vQHZnZXIua2VybmVsLm9yZw0KTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3Zn
ZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo

Re: rp_filter

[Anton Danilov]

Hello.
This is the slowpoke post.

To check the rp filter you can use the ip route get command:
    ip route get <ds-tip> from <src-ip> iif <input-interface>

In the recent kernels you will see either valid route or 'invalid
cross-device link' error. In the older kernels you won't see a valid
route if the rp_filter prevents forwarding.

Also, use command 'nstat -z TcpExtIPReversePathFilter' to check the rp
filtered packet drops counter.

Notice, the max value from conf/{all,interface}/rp_filter is used when
doing source validation on the {interface}.
On Fri, 13 Jul 2018 at 18:42, Leroy Tennison <leroy@datavoiceint.com> wrote:
>
> Is there a definitive way to tell that rp_filter is dropping traffic (in this case echo request) other than disabling it and seeing the expected traffic (echo reply)?  I tried an iptables packet trace but I either did it wrong or it showed nothing.  The only indications I have right now are:
>
> No firewall rules blocking traffic but no replies either.
> The problem is subnet-specific (only occurs on a directly-connected subnet).
>
> Early
> Bird Extended! Save now until July 20 on the 2018 Momentum User
> Conference!
> Register
> here
> Leroy Tennison
> Network Information/Cyber Security Specialist
> E: leroy@datavoiceint.com
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com
> TThis message has been sent on behalf
> of a company that is part of the Harris Operating Group of
> Constellation Software Inc. These companies are listed
> here
> .
> If you prefer not to be contacted by Harris
> Operating Group
> please notify us
> .
> This message is intended exclusively for the
> individual or entity to which it is addressed. This communication
> may contain information that is proprietary, privileged or
> confidential or otherwise legally exempt from disclosure. If you are
> not the named addressee, you are not authorized to read, print,
> retain, copy or disseminate this message or any part of it. If you
> have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the
> message.
>


-- 
Anton.