wtfbbqhax / libdnet Goto Github PK

View Code? Open in Web Editor NEW

1.0 1.0 0.0 1.61 MB

Automatically exported from code.google.com/p/libdnet (unoficial mirror)

License: Other

C 72.48% Shell 21.58% Python 5.94%

libdnet's People

Stargazers

Watchers

libdnet's Issues

[PATCH] ifconf traversal failure (e.g. intf_loop() fails)

What steps will reproduce the problem?
1. Run "test/dnet/dnet intf show"


What is the expected output? What do you see instead?

The expected output is shown later on (using my patch).  I currently get this 
instead:

fwip0: flags=0x30<BROADCAST,MULTICAST> mtu 1500
dnet: intf_loop: Device not configured


What version of the product are you using? On what operating system?

SVN checkout (but most likely present for some time).  I'm running NetBSD 
-current (5.99.39).


Please provide any additional information below.

I've attached a patch for fix this by correcting the NEXTIFR() macro in intf.c. 
 NetBSD put a sockaddr_storage in the ifreq ifr_ifru union, so using 
sizeof(i->ifr_addr) won't work (it's still sockaddr), but for other systems 
using only sockaddrs, sizeof(ifr_addr) should always equal sizeof(ifr_ifru) 
anyway.

Oh, I didn't notice any max() or MAX() defined or used in libdnet, but the 
patch could be use it if available.  I just didn't see any sense adding it for 
only this, though.

fwip0: flags=0x30<BROADCAST,MULTICAST> mtu 1500
vr0: flags=0x30<BROADCAST,MULTICAST> mtu 1500
        link 00:11:d8:42:94:29
        alias fe80:2::211:d8ff:fe42:9429/64
lo0: flags=0x23<UP,LOOPBACK,MULTICAST> mtu 33192
        inet 127.0.0.1/8
        alias ::1
        alias fe80:3::1/64
ppp0: flags=0x25<UP,POINTOPOINT,MULTICAST> mtu 1500
        inet 192.168.1.2/24 --> 192.168.1.1
        alias fe80:4::2e0:1800:ca:ee7a/64

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 5:38

Attachments:

ifconf.patch

ip_cksum_add bug in dnet.pyx

What steps will reproduce the problem?

libdnet-1.12 uses a deprecated function prototype of PyObject_AsReadBuffer, 
causing an overflow on 64-bit builds. Calling dnet.ip_cksum_add(buf, x) (with 
non-zero x) will cause ip_cksum_add in ip-util.c to get cksum = 0. 

An example of this bug breaking something can be found in 
dpkt/ip.py::IP:__str__ :
                s = dpkt.in_cksum_add(0, s)
                s = dpkt.in_cksum_add(s, p)

(where dpkt.in_cksum_add is aliased to dnet.ip_cksum_add in dpkt.py)

This bug causes dpkt to insert incorrect checksums for UDP/TCP packets, as the 
first result from ip_cksum_add is essentially ignored.

What is the expected output? What do you see instead?

I expect cksum to be maintained between the python-c call, instead of getting 
overwritten as 0.

What version of the product are you using? On what operating system?

dnet-1.12, ubuntu 10.10.

Please provide any additional information below.

I've provided a patch to libdnet-1.12/python/dnet.pyx that fixes this problem. 
The solution is to use Py_ssize_t instead of int. (this patch also includes 
modifications to allow dnet.pyx to build under the version of pyrexc I pulled 
out of the Ubuntu repository (pyrexc 0.9.8.5))

Original issue reported on code.google.com by [email protected] on 31 Dec 2011 at 7:38

Attachments:

dnet.pyx.diff

route_get hangs on ipv6 / mac os x

This is on Mac OS X 10.6

/*
 * function: find_default_route_entry input: none output: addr (libdnet)
 * structure with the default route address
 */
struct addr    *
find_default_route_entry()
{
        route_t        *r = NULL;
        struct route_entry *e = NULL;
        int             i = 0;

        if ((e = malloc(sizeof(struct route_entry))) == NULL)
                crapout("malloc: failed to allocate route_entry for find_default_route");


        memset((void *) e, 0, sizeof(struct route_entry));
        if ((i = addr_pton("::", &((*e).route_dst))) < 0)
                crapout("dnet: Failed to addr_pton");

        if ((r = route_open()) == NULL)
                crapout("dnet: Failed to route_open");

        if ((i = route_get(r, e)) < 0)
                crapout("dnet: Failed to route_get");

        route_close(r);

        dprintf("default gateway addr: %s\n", addr_ntoa(&((*e).route_gw)));

        return &((*e).route_gw);

}


Expected output: interface for default route on IPv6.
dnet 1.12
OS X 10.6.7

Original issue reported on code.google.com by jfesler on 23 Mar 2011 at 10:00

OSError: Result too large

What steps will reproduce the problem?

>>> import dnet
>>> dnet.eth("eth0")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dnet.pyx", line 112, in dnet.eth.__init__
OSError: Result too large
>>> dnet.eth("eth7")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dnet.pyx", line 112, in dnet.eth.__init__
OSError: Result too large
>>> dnet.eth(None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "dnet.pyx", line 110, in dnet.eth.__init__
TypeError: expected string or Unicode object, NoneType found


What is the expected output? What do you see instead?

there is no way to specify that we want the type=6 (ethernet) interface. The 
dnet.eth() method and the underlying eth_open() C function only take 
the plain interface name as arguments.

What version of the product are you using? On what operating system?
Python 2.6.3
dnet 1.12 win32
Windows 7 / Vista

Please provide any additional information below.

>>> import dnet
>>> for iface in dnet.intf(): print iface
...

{'flags': 32, 'type': 1, 'name': 'eth0', 'mtu': 0L}
...
{'flags': 33, 'link_addr': 0a:aa:20:52:41:53, 'type': 6, 'name': 'eth0', 'mtu': 
1500L}
...
{'addr': 192.168.1.99/24, 'mtu': 1500L, 'flags': 33, 'link_addr': 
00:1f:3c:34:1c:0c, 'type': 71, 'name': 'eth0'}
...

Original issue reported on code.google.com by [email protected] on 31 Jan 2010 at 12:14

No route detected for IPv6 packets in conjunction with scapy.

Hello. 

I am currently using scapy with libdnet in order to send an IPv6 Packet to a  
random location. Problem is the packets are supposed to leave the machine but 
wireshark captures no packets leaving the pc. 

On closer inspection i realised that conf.route6 from scapy is empty. Then i 
tried to get all the interfaces from my device. Here is what i got back: 

{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth0', 'mtu': 
1500L}
{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth1', 'mtu': 
1500L}
{'flags': 33, 'link_addr': 00:50:56:a0:1e:df, 'type': 6, 'name': 'eth2', 'mtu': 
1500L}
{'flags': 33, 'link_addr': 00:50:56:a0:1e:df, 'type': 6, 'name': 'eth3', 'mtu': 
1500L}
{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth4', 'mtu': 
1500L}
{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth5', 'mtu': 
1500L}
{'flags': 32, 'link_addr': 00:50:56:a0:00:6c, 'type': 6, 'name': 'eth6', 'mtu': 
0L}
{'flags': 32, 'link_addr': 00:50:56:a0:01:0e, 'type': 6, 'name': 'eth7', 'mtu': 
0L}
{'flags': 32, 'link_addr': 00:50:56:a0:6e:61, 'type': 6, 'name': 'eth8', 'mtu': 
0L}
{'addr': 152.78.61.39/24, 'mtu': 1500L, 'flags': 33, 'link_addr': 
00:50:56:a0:1e:df, 'type': 6, 'name': 'eth9'}
{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth10', 
'mtu': 1500L}
{'flags': 33, 'link_addr': b0:90:20:52:41:53, 'type': 6, 'name': 'eth11', 
'mtu': 1500L}
{'flags': 33, 'type': 23, 'name': 'ppp0', 'mtu': 1494L}
{'flags': 33, 'link_addr': 20:41:53:59:4e:ff, 'type': 23, 'name': 'ppp1', 
'mtu': 3256L}
{'addr': 127.0.0.1/8, 'flags': 3, 'type': 24, 'name': 'lo0', 'mtu': 1500L}
{'flags': 33, 'type': 131, 'name': 'tun0', 'mtu': 4091L}
{'flags': 32, 'type': 131, 'name': 'tun1', 'mtu': 1480L}
{'flags': 33, 'type': 131, 'name': 'tun2', 'mtu': 1460L}
{'flags': 33, 'type': 131, 'name': 'tun3', 'mtu': 1464L}
{'flags': 32, 'type': 131, 'name': 'tun4', 'mtu': 1280L}
{'flags': 32, 'type': 131, 'name': 'tun5', 'mtu': 1280L}
{'flags': 33, 'type': 131, 'name': 'tun6', 'mtu': 1472L}
{'flags': 32, 'type': 131, 'name': 'tun7', 'mtu': 1280L}

As you can see, nowhere in there there is an ipv6 address. How am i supposed to 
send ipv6 packets if no ipv6 address is listed? in extend, here is the ipconfig 
from cmd:

Ethernet adapter Local Area Connection 4:

   Connection-specific DNS Suffix  . : ecs.soton.ac.uk
   Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-50-56-A0-1E-DF
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:630:d0:f105:5cfe:e988:421a:a7b7(
erred)
   Temporary IPv6 Address. . . . . . : 2001:630:d0:f105:e8bc:7c26:9a40:31b8(
erred)
   Link-local IPv6 Address . . . . . : fe80::5cfe:e988:421a:a7b7%17(Preferre
   IPv4 Address. . . . . . . . . . . : 152.78.61.39(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 July 2013 03:16:17
   Lease Expires . . . . . . . . . . : 13 August 2013 09:17:16
   Default Gateway . . . . . . . . . : fe80::210:18ff:fee5:5bfa%17
                                       152.78.61.254
   DHCP Server . . . . . . . . . . . : 152.78.61.2
   DNS Servers . . . . . . . . . . . : 152.78.68.1
                                       152.78.70.1
   NetBIOS over Tcpip. . . . . . . . : Enabled

This is run on a VM but i dont think it matters. 
PLEASE someone help me this is very important! how can i configure scapy in 
order to understand how to send ipv6 packets. and why do i see no ipv6 
addresses in the list above?

Original issue reported on code.google.com by [email protected] on 12 Aug 2013 at 10:23

Strange libraries when building on RHEL4 R8 2.6.32-71.18.1.el6.x86_64

What steps will reproduce the problem?
1. ./configure --prefix=/usr/local/libdnet-1.12
2. make && make install


What is the expected output? What do you see instead?

EXPECTED:
ls -l /usr/local/libdnet-1.12/lib
-rw-r--r-- 1 cmgreen cmgreen 272390 Mar  3 08:50 libdnet.a
-rwxr-xr-x 1 cmgreen cmgreen    933 Mar  3 08:50 libdnet.la
lrwxrwxrwx 1 cmgreen cmgreen     16 Mar  3 08:50 libdnet.so -> libdnet.so.1.0.1
lrwxrwxrwx 1 cmgreen cmgreen     16 Mar  3 08:50 libdnet.so.1 -> 
libdnet.so.1.0.1
-rwxr-xr-x 1 cmgreen cmgreen 160580 Mar  3 08:50 libdnet.so.1.0.1

ACTUAL:
lrwxrwxrwx 1 cmgreen cmgreen     13 Mar  3 09:08 libdnet -> libdnet.1.0.1
lrwxrwxrwx 1 cmgreen cmgreen     13 Mar  3 09:08 libdnet.1 -> libdnet.1.0.1
-rwxr-xr-x 1 cmgreen cmgreen 160604 Mar  3 09:08 libdnet.1.0.1
-rw-r--r-- 1 cmgreen cmgreen 272414 Mar  3 09:08 libdnet.a
-rwxr-xr-x 1 cmgreen cmgreen    791 Mar  3 09:08 libdnet.la


What version of the product are you using? On what operating system?

Red Hat Enterprise Linux Server release 6.0 (Santiago) x64

Please provide any additional information below.

This issue really confuses the libtool when building snort-2.9.0.4 with ipv6 
support.  Currently using:

  libtool-2.2.6-15.5.el6.x86_64
  autoconf-2.63-5.1.el6.noarch
  automake-1.11.1-1.2.el6.noarch

Problem resolved by:

libtoolize --automake --copy"
aclocal -I config"
autoheader
automake --add-missing --copy
autoconf

It would be appreciated to cut a new .tar.gz release with updated auto* to 
prevent others from hitting this same issue.

Original issue reported on code.google.com by [email protected] on 3 Mar 2011 at 3:13

Can not import dnet

What steps will reproduce the problem?
1. import dnet
2.
3.

What is the expected output? What do you see instead?
Expect Nothing, but

Traceback (most recent call last):
  File "./test.py", line 6, in 
    import dnet
ImportError: dlopen(/Library/Python/2.5/site-packages/dnet.so, 2): 
Symbol not found: _addr_bcast
  Referenced from: /Library/Python/2.5/site-packages/dnet.so
  Expected in: dynamic lookup

What version of the product are you using? On what operating system?
1.12 On OS X 10.6

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 3 Aug 2010 at 12:01

Merged into: #9

Bad ip packets sent in tunnel linux 2.6 (x86 and x86_64)

What steps will reproduce the problem?
option a:
1. Compile the library
2. Make any application that sends ip packets
3. start application
4. Read packets via tcpdump
option b:
1. Compile the library
2. Make a simple icmp echo application
3. start ping on the virtual tunnel interface.
4. observe that the kernel does not understand the icmp replies

What is the expected output? What do you see instead?
The level2 ethernet type is 0x0000 when it should be 0x0800

What version of the product are you using? On what operating system?
With 1.11 , RHEL4 (x86, kernel 2.6.24.2, gcc 3.4.6), RHEL5 (x86 and x86_64,
default kernel(2.6.18-53), gcc 4.1.2)


Please provide any additional information below.
The fix, at least on intel cpu for recent 2.6 kernels is a htonl and a
change in the way the size of a parameter is calculated.
I have not verified this patch on earlier kernels or 2.4 branch kernels

Original issue reported on code.google.com by [email protected] on 28 Mar 2008 at 6:28

Attachments:

tun-linux.c.patch

[Python module] Multiple definitions

What steps will reproduce the problem?
1. Compile python module under windows

What is the expected output?
Module compiles cleanly.

What do you see instead?
Multiple definitions of some symbols.

What version of the product are you using?
1.12. 

On what operating system?
Win32

Please provide any additional information below.

These files are listed twice in setup.py:

'../src/err.c'
'../src/strlcat.c'
'../src/strlcpy.c'

Original issue reported on code.google.com by [email protected] on 24 Aug 2009 at 6:12

bond0 cause [ warning] [guestinfo] Failed to get nic info.


What is the expected output? What do you see instead?
log says: vmsvc ... [ warning] [guestinfo] Failed to get nic info.

What version of the product are you using? On what operating system?
open-vm-tools, linux

Please provide any additional information below.

it looks like bond is not supported by libdnet

for every 30 secods, i get "[ warning] [guestinfo] Failed to get nic info" in 
logging
after some digging and i found that it's caused by bond0 device, libdnet failed 
to handle the bond device case
(gdb) p ifr
$35 = {ifr_ifrn = {ifrn_name = 
"bond0\000\000\000\020\000\000\000\000\000\000"}, ifr_ifru = {ifru_addr = 
{sa_family = 65534, sa_data = '\000' },
ifru_dstaddr = {sa_family = 65534, sa_data = '\000' }, ifru_broadaddr = 
{sa_family = 65534, sa_data = '\000' }, ifru_netmask = {
sa_family = 65534, sa_data = '\000' }, ifru_hwaddr = {sa_family = 65534, 
sa_data = '\000' }, ifru_flags = -2, ifru_ivalue = 65534,
ifru_mtu = 65534, ifru_map = {mem_start = 65534, mem_end = 0, base_addr = 0, 
irq = 0 '\000', dma = 0 '\000', port = 0 '\000'},
ifru_slave = "\376\377", '\000' , ifru_newname = "\376\377", '\000' , ifru_data 
= 0xfffe
}}
(gdb) p entry[0]
$37 = {intf_len = 8192, intf_name = 
"bond0\000\000\000\000\000\000\000\000\000\000", intf_type = 6, intf_flags = 
49, intf_mtu = 1500, intf_addr = {addr_type = 2,
addr_bits = 15, addr_u = {eth = {data = "\300\250\b\001\000"}, ip = 17344704, 
ip6 = {data = "\300\250\b\001", '\000' },
data8 = "\300\250\b\001", '\000' , data16 = {43200, 264, 0, 0, 0, 0, 0, 0}, 
data32 = {17344704, 0, 0, 0}}}, intf_dst_addr = {addr_type = 0,
addr_bits = 0, addr_u = {eth = {data = "\000\000\000\000\000"}, ip = 0, ip6 = 
{data = '\000' }, data8 = '\000' , data16 = {
0, 0, 0, 0, 0, 0, 0, 0}, data32 = {0, 0, 0, 0}}}, intf_link_addr = {addr_type = 
0, addr_bits = 0, addr_u = {eth = {data = "\000\000\000\000\000"}, ip = 0,

ip6 = {data = '\000' }, data8 = '\000' , data16 = {0, 0, 0, 0, 0, 0, 0, 0}, 
__data32 = {0, 0, 0, 0}}}, intf_alias_num = 0,
intf_alias_addrs = 0x7ffffbd942ac}
(gdb) bt
0 addr_ston (sa=0x7ffffbd94200, a=0x7ffffbd94294) at addr.c:337
1 0x00007fc74edc0c03 in _intf_get_noalias (intf=0x641670, entry=0x7ffffbd94250) 
at intf.c:430
2 0x00007fc74edc15f5 in intf_loop (intf=0x641670, callback=0x7fc74f1f66bf , 
arg=0x63ef30) at intf.c:709
3 0x00007fc74f1f65b7 in GuestInfoGetNicInfo (nicInfo=0x63ef30) at 
guestInfoPosix.c:180
4 0x00007fc74f1f5c84 in GuestInfo_GetNicInfo (nicInfo=0x7ffffbd98368) at 
guestInfo.c:107
5 0x00007fc74f1f31e2 in GuestInfoGather (data=0x60b560 , data@entry=) at 
guestInfoServer.c:305
6 0x00007fc7535c02ab in g_timeout_dispatch (source=source@entry=0x63c300, 
callback=, user_data=)
at /var/tmp/portage/dev-libs/glib-2.38.2-r1/work/glib-2.38.2/glib/gmain.c:4451
7 0x00007fc7535bf496 in g_main_dispatch (context=0x61c320) at 
/var/tmp/portage/dev-libs/glib-2.38.2-r1/work/glib-2.38.2/glib/gmain.c:3066
8 g_main_context_dispatch (context=context@entry=0x61c320) at 
/var/tmp/portage/dev-libs/glib-2.38.2-r1/work/glib-2.38.2/glib/gmain.c:3642
9 0x00007fc7535bf8a8 in g_main_context_iterate (context=0x61c320, 
block=block@entry=1, dispatch=dispatch@entry=1, self=)
at /var/tmp/portage/dev-libs/glib-2.38.2-r1/work/glib-2.38.2/glib/gmain.c:3713
10 0x00007fc7535bfd99 in g_main_loop_run (loop=0x6169d0) at 
/var/tmp/portage/dev-libs/glib-2.38.2-r1/work/glib-2.38.2/glib/gmain.c:3907
11 0x0000000000404caa in ToolsCoreRunLoop (state=0x60b500 ) at mainLoop.c:238
12 0x000000000040516c in ToolsCore_Run (state=0x60b500 ) at mainLoop.c:446
13 0x00000000004057ca in main (argc=1, argv=0x6169b0, envp=0x7ffffbd98778) at 
mainPosix.c:283
(gdb) p sa->sa_family
$38 = 65534
it goes to default case
(gdb) fr
0 addr_ston (sa=0x7ffffbd94200, a=0x7ffffbd94294) at addr.c:337
337 return (-1);
(gdb) l
332 a->addr_bits = IP_ADDR_BITS;
333 a->addr_ip = so->sin.sin_addr.s_addr;
334 break;
335 default:
336 errno = EINVAL;
337 return (-1); <- here
338 }
339 return (0);
340 }
341
returning all the way up to
304 / Get NIC information. /
305 if (!GuestInfo_GetNicInfo(&nicInfo)) {
306 g_warning("Failed to get nic info.\n");

Original issue reported on code.google.com by [email protected] on 9 May 2014 at 6:08

building python interface failed on OS X (python 2.6): dnet.c problems

What steps will reproduce the problem?
1. python setup.py build

After building libdnet from svn (subsequent to 1.12)

building the python interface starts with:

creating build/temp.macosx-10.6-universal-2.6
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall 
-Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe 
-I../include 
-I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c 
./dnet.c -o build/temp.macosx-10.6-universal-2.6/./dnet.o
./dnet.c:62: warning: this decimal constant is unsigned only in ISO C90
./dnet.c: In function ‘__pyx_f_4dnet___oserror’:
./dnet.c:447: warning: function declaration isn’t a prototype
./dnet.c: In function ‘__pyx_f_4dnet_3eth_get’:
./dnet.c:581: warning: pointer targets in passing argument 1 of 
‘PyString_FromStringAndSize’ differ in signedness

and dnet.c just doesn't build.  I am seeing an -arch ppc  which seems 
suspicious.

Original issue reported on code.google.com by [email protected] on 2 Aug 2011 at 8:51

intf_get can write past the end of the provided buffer.

call intf_get() with a large enough intf_entry buffer to hold all the IPv4 
addresses but not enough room for the IPv6 addresses.

What steps will reproduce the problem?
1. The default BUFSIZ buffer in the test code is 8192, the easiest thing it 
probably to shrink this.
2. Add Enough IPv4 addresses to an interface so that when you run ./dnet intf 
get <intf> The buffer will be almost full but not quite (< sizeof(struct addr) 
left)
3. Add one or more IPv6 addresses to the same interface
4. re-run dnet intf get <intf>

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
libdent-1.11, Linux 2.6.29-gentoo-r5 i686

Please provide any additional information below.
I believe this patch will fix the issue. This is how the IPv4 loop, in the same 
function, makes sure it does not walk off the end of the buffer also.

Index: src/intf.c
===================================================================
--- src/intf.c  (revision 12767)
+++ src/intf.c  (working copy)
@@ -531,7 +531,7 @@
        u_int idx, bits, scope, flags;

        if ((f = fopen(PROC_INET6_FILE, "r")) != NULL) {
-           while (ap < lap &&
+           while ((ap + 1) < lap &&
                   fgets(buf, sizeof(buf), f) != NULL) {
                sscanf(buf, "%04s%04s%04s%04s%04s%04s%04s%04s %02x %02x %02x %02x %32s\n",
                    s[0], s[1], s[2], s[3], s[4], s[5], s[6], s[7],

Original issue reported on code.google.com by [email protected] on 7 Oct 2010 at 9:28

setup.py.in issues

The python/setup.py.in section for 'win32' has some issues:
1) strlcat.c and strlcpy.c are listed twice.

2) the "winpcap_dir = '../../WPdpack'" doesn't seems kosher.
  Why can't setup.py.in look in $INCLUDE and $LIB for WinPcap
  headers and packet.lib?

Original issue reported on code.google.com by [email protected] on 24 Jan 2013 at 3:13

Unable to install on Solaris 11

What steps will reproduce the problem?
1. Install Solaris 11
2. run configure and make
3. Error message generated from makefile

What is the expected output? What do you see instead?
libndet installed. Makefile fails instead with the following:

oot@sun-11:~/Downloads/libdnet-1.12# make
Making all in include
make  all-recursive
Making all in dnet
Making all in man
Making all in src
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include   
-I../include   -g -O2 -Wall -c -o eth-linux.lo `test -f 'eth-linux.c' || echo 
'./'`eth-linux.c
 gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -g -O2 -Wall -c eth-linux.c  -fPIC -DPIC -o .libs/eth-linux.o
eth-linux.c:16:22: fatal error: features.h: No such file or directory
compilation terminated.
*** Error code 1
make: Fatal error: Command failed for target `eth-linux.lo'
Current working directory /root/Downloads/libdnet-1.12/src
*** Error code 1
The following command caused the error:
set fnord $MAKEFLAGS; amf=$2; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list='include man src python test'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" = "."; then \
    dot_seen=yes; \
    local_target="$target-am"; \
  else \
    local_target="$target"; \
  fi; \
  (cd $subdir && make  $local_target) \
   || case "$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done; \
if test "$dot_seen" = "no"; then \
  make  "$target-am" || exit 1; \
fi; test -z "$fail"
make: Fatal error: Command failed for target `all-recursive'
root@sun-11:~/Downloads/libdnet-1.12# 


What version of the product are you using? On what operating system?
libdnet-1.12. On Solaris 11

Please provide any additional information below.
I am attempting to install the latest version of snort and libdnet libraries 
are required.

Original issue reported on code.google.com by [email protected] on 11 Jan 2014 at 7:27

need a manual in a well-marked position , and add interface and metric for full control if someone dont want the default value

What steps will reproduce the problem?
1.
2.
3.  i tried more than half a hour,then get it work...then i found it is 
easy,but maybe hard for newbie to get it work at once...

What is the expected output? What do you see instead?

now it can't set the metric if it can it is better...

because it is not easy to find the API Documentation at :
http://libdnet.sourceforge.net/pydoc/

it is better if a manual for newbie come with the install package like:
import dnet

handle=dnet.route()

#add a route to route table
dst=dnet.addr('111.111.111.111')
gw=dnet.addr(your VPN or something)

handle.add(dst,gw)

#loop a function with two two param

def show(x,y):
 print x,y

handle.loop(show) # it show route table



What version of the product are you using? On what operating system?
dnet-1[1].12.win32       XP

Original issue reported on code.google.com by [email protected] on 24 Nov 2010 at 9:48

"dnet intf show" fails when Infiniband interface present, affects 'nmap'

What steps will reproduce the problem?
1. run "dnet intf show" on system with IB interface


What is the expected output?

   Something similar to output from "ip addr show".

3: ib0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 2044 qdisc pfifo_fast qlen 50000
    link/infiniband 80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:21:d3:a1 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 172.29.60.19/24 brd 172.29.60.255 scope global ib0

4: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast qlen 50000
    link/infiniband 80:00:04:05:fe:80:00:00:00:00:00:00:00:02:c9:02:00:21:d3:a2 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 172.29.61.19/24 brd 172.29.61.255 scope global ib1
    inet6 fe80::202:c902:21:d3a2/64 scope link
       valid_lft forever preferred_lft forever


What do you see instead?

   lt-dnet: intf_loop: Invalid argument


What version of the product are you using?

SVN 665, pulled 8/23/12

On what operating system?

CentOS 5.8

Please provide any additional information below.

kernel 2.6.18-308.8.1.el5

Works on nearly identical system that
has no Infiniband interfaces.

Original issue reported on code.google.com by [email protected] on 24 Aug 2012 at 1:11

Compilation fails on mac for x86_64 arch

What steps will reproduce the problem?
1. On mac os x - ./configure CFLAGS='-arch x86_64' LDFLAGS='-arch x86_64'
2. make


What is the expected output? What do you see instead?

/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include  
-I../include   -arch x86_64 -Wall -c -o fw-ipfw.lo `test -f 'fw-ipfw.c' || echo 
'./'`fw-ipfw.c
 gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -arch x86_64 -Wall -c fw-ipfw.c  -fno-common -DPIC -o .libs/fw-ipfw.o
fw-ipfw.c:43: warning: 'struct ip_fw' declared inside parameter list
fw-ipfw.c:43: warning: its scope is only this definition or declaration, which 
is probably not what you want
fw-ipfw.c: In function 'fr_to_ipfw':
fw-ipfw.c:47: error: dereferencing pointer to incomplete type
fw-ipfw.c:52: error: dereferencing pointer to incomplete type
fw-ipfw.c:53: error: dereferencing pointer to incomplete type
fw-ipfw.c:54: error: dereferencing pointer to incomplete type
fw-ipfw.c:54: error: 'IP_FW_F_IIFNAME' undeclared (first use in this function)
fw-ipfw.c:54: error: (Each undeclared identifier is reported only once
.....
What version of the product are you using? On what operating system?
libdnet-1.12 on mac os x 10.5.5 with xcode-3.1.4

Original issue reported on code.google.com by [email protected] on 24 Aug 2010 at 8:59

trunk subdir embedded in the distribution source

What steps will reproduce the problem?
1. Download libdnet-1.12 source and unpack it
2. There will be trunk subdirectory with all the sources again

What is the expected output? What do you see instead?

No trunk directory.

Please provide any additional information below.

I suppose this is not done on purpose?

Original issue reported on code.google.com by [email protected] on 6 Jan 2009 at 3:49

PyObject_AsReadBuffer api changes

PyObject_AsReadBuffer api changed to use Py_ssize_t instead of int for length 
argument. ignoring this leads to segfaults, using the ip_cksum_add method. this 
patch fixes the python api use in dnet.pyx as well as replacing the 'type' 
argument names with 'type_' as the first is now prohibited in pyrex. a newly 
generated dnet.c is also included.

Original issue reported on code.google.com by BlueCore90 on 21 Oct 2014 at 6:57

Attachments:

libdnet-1.12.pyrex2.7.patch

AIX patches for route and ndd

nmap hasn't worked properly on AIX for a while (since it started using dnet), 
these patches fix that.

configure.in
AC_CHECK_HEADERS - some of the headers require sys/socket.h be included first.

Move the check for ac_cv_header_sys_ndd_var_h before the others so that ndd is 
used on AIX.


src/route-bsd.c
Make it work on AIX using getkerninfo(KINFO_RT_DUMP,...).

src/eth-ndd.c
Setting ETH_TYPE_IP caused the bind() to fail with EEXIST, removing that 
appears to work.
Fill in e->device
nmap calls eth_send with a length less than the minimum length for an ethernet 
packet which causes write to fail with EMSGSIZE (Message too long says 
strerror(), but really is too short), so we pad it.
No point in looping once we have an answer.

Original issue reported on code.google.com by [email protected] on 27 Sep 2011 at 5:18

Attachments:

dnet-stripped.diff

dnet ip fragment offset check

What steps will reproduce the problem?

1. dnet ip off 8192 
Usage: dnet ip [tos|id|off|ttl|proto|src|dst <value>] ... 

What is the expected output? What do you see instead?

The fragment offset should be limited to 0xfff8 but the actual limit is
0x1fff because a shift is missing.  Fragments for big IP packets cannot
be created.

What version of the product are you using? On what operating system?

libdnet-1.12 OpenBSD 4.9-beta

Please provide any additional information below.

Just add the correct shift in the check code.
Then this will work: dnet ip off 65528

--- test/dnet/aton.c.orig       Mon Oct 14 17:42:10 2002
+++ test/dnet/aton.c    Thu Jan 20 03:26:57 2011
@@ -86,7 +86,7 @@ off_aton(char *string, uint16_t *off)
        } else {
                i = strtol(string, &p, 10);
                if (*string == '\0' || (*p != '\0' && *p != '+') ||
-                   i > IP_OFFMASK)
+                   i > (IP_OFFMASK << 3))
                        return (-1);
                *off = htons(((*p == '+') ? IP_MF : 0) | (i >> 3));
        }

Original issue reported on code.google.com by [email protected] on 20 Jan 2011 at 2:40

Attachments:

patch-test_dnet_aton_c

config/acinclude.m4 is better moved to m4/acinclude.m4

What steps will reproduce the problem?
1. Untar version 1.12
2. Run 'autoreconf -fi'

What is the expected output? What do you see instead?
I expect this to complete successfully, but it fails with error messages about 
macros not being found.

What version of the product are you using? On what operating system?
1.12, on Solaris 9.

Please provide any additional information below.

These two patches move the acinclude.m4 file to the m4 directory and register 
it Makefile.am.

https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libdnet/trunk/files/000
1-Using-the-m4-subdirectory-for-macros.patch
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/libdnet/trunk/files/000
2-Moved-acinclude.m4-to-the-m4-directory.patch

After applying these 2 patches, "autoreconf -fi" completes successfully.

Original issue reported on code.google.com by [email protected] on 4 Aug 2011 at 2:48

Can not import dnet

What steps will reproduce the problem?
1. import dnet
2.
3.

What is the expected output? What do you see instead?
Expect Nothing, but

Traceback (most recent call last):
  File "./test.py", line 6, in 
    import dnet
ImportError: dlopen(/Library/Python/2.5/site-packages/dnet.so, 2): 
Symbol not found: _addr_bcast
  Referenced from: /Library/Python/2.5/site-packages/dnet.so
  Expected in: dynamic lookup

What version of the product are you using? On what operating system?
1.12 On OS X 10.6

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 3 Aug 2010 at 12:01

route_get fails on ipv6 / freebsd

This is on FreeBSD 7.1
/*
 * function: find_default_route_entry input: none output: addr (libdnet)
 * structure with the default route address
 */
struct addr    *
find_default_route_entry()
{
        route_t        *r = NULL;
        struct route_entry *e = NULL;
        int             i = 0;

        if ((e = malloc(sizeof(struct route_entry))) == NULL)
                crapout("malloc: failed to allocate route_entry for find_default_route");


        memset((void *) e, 0, sizeof(struct route_entry));
        if ((i = addr_pton("::", &((*e).route_dst))) < 0)
                crapout("dnet: Failed to addr_pton");

        if ((r = route_open()) == NULL)
                crapout("dnet: Failed to route_open");

        if ((i = route_get(r, e)) < 0)
                crapout("dnet: Failed to route_get");

        route_close(r);

        dprintf("default gateway addr: %s\n", addr_ntoa(&((*e).route_gw)));

        return &((*e).route_gw);

}


Expected output: interface for default route on IPv6.
dnet 1.12
FreeBSD 7.1

Original issue reported on code.google.com by jfesler on 23 Mar 2011 at 10:01

dnet.ip_cksum_add crashes on OSX

What steps will reproduce the problem?
1.
execute the following in the python interpreter:

import dnet
data = 'E\x00\x00"\x00\x00\x00\x00@\x01\x00\x00\x01\x02\x03\x04\x05\x06\x07\x08'
dnet.ip_cksum_add(data,0)

What is the expected output? What do you see instead?

Python returns to bash without any error or warning.

What version of the product are you using? On what operating system?

libdnet 1.12 on OSX 10.9.4 with python 2.7.5

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 1 Sep 2014 at 1:58

Deprecated AM_CONFIG_HEADER macro used in configure.in

What steps will reproduce the problem?
1. building with recent versions of autoconf (2.69)/automake (1.13)/libtool 
(2.4.2)

What is the expected output? What do you see instead?

Expected no errors when running `autoreconf -ivf`, got:

configure.in:13: error: possibly undefined macro: AM_CONFIG_HEADER
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.


What version of the product are you using? On what operating system?

Libdnet 1.12 on Mac OS X Mountain Lion with Homebrew.

Please provide any additional information below.

Patch provided

Original issue reported on code.google.com by [email protected] on 5 Jan 2013 at 11:45

Attachments:

libdnet-automake.patch

Windows x64 Support?

What steps will reproduce the problem?
1. ./configure
2. cd python && python setup.py bdist_wininst
3.

What is the expected output? What do you see instead?
Compiled Succesfully or something equivalent.
but compilation broke in between using MSVC++ when building libdnet for python
and got this:

E:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\cl.exe /c /nolo
go /Ox /MD /W3 /GS- /DNDEBUG -I../include -I../../WPdpack/Include -IE:\Python27\
include -IE:\Python27\PC /Tc./dnet.c /Fobuild\temp.win-amd64-2.7\Release\./dnet.
obj
dnet.c
../include\dnet/os.h(26) : error C2371: 'ssize_t' : redefinition; different basi
c types
        e:\python27\include\pyconfig.h(199) : see declaration of 'ssize_t'
./dnet.c(658) : warning C4244: 'function' : conversion from 'ssize_t' to 'long',
 possible loss of data
./dnet.c(883) : warning C4244: 'function' : conversion from 'ssize_t' to 'long',
 possible loss of data
./dnet.c(1044) : warning C4133: 'function' : incompatible types - from 'int *' t
o 'Py_ssize_t *'
./dnet.c(1125) : warning C4133: 'function' : incompatible types - from 'int *' t
o 'Py_ssize_t *'
./dnet.c(1485) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(1491) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(1787) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'lo
ng', possible loss of data
./dnet.c(1810) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(1816) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(1910) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'lo
ng', possible loss of data
./dnet.c(1935) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(1941) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(2021) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'lo
ng', possible loss of data
./dnet.c(2044) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(2050) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(2748) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(2754) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(3118) : warning C4090: 'function' : different 'const' qualifiers
./dnet.c(3118) : warning C4028: formal parameter 1 different from declaration
./dnet.c(3567) : warning C4018: '<' : signed/unsigned mismatch
./dnet.c(3647) : warning C4013: 'strlcpy' undefined; assuming extern returning i
nt
./dnet.c(3655) : warning C4244: '=' : conversion from 'long' to 'unsigned short'
, possible loss of data
./dnet.c(3730) : warning C4018: '<' : signed/unsigned mismatch
./dnet.c(4135) : warning C4090: 'function' : different 'const' qualifiers
./dnet.c(4135) : warning C4028: formal parameter 1 different from declaration
./dnet.c(4556) : warning C4090: 'function' : different 'const' qualifiers
./dnet.c(4556) : warning C4028: formal parameter 1 different from declaration
./dnet.c(5216) : warning C4090: 'function' : different 'const' qualifiers
./dnet.c(5216) : warning C4028: formal parameter 1 different from declaration
./dnet.c(5730) : warning C4018: '>' : signed/unsigned mismatch
./dnet.c(6069) : warning C4244: 'function' : conversion from 'ssize_t' to 'long'
, possible loss of data
./dnet.c(6099) : warning C4244: '=' : conversion from 'ssize_t' to 'int', possib
le loss of data
error: command '"E:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd6
4\cl.exe"' failed with exit status 2


What version of the product are you using? On what operating system?
libdnet-1.12

Please provide any additional information below.
Is this because of change in architecture?

Original issue reported on code.google.com by [email protected] on 4 Nov 2010 at 1:14

Code review request

Purpose of code changes on this branch:

On some platforms nmap developers found that sa->sa_len might equal 0.
This is a workaround for that issue.

After the review, I'll merge this branch into:
/trunk

with message: "Work around for sa->sa_len approved by dugsong'

Currently I have the trunk checked out, do I need to create a new branch
for the Nmap merges?

Original issue reported on code.google.com by [email protected] on 12 Feb 2010 at 8:20

alias addresses don't have a netmask

What steps will reproduce the problem?
1. check an interfaces alias addresses

What is the expected output? What do you see instead?
expected:
192.168.0.5/24

actual:
192.168.0.5

What version of the product are you using? On what operating system?
0.12 on Ubuntu 8.10

Please provide any additional information below.
This is checked from python, so could be a python only issue.

Original issue reported on code.google.com by [email protected] on 12 Jan 2009 at 7:55

fw(): Function not implemented on Python 2.6/Fedora 11

What steps will reproduce the problem?
1. python
2. import dnet
3. fw = dnet.fw()

What is the expected output? What do you see instead?
-expect no output, just success
-File "dnet.pyx", line 1244 in dnet.fw.__init__
  OSError: Function not implemented

What version of the product are you using? On what operating system?
trunk (r653, I think), Fedora 11

Please provide any additional information below.
Does the OS need some other utility packages to interface with iptables or
does this just not work on Fedora?

Original issue reported on code.google.com by [email protected] on 4 Nov 2009 at 5:16

Python 2.7.3 "TypeError: exceptions must be strings, classes or instances, not type"

What steps will reproduce the problem?
1. Use the python module with Python 2.7.3
2. Do anything that will cause an exception and try to catch it

What is the expected output? What do you see instead?
  Instead of the exception being thrown and caught, it simply exits with  "TypeError: exceptions must be strings, classes or instances, not type".


Please provide any additional information below.

  This is caused by it being compiled with an old version of pyrexc. The fix is simple enough, just download libdnet from source as well as installing pyrexc. One minor issue is that the word "type" is now a reserved word, so you I just ran threw and replaced the variables named "type" with "typee" (patch attached). Run "pyrexc dnet.pyx" in the python folder and reinstalling fixes it.

Original issue reported on code.google.com by [email protected] on 5 Jul 2012 at 10:24

Attachments:

dnet.pyx.patch

No libdnet binaries for Python2.6

What steps will reproduce the problem?
1. >>> import dnet
   ImportError: No module named dnet


What is the expected output? What do you see instead?
I'm basicly trying to run scapy under windows.
What i should be seeing is anything but the error message?


What version of the product are you using? On what operating system?
Windows XP Pro SP2, Python 2.6.4, 'final'.
Trying to compile libdnet-1.12 with Cygwin+MinGW.


Please provide any additional information below.
C:\MinGW, C:\WpdPack, C:\cygwin is installed correctly.
Basicly what i need is a short description on how to compile the 
application :/
Yea i've tried google, but ./configure under windows doesn't make sense and 
i honestly don't know how to compile this.
Would be nice with a setup.py in the dist?

Something like:
   > python setup.py config --with-pcap="C:\WpdPack"
   > python setup.py build -cmingw32
   > python setup.py bdist_wininst

Original issue reported on code.google.com by [email protected] on 24 Mar 2010 at 7:54

[PATCH] void* dereference

What steps will reproduce the problem?
1. Run on a system with !HAVE_LINUX_PROCFS and a void* ifc_buf in ifconf.


What is the expected output? What do you see instead?

libdnet seems to behave correctly for me, but it's probably just due to 
compiler help (the code treats ifc_buf like a char*).

If HAVE_LINUX_PROCFS is defined then this code isn't used, and not all systems 
have a void *ifc_buf, so I guess that's why it wasn't noticed.


What version of the product are you using? On what operating system?

SVN checkout.  Running on NetBSD -current (5.99.39)


Please provide any additional information below.

I've attached a simple patch to correct this.

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 5:50

Attachments:

void-deref.patch

wtfbbqhax / libdnet Goto Github PK

libdnet's People

Stargazers

Watchers

libdnet's Issues

Recommend Projects

Recommend Topics

Recommend Org