Hi, > Really? I find this rather odd... since I worked around the problem > with pcap_lookupnet by calling PacketGetNetInfo instead. The odd thing, > is that all pcap_lookupnet does (on Win* I think - hard to work though > all those #if's) is call PacketGetNetInfo, and perform some network > class verification and then do the weird anding.
Yes, it does it on all the supported platforms. This the reason why I say it's the default behavior. Removing the and would be simple, but would broke compatibility with Unix. Loris > Thanks for the reply though - was starting to think noone even cared. > > -Antyrg > > Loris Degioanni wrote: > > I think this is the documented behavior. > > As the original manual page http://www.tcpdump.org/pcap3_man.html says, > > pcap_lookupnet() is used to determine the network number and mask > > associated with the network device. Future versions of winpcap will include > > the pcap_findalldevs() function that will provide comprehensive information > > about an adapter, including the IP address. WinPcap 2.3 however doesn't > > still support it. > > > > Loris > > > > ----- Original Message ----- > > From: "Antyrg" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, March 31, 2002 11:57 PM > > Subject: Re: [WinPcap-users] Determining IP address > > > > > > > >>It just hit me... why is the code anding the IP by the netmask before it > >>returns? That explains why it's not returning the proper IP... with a > >>netmask of 255.255.255.0, the and sets the last digit to 0. Is there a > >>reason for this? > >> > >>Antyrg wrote: > >> > >>>Anyone? I've looked through the source code, as well as examples, and > >>>I'm not seeing how to do this. The winpcap code seems to be calling the > >>>packet.dll, which scans through the registry to get it, and somewhere in > >>>there either it's messing up or I am, and I think it's more likely me. > >>> > >>>If I don't hear back soon, I'm going to have to duplicate the registry > >>>searching code and try to debug it, and I'd really rather someone tell > >>>me that I'm doing it wrong and need to make some odd call or math > >>>operation before trying to convert to human readable form (I've noticed > >>>the code has ip &= netmask, but it doesn't work wether I reverse this or > >>>not) > >>> > >>>-Antyrg > >>> > >>>Antyrg wrote: > >>> > >>> > >>>>Hi, > >>>> > >>>>Could someone give me an example of how to get and display the > >>>>selected network adapter's IP address? I have to be doing something > >>>>wrong somewhere... here's what I'm doing (psuedo-code) > >>>> > >>>> Options::device = AdapterDlg::GetAdapterName(); > >>>> int ret = pcap_lookupnet(Options::device, &(Options::ip), > >>>>&(Options::netmask), error); > >>>> > >>>>GetAdapterName returns a valid adapter (I'm able to capture packets > >>>>via the name it returns, if nothing else), and everything is the > >>>>appropriate type and seems like it wants to work, but the problem is > >>>>that both the netmask and ip returned are backwards and don't include > >>>>the last digit... if IP was 192.168.0.1, it returns 0.0.168.192 > >>>>(according to inet_ntoa) and I have to reverse it myself... but I must > >>>>be doing something wrong? It does this both on my LinkSys and RealTek > >>>>cards. > >>>> > >>>>I'm running XP Pro with the new 2.3 winpcap drivers (and not using > >>>>packet.dll at all). Any help would be appreciated. The good thing > >>>>though, the beta version was returning 0.0.0.0 for the realtek and I > >>>>don't remember what for the linksys. > >>>> > >>>>-Antyrg > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > >
