You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Stephen Love <st...@juno.com> on 2009/11/10 14:19:45 UTC
[users@httpd]
I have set up a routine in my server that logs all incoming IP addresses and parses for duplicates in the same list. HOWEVER...a person posting almost NEVER has the same address. I believe I am not using the actual IP Address at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!) of the HARDWARE (Network Adapter) actually sending the message, or its REPLY TO address... the address it is COMMUNICATING FROM in order to actually send the message. I am SURE if it is to establish a 2-way link to send and confirm the message, the receiving end HAS that info, buried deep within what it receives. HOW can I get that, so that the route steps inbetween do not matter?
See us online at http://www.LOVEnCompany.com.
____________________________________________________________
Weight Loss Program
Best Weight Loss Program - Click Here!
http://thirdpartyoffers.juno.com/TGL2131/c?cp=Ntt5TC2wqavlm6Ic43CARgAAJz1cSR5zxtI8-KAHzBSY23cQAAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAAEUgAAAAA=
Re: [users@httpd]
Posted by Rich Bowen <rb...@rcbowen.com>.
On Nov 10, 2009, at 08:19 , Stephen Love wrote:
> I have set up a routine in my server that logs all incoming IP
> addresses and parses for duplicates in the same list. HOWEVER...a
> person posting almost NEVER has the same address. I believe I am not
> using the actual IP Address at all. What I WANT is the actual SERIAL
> NUMBER (If you could call it that!) of the HARDWARE (Network
> Adapter) actually sending the message, or its REPLY TO address...
> the address it is COMMUNICATING FROM in order to actually send the
> message. I am SURE if it is to establish a 2-way link to send and
> confirm the message, the receiving end HAS that info, buried deep
> within what it receives. HOW can I get that, so that the route steps
> inbetween do not matter?
>
No, you can't. It's impossible. That information (the MAC address)
doesn't make it past the first hop, and there's numerous pieces of
hardware (routers, firewalls, proxy servers, etc) between client and
server. The receiving end does NOT have that info, buried or
otherwise. It's simply not there.
--
Rich Bowen
rbowen@rcbowen.com
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd]
Posted by LuKreme <kr...@kreme.com>.
On 10-Nov-2009, at 13:49, André Warnier wrote:
> And I would add that, from a user point of view, I would be very reluctant to help at any system that would let me be identified in any way other than me voluntarily and knowingly providing my id by means of some obvious login page or certificate, and then only to some party I trust not to disseminate that information outside of my control.
> And enough recent cases have shown that such trustable parties are not very thick on the ground.
Heck, I don't even trust MYSELF that much.
--
'They say that whoever pays the piper calls the tune.'
'But, gentlemen,' said Mr Saveloy, 'whoever holds a knife to the piper's throat writes the symphony.' --Interesting Times
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd]
Posted by André Warnier <aw...@ice-sa.com>.
Mark H. Wood wrote:
...
>
> It's thus very unlikely that you will get any help from hardware
> manufacturers in identifying remote users or hosts in the manner you
> specified. You'll need cooperation from your users.
>
And I would add that, from a user point of view, I would be very
reluctant to help at any system that would let me be identified in any
way other than me voluntarily and knowingly providing my id by means of
some obvious login page or certificate, and then only to some party I
trust not to disseminate that information outside of my control.
And enough recent cases have shown that such trustable parties are not
very thick on the ground.
So independently of the technical issues, you are up against some
guaranteed and well-founded resistance.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd]
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, Nov 10, 2009 at 10:52:18AM -0500, Brian Mearns wrote:
> As Eric says, what you're looking for is a MAC address which is a
> universally unique identifier that every network device has (though I
> think even here, "universally unique" might have some qualifying
> conditions).
Yes. Occasionally a manufacturer goofs and issues more than one part
with the same MAC address burned in. We received two desktop boxes
with the same MAC address once. Imagine how often it happens and
isn't caught, because they went to two different customers. :-(
Also, the IEEE 802 standards define Locally Administered Addresses.
Essentially you can tell most Ethernet adaptors to use any MAC address
you please, so long as a particular bit is on.*
A further complication is that at any time, someone could have a NIC
fail, replace it, and wind up using a different MAC address from then
on. Is that one user, or two? You don't know.
> MAC addresses are used in very low level protocols (link
> layer protocols, I believe) to send packets to specific devices. MAC
> addresses are for point-to-point communications, not end-to-end.
To make this plainer: the first router on the path from user X to you
will discard this information. As far as the protocol stack is
concerned, it has no useful meaning beyond that point.
It's thus very unlikely that you will get any help from hardware
manufacturers in identifying remote users or hosts in the manner you
specified. You'll need cooperation from your users.
-----------------
* DECnet Phase IV used this to encode the network-layer address in
the link-layer address, so the same NIC would have two different
MAC addresses depending on whether DECnet had been started. And
the LAA would change if you ever changed the network-layer
address. What fun.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Friends don't let friends publish revisable-form documents.
Re: [users@httpd]
Posted by Brian Mearns <me...@gmail.com>.
On Tue, Nov 10, 2009 at 8:28 AM, Eric Covener <co...@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <st...@juno.com> wrote:
>> I have set up a routine in my server that logs all incoming IP addresses and
>> parses for duplicates in the same list. HOWEVER...a person posting almost
>> NEVER has the same address. I believe I am not using the actual IP Address
>> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!)
>> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY
>> TO address... the address it is COMMUNICATING FROM in order to actually send
>> the message. I am SURE if it is to establish a 2-way link to send and
>> confirm the message, the receiving end HAS that info, buried deep within
>> what it receives. HOW can I get that, so that the route steps inbetween do
>> not matter?
>
> You don't have access to their MAC address or any other universal
> identifier, no matter how much you use the shift key.
>
> --
> Eric Covener
> covener@gmail.com
>
[clip]
As Eric says, what you're looking for is a MAC address which is a
universally unique identifier that every network device has (though I
think even here, "universally unique" might have some qualifying
conditions). MAC addresses are used in very low level protocols (link
layer protocols, I believe) to send packets to specific devices. MAC
addresses are for point-to-point communications, not end-to-end. You
could set up a packet sniffer, like Wireshark, and capture the source
MAC addresses of incoming packets, but that would probably just give
you the MAC address of your router or modem.
As you've discovered, IP addresses are not valid ways to identify end
users. Most residential internet access is done through a dynamic IP
address, meaning their ISP can change their IP address whenever it
wants. Further, a lot of people access the web through proxy servers,
so that a large number of end users are seen as the same IP address,
and others access through proxy pools or networks like Tor so that the
same person may have a different IP address for every request they
make.
It sounds like what you're looking for is a way to track your
visitors. Google Analytics is a pretty good free service for doing
exactly that, or you can set up your own similar system. The way these
things work is by using cookies to track individual browsers. But of
course, a lot of people don't use cookies. Further, if you're worried
about active menace, cookies are terribly insecure unless you're using
secure connections (and even then through various types of attack), so
a malicious user could snoop other people's cookies and submit it with
their own request, making it look like the request came from the other
user.
If you want to do more strict tracking, something along the lines of
"sorry, you already voted, and you can only vote once.", you'll need
to get much more sophisticated. Some sort of user-authentication
(i.e., "log in") is a must for this, and you'll need to be very
careful about people snooping cookies and log-in date (like, only use
secure HTTPS connections).
-Brian
--
Feel free to contact me using PGP Encryption:
Key Id: 0x3AA70848
Available from: http://keys.gnupg.net
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd]
Posted by Eric Covener <co...@gmail.com>.
On Tue, Nov 10, 2009 at 8:19 AM, Stephen Love <st...@juno.com> wrote:
> I have set up a routine in my server that logs all incoming IP addresses and
> parses for duplicates in the same list. HOWEVER...a person posting almost
> NEVER has the same address. I believe I am not using the actual IP Address
> at all. What I WANT is the actual SERIAL NUMBER (If you could call it that!)
> of the HARDWARE (Network Adapter) actually sending the message, or its REPLY
> TO address... the address it is COMMUNICATING FROM in order to actually send
> the message. I am SURE if it is to establish a 2-way link to send and
> confirm the message, the receiving end HAS that info, buried deep within
> what it receives. HOW can I get that, so that the route steps inbetween do
> not matter?
You don't have access to their MAC address or any other universal
identifier, no matter how much you use the shift key.
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org