[Winpcap-users] can not get any captured package when

[Lin George]

Thanks Bryan,
Great reply.
1.
For the name resolve library, I have looked at getaddrinfo function,
http://msdn.microsoft.com/en-us/library/ms738520.aspx
just want to make a quite confirm with you since I am new to this function, you mean the 4th out parameter res will return a list of IP for the same name? Not necessary to be 3 always?
And it is client application (which utilizes getaddrinfo)'s responsibility to rotate to use the IP address list to make it better load balanced?
2.
> That also may explain why it never changes in your environment: Your DNS
> server isn't returning the expected data.  It's returning your proxy
> address (and it's probably returning that single address no matter what
> name you ask for).

I think in my network environment, it is the proxy which does the real DNS resolution work? Could we make such a conclusion now?
3.
The gethostbyname function is also valid on Windows, but when compared with getaddrinfo, gethostbyname could only return one IP address for a name, while getaddrinfo could return a list of IP address? I am new to this point, could you confirm please? :-)
4.
>From the study of your reply, I think even if we call getaddrinfo or gethostbyname, DNS server may or may not be used, because the two APIs may cache for values for some time? Correct?
If you have any further documents or sample codes which regarding to how the local name resolution library works and how they works with local DNS server, please refer some. :-)
have a good week,
George
----- Original Message ----
From: Bryan Kadzban <bryan at kadzban.is-a-geek.net>
To: Lin George <george4academic at yahoo.com>
Cc: winpcap-users at winpcap.org
Sent: Monday, August 11, 2008 10:56:27 PM
Subject: Re: [Winpcap-users] can not get any captured package when

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Lin George wrote:
> You mean ping does not have the responsibility and function to 
> resolve related IP address to name, and its function is just to send 
> ICMP to test connectivity?

Well, mostly.  Since you're giving ping a name and not an IP address, it
has to resolve that name to a (single) IP address.  But it uses the
resolver library to do that; it does not send or parse DNS packets on
its own.

> And since we send name other than IP to ping, and ping will first
> delegate the work of name resolution to name resolution library,

Yes.

> since ping only recognize IP address, other than name.

The ICMP echo-request packets that ping sends (and waits for a response
to) must be sent to an IP address.  (*All* packets must be sent to an IP
address, not a name.  Ping is no different from any other program.  They
all use a resolver of some sort to translate a name to an IP address.)

> You mentioned two terms in your reply, "The local name server" and 
> "local resolver library", my question is, does the local name server 
> you mean the one which is displayed as DNS when we type ipconfig 
> command?

Probably.  I'm not sure because it's been a while since I used Windows,
and I don't remember for sure what ipconfig shows.  But that sounds right.

> And what is "local resolver library"?

On Linux, it's the gethostbyname() or getaddrinfo() functions in the
name-resolution add-on to the C library.  On Windows, I don't know what
the function names are for sure, but getaddrinfo() might be available
from the Winsock DLL.

> Does "local resolver library" always use "the local name server" to
> resolve address?

Generally, yes.  But not necessarily always -- the interface to the
local resolver library is "get me the list of IP addresses for the name
xxxx.yyyy.zzzz", and you get a list of IP addresses back.  It might use
the hosts file, or it might use the local name server, or it might use a
hardcoded public name server.  (Though I doubt anything exists that uses
this last option.)

>> The local name server, whatever it is, is returning a semi-valid 
>> result for www.google.com, or at least that's what it looks like.
> 
> In my network environment, the result of ping www.google.com is the 
> same address of proxy server.

Um, whoa, that's wrong.  Well, it's probably what's expected by whoever
set up your network (and therefore not really "wrong"), but it looks
like they set it up strangely.

> Do you think it is what you called "semi-valid" result?

No.

> If not, what do you mean a "semi-valid" result (sorry my English is
> not very good)?

By semi-valid I meant something that looked like a public IP address
that Google probably owned.  If you're getting your proxy's IP address,
then it's not valid.  It does look like it's a public IP address, but it
looks like Google doesn't own it.

That also may explain why it never changes in your environment: Your DNS
server isn't returning the expected data.  It's returning your proxy
address (and it's probably returning that single address no matter what
name you ask for).

> you mean the local resolver library picks up or the ping utility
> picks up?

Well, not "picks up"; "picks" -- as in "chooses".  :-)  Let me explain:

As above, the interface to the resolver library is "give me the list of
IP addresses for the name xxxx.yyyy.zzzz".  The important part is that
it returns a list.  Most programs need a single address, so when they
get the list, they find the first address on the list and use it; they
ignore the rest of the list.

> And no matter how many real IP address does a web server have (e.g.
> www.google.com has a lot of IP address), but local resolver library
> only keeps 3 at most?

When the local resolver library is doing the work to translate the name
to the list of IP addresses, it (usually) asks the local name server
what the name server thinks the list should be.  This may end up
involving lots of requests to other name servers, etc., but eventually
the local name server will return some answer.  The answer will have a
list of IP addresses, and a time-to-live (how long the response may be
cached).

And this is not a guarantee, but the local resolver library *may* store
away this answer somewhere locally, for up to the time-to-live.  So if
the response TTL is, say, 3600 (units are seconds), then the local
library can store that answer away for up to an hour.  The advantage to
doing it this way is that if the same program (or another one) asks for
the same name again, then the local resolver library doesn't have to
send another request to the local name server.  The name resolution
process will operate faster if the request is satisfied locally, because
the network is slow.  (Well, it's fast, but its latency is higher than
getting the answer locally.  And if you have to ask a DNS server that
isn't on your local network, then it's always slow.)

- ----

In any case, if you capture all the traffic to and from your proxy, that
should work.  :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIoFMZS5vET1Wea5wRA+/bAJ9ybVv/gwoTvfIKpaCA0W5dtkdjDwCg18ln
X0DKZREIAOrfPSI4SM6PV6k=
=O7cP
-----END PGP SIGNATURE-----