On Tue, Jan 26, 2016 at 4:46 AM, Guy Harris <g...@alum.mit.edu> wrote:

> On Jan 24, 2016, at 7:47 PM, Yang Luo <hslu...@gmail.com> wrote:
>
> > My ubuntu 14.04 shows the lines below, so I think it doesn't support
> IFF_LOOPBACK.
> > root@ly-controller:~# ifconfig lo
> > lo        Link encap:Local Loopback
> >
> >           inet addr:127.0.0.1  Mask:255.0.0.0
> >           inet6 addr: ::1/128 Scope:Host
> >           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>               ^^^^^^^^^
> >           RX packets:10580846 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:10580846 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:0
> >           RX bytes:2877631654 (2.8 GB)  TX bytes:2877631654 (2.8 GB)
>
> No, it *does* support it.
>
> > However Windows supports it.
>
> Yes, there's an IFF_LOOPBACK flag in Winsock:
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms738568(v=vs.85).aspx
>
> But is it actually set for any interface, or is it just provided for
> source compatibility with various UN*Xes?


I think maybe IFF_LOOPBACK in Windows means the Windows-way loopback, like
"Windows Loopback Adapter". So the same definition, not the same meaning
with lo.


>


> > <image.png>
> >
> > I have analyzed the code related to me. Currently my code is in
> inet.c----add_or_find_if. It has curdev->flags and this must be set. What
> pcap-win32.c has is pcap_create and pcap_activate_win32, called by
> pcap_open_live which is called by add_or_find_if. If I make the change in
> pcap-win32.c, the code would be very ugly.
>
> In the current version of the code on the trunk, which I just checked in,
> add_or_find_if() takes PCAP_IF_ flags, rather than IFF_ flags, as arguments.
>

I saw your commit. add_or_find_if() has been moved to fad-helpers.c and
flags is PCAP_IF_ type.


>
> In pcap_add_if_win32(), check whether the interface is a loopback
> interface and, if it is, pass PCAP_IF_LOOPBACK to add_or_find_if(),
> otherwise pass 0.
>

I think calling PacketIsLoopbackAdapter requires the adapter to be opened
first (like calling PacketOpenAdapter in pcap_open_live call). But before
calling add_or_find_if() the adapter is not ever opened. I don't think it's
good to open it twice. Also the function name add_or_find_if() suggests
that the "if" can be found if it's already in the list, no opening in this
condition. So I don't feel good to open it in another place.

The solution:

I think I will just move the registry code from packet.dll to libpcap's
fad-win32.c's pcap_add_if_win32() as you said, so no need to call
PacketIsLoopbackAdapter and no need to open the adapter, and no need to
dynamically load PacketIsLoopbackAdapter using LoadLibrary and
GetProcAddress APIs.

BTW, before I do this, I think I need to have a workable build of libpcap
on Windows.



>
> (There appear to be OIDs that will determine whether the interface is
> "working" or not, but 1) they appear to be different in NDIS 5 and NDIS 6
> and 2) they don't separate "up" and "running", so you could only use them
> to determine whether to pass PCAP_IF_UP|PCAP_IF_RUNNING, possibly combined
> with PCAP_IF_LOOPBACK, or just 0, possibly combined with PCAP_IF_LOOPBACK.)
>
> > Maybe I should just put my code in inet.c and wrap it with #ifdef WIN32
> macro?
>
> No - see above.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to