developer3000s / honeyd Goto Github PK

What steps will reproduce the problem?
1. Install libevent-2.0.6rc
2. Try to compile honeyd-1.5c

make[2]: Entering directory 
`/var/tmp/portage/net-analyzer/honeyd-1.5c-r2/work/honeyd-1.5c'
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -I./ -I./compat 
-I/usr/include/python2.6 -I/usr/include -I/usr/include -I/usr/include     -O2 
-pipe -Wall -ggdb -march=athlon-xp -Wall -g 
-DPATH_HONEYDINCLUDE="\"/usr/include/honeyd\"" 
-DPATH_HONEYDDATA="\"/usr/share/honeyd\"" 
-DPATH_HONEYDLIB="\"/usr/lib/honeyd\"" -DHONEYD_PLUGINS_DECLARE="" 
-DHONEYD_PLUGINS="" -DPATH_RRDTOOL="\"/usr/bin/rrdtool\"" -Wall -g 
-DPATH_HONEYDINCLUDE="\"/usr/include/honeyd\"" 
-DPATH_HONEYDDATA="\"/usr/share/honeyd\"" 
-DPATH_HONEYDLIB="\"/usr/lib/honeyd\"" -DHONEYD_PLUGINS_DECLARE="" 
-DHONEYD_PLUGINS="" -DPATH_RRDTOOL="\"/usr/bin/rrdtool\"" -Wall -g 
-DPATH_HONEYDINCLUDE="\"/usr/include/honeyd\"" 
-DPATH_HONEYDDATA="\"/usr/share/honeyd\"" 
-DPATH_HONEYDLIB="\"/usr/lib/honeyd\"" -DHONEYD_PLUGINS_DECLARE="" 
-DHONEYD_PLUGINS="" -DPATH_RRDTOOL="\"/usr/bin/rrdtool\"" -c honeyd.c
In file included from honeyd.c:97:
tagging.h:89: error: expected declaration specifiers or ‘...’ before 
‘(’ token
tagging.h:89: error: expected declaration specifiers or ‘...’ before 
‘(’ token
In file included from stats.h:36,
                 from honeyd.c:98:
./compat/sha1.h:23: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:23: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:26: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:28: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:30: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:32: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:35: warning: ‘__bounded__’ attribute directive ignored
./compat/sha1.h:35: warning: ‘__bounded__’ attribute directive ignored
In file included from /usr/include/python2.6/Python.h:8,
                 from honeyd.c:106:
/usr/include/python2.6/pyconfig.h:1048:1: warning: "_GNU_SOURCE" redefined
In file included from /usr/include/evutil.h:29,
                 from /usr/include/event.h:178,
                 from honeyd.c:73:
/usr/include/event2/util.h:61:1: warning: this is the location of the previous 
definition
In file included from /usr/include/python2.6/Python.h:8,
                 from honeyd.c:106:
/usr/include/python2.6/pyconfig.h:1067:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/limits.h:27,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include-fixed/limits.h:122,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include-fixed/limits.h:11,
                 from /usr/include/sys/param.h:26,
                 from honeyd.c:33:
/usr/include/features.h:210:1: warning: this is the location of the previous 
definition
make[2]: *** [honeyd.o] Error 1

Full build log attached.

Gentoo Linux bug report: https://bugs.gentoo.org/show_bug.cgi?id=333099

What steps will reproduce the problem?
1. honeyd -f /etc/honeyd.conf --webserver-port 9100 --webserver-root
/usr/local/share/honeyd/webserver/htdocs/
2. honeydctl -v
3. honeydctl> list

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

I expect a list of all configured templates but I got a "parse error"

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

honeyd-1.5c on OpenBSD (i386, sparc64, amd64 and macppc)

Please provide any additional information below.

$ sudo honeydctl -v
Honeyd 1.5c Management Console
Copyright (c) 2004 Niels Provos.  All rights reserved.
See LICENSE for licensing information.
Up for 695 seconds.
0C 0P honeydctl> help
help             outputs a command help
!                runs a Python command in the Honeyd environment
delete           removes configured templates and ports
list             lists configured templates or subsystems
0C 0P honeydctl> list
<stdin>: parse error
0C 0P honeydctl> delete
<stdin>: parse error
0C 0P honeydctl> !
Traceback (most recent call last):
 File "<filter>", line 11, in ?
NameError: name 'null' is not defined
0C 0P honeydctl>


here's my honeyd.conf (default):

route entry 10.0.0.1
route 10.0.0.1 link 10.2.0.0/24
route 10.0.0.1 add net 10.3.0.0/16 10.3.0.1 latency 8ms bandwidth 10Mbps
route 10.3.0.1 link 10.3.0.0/24
route 10.3.0.1 add net 10.3.1.0/24 10.3.1.1 latency 7ms loss 0.5
route 10.3.1.1 link 10.3.1.0/24

# Example of a simple host template and its binding
create template
set template personality "Microsoft Windows XP Professional SP1"
set template uptime 1728650
set template maxfds 35
add template tcp port 80 "scripts/iis5.net/main.pl"
add template tcp port 22 "sh scripts/test.sh $ipsrc $dport"
add template tcp port 23 proxy $ipsrc:23
add template udp port 53 proxy 141.211.92.141:53
set template default tcp action reset

create default
set default default tcp action block
set default default udp action block
set default default icmp action block

create router
set router personality "Cisco 1601R router running IOS 12.1(5)"
set router default tcp action reset
add router tcp port 22 "scripts/test.sh"
add router tcp port 23 "scripts/router-telnet.pl"

bind 10.3.0.1 router
bind 10.3.1.1 router
bind 10.3.1.12 template
bind 10.3.1.11 template
bind 10.3.1.10 template
set 10.3.1.11 personality "Microsoft Windows NT 4.0 SP3"
set 10.3.1.10 personality "IBM AIX 4.2"

What steps will reproduce the problem?
1. Start a virtual machine on tap1
2. Start honeyd on another interface with
"sudo honeyd -i eth0 -i tap1 test.config -d
3. Ping from inside the virtual machine toward any of the honeypot machines.

What is the expected output? What do you see instead?
Honeyd segfaults.

What version of the product are you using? On what operating system?
SVN HEAD and latest package, same result. It has been tried on Fedora 8,
Ubuntu 7.10 and 8.04 beta.

Please provide any additional information below.
I've provided as attachments a patch that seems to correct the issue. Our
patched version of honeyd is regularly used, and has yet to show any side
effects. Also attached is the config file used.

This bug has also been notified on the forum, by someone who wasn't using a
virtual machine, but a real one.
http://honeyd.org/phpBB2/viewtopic.php?t=510&sid=cb0f85cb62141975ea924060c9d90c8
3

What steps will reproduce the problem?
1. Launch honeyd with a '-u' or '-g' switch:


2. Observer the user the daemon runs as (it is 'nobody' instead of the
provided ones:

nobody   19918     1  0 15:10 ?        00:00:00 /usr/bin/honeyd -f
/etc/honeypot/honeyd.conf -l /var/log/honeypot/honeyd.log -p
/etc/honeypot/nmap.prints -a /etc/honeypot/nmap.assoc -0
/etc/honeypot/pf.os -x /etc/honeypot/xprobe2.conf -u 110 -g 110
--disable-webserver -i lo 10.0.0.0/8

Also, syslog shows:

Nov 23 15:10:16 javifsp honeyd[19918]: Demoting process privileges to uid
65534, gid 65534

What is the expected output?
----------------------------

I would expect it to run with the provided uid/gid

Product version: 1.5c 
Operating system: Debian GNU/Linux 'sid'

This bug was found by a user a few months back in Debian (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484498) but I was unable
to dedicate time to investigate it until recently. 

The issue is related to how honeyd_init() overwrites honeyd_uid and
honeyd_gid even though these are set by the command line switches (-u and
-g) which never take effect.

The attached patch is a proposed fix: only set honeyd_uid and honeyd_gid to
the system's nobody user if the values are still the default values set in
the header. Otherwise don't do anything (i.e. honor the switches)

With this patch, which I'm going to submit in a new Debian package version
(-6) honeyd starts properly:

jfs@silicio:honeyd$ sudo /etc/init.d/honeyd start
Starting Honeyd daemon: honeyd.
jfs@silicio:honeyd$ ps -ef |grep honeyd
honeyd   31842     1  0 15:28 ?        00:00:00 /usr/bin/honeyd -f
/etc/honeypot/honeyd.conf -l /var/log/honeypot/honeyd.log -p
/etc/honeypot/nmap.prints -a /etc/honeypot/nmap.assoc -0
/etc/honeypot/pf.os -x /etc/honeypot/xprobe2.conf -u 110 -g 110
--disable-webserver -i lo 10.0.0.0/8
$ grep Demoting /var/log/syslog |tail -1
Nov 23 15:28:58 javifsp honeyd[31842]: Demoting process privileges to uid
110, gid 110

One feature that is nice to have in Honeyd is the ability for proxied services 
to look up the source and destination IP of incoming requests. This way, they 
can tailor their responses based on the destination IP address and port. This 
would provide similar function to the HONEYD_IP_SRC, HONEYD_IP_DST, 
HONEYD_SRC_PORT, and HONEYD_DST_PORT that are passed to subsystems.

I have attached a patch which causes Honeyd to create a new unix domain socket 
(/var/run/honeyd-proxy.sock) which can be used to subscribe to information 
about proxied requests. Using this interface, a backend server providing 
proxied services can look up the original source and destination ip address and 
port. It receives two types of messages - one when the proxied connection is 
initiated, and another when the proxied connection is closed.

The patch file also makes the following changes:
- Allows users to provide CFLAGS via configure instead of always using 
hardcoded CFLAGS.
- Lower logging level of syslog messages which are sent on every connection.
- Set the permissions on the Honeyd UI and proxy sockets to allow 
administration of these from the UID/GID that Honeyd runs under.

When i execute Honeyd.exe it display 

honeyd-win32: Unable to query adapter \Device\NPF_GenericDialupAdapter for
MAC Address. Error Code: 6

What steps should be taken to resolve this issue ??

What steps will reproduce the problem?
1. Set up an emulated Honeyd configuration file which proxies data to a
local SSH daemon. For example:

create linux.192.168.1.101
set linux.192.168.1.101 default tcp action reset
set linux.192.168.1.101 default udp action block
set linux.192.168.1.101 default icmp action open
set linux.192.168.1.101 maxfds 1024
set linux.192.168.1.101 uptime 79239
add linux.192.168.1.101 tcp port 22 proxy localhost:22
set linux.192.168.1.101 personality "Linux 2.4.7 (X86)"
bind 192.168.1.101 linux.192.168.1.101

2. Create a larger file to transfer over scp:

# dd if=/dev/zero of=testfile bs=1024 count=5000

3. Copy the file to the emulated Honeyd system:

# scp testfile [email protected]:/tmp

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

Expect transfer to complete quickly similar to the same speed when
transferring without using Honeyd. Instead I see a short burst where approx
2112 kb are transferred, followed by several shorter bursts and a long
delay at shutdown.

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

1.5c and SVN trunk.

Please provide any additional information below.

The systems are on the same 100mb ethernet lan. Transferring the same file
and bypassing Honeyd takes 1 second (4.9MB/s). Transferring through Honeyd
proxy takes 32 seconds at 156 KB/s.

On Aug 01 2005 Niels Provos wrote 

Mac addresses are link-layer mechanism. They only work for machines on the
same network segment. The moment that a router gets in the way, the mac
address is removed. The IP layer does not have MAC addresses.

Honeyd essentially tells you that you are trying to use MAC addresses, but
that there is no ethernet interface for the IP range that you configured. I
suppose I could just make that a warning instead of a failure.

Does this make more sense?

Niels.

For original post.See
http://www.honeyd.org/phpBB2/viewtopic.php?p=971&sid=31e9d6a98779109ffe203825792
b6757


Dear Niels.

By having a error when a Mac-address is used on a routed virtual machine
prevents users from using the same Template for non-routed and routed
Virtual Machines.

I see that the condition is still unchanged in the newly released honeyd 1.5c

I have therefore changed the error to a warning in my own WinHoneyd release.

Attached you will find the changed file "parse.c", that I humbly submit for
inclusion in the main code of Honeyd.

What steps will reproduce the problem?
1. Start Honeyd.
2. Restart the interface Honeyd is bound to.
3. Watch CPU usage climb to 100% and stay there.

What is the expected output? What do you see instead?
Expect Honeyd to not enter an infinite loop

What version of the product are you using? On what operating system?
Honeyd v1.5c

The fix for this issue is to read one byte first in order to clear any POLLERR 
bits and then continue reading data.

On recent Linux systems, packets going through the loopback interface do
not get checksums inserted. This is reasonable behaviour as there is no
physical network to corrupt the data, but it does cause Honeyd to discard
the packets because the checksums are wrong.

I attach a patch for honeyd 1.5c that adds a new option: -N causes it to
ignore the checksums on TCP, UDP, and ICMP packets.

Andrew

From Spiros Antonatos:

We recently discovered a bug in the honeyd implementation of TCP stack.
When an ACK is delayed and comes after fresh data has arrived, then honeyd
falls into an infinite loop.

More specifically, the line
acked = th_ack - con->snd_una;

in the TCP_RECV_SEND_DATA macro (honeyd.c file) causes an integer overflow
when a delayed ACK
is received and thus honeyd considers an amount of more than 4GB to be
acked.

We hunted the bug as follows. In the TCP_CHECK_SEQ_OR_ACK macro (honeyd.c
file)
there is a code that checks delayed packets:

if (TCP_SEQ_LT(th_ack, con->snd_una)) { \
       if (tcp->th_flags & TH_RST) \
       goto drop; \
}\

but only treats RST packets. We commented out the " if (tcp->th_flags &
TH_RST)"
and thus all delayed ack packets are ignored. We tested our fix and does not
break any connections
and transfers.

see http://www.honeyd.org/phpBB2/viewtopic.php?
t=531&start=0&postdays=0&postorder=asc&highlight=

patch is attached.

jane, how do i stop this crazy thing?!

What steps will reproduce the problem?
1. A basic configuration binding a Windows workstation
2. Honeyd started
3. Try to ping or otherwise contact the virtual IP

Expected behaviour is some interaction with the pinging or contacting network 
host however after about 2 minutes the console shows 

honeyd[1136]: listening promiscuously on eth0: (arp or ip proto 47 or (udp and 
src port 67 and dst port 68) or (ip )) and not ether src 00:50:56:a8:74:c0
honeyd[1136]: Demoting process privileges to uid 65534, gid 65534
honeyd[1136]: update_connect_cb: connection failed: Operation now in progress

Honeyd hosts don't respond. ARP requests are visible for new hosts.

Honeyd version is 1.5c on Debian

What steps will reproduce the problem?
1. When i edited the /etc/honeypot/xprobe2.conf file

What is the expected output? What do you see instead?
Expected output was to run the honeyd & obtain the logs
What i get is segmentation fault(image error.png attached) 

What version of the product are you using? On what operating system?
Version - Honeyd V1.5c
OS - Ubuntu 10.04LTS

Please provide any additional information below.
I was following the steps provided in this blog - 
http://www.infoconsultor.info/?p=1392

Thank You.

 gcc -DHAVE_CONFIG_H -I. -I. -I. -I./ -I./compat -O2 -Wall -g
-DPATH_HONEYDINCLUDE=\"/usr/local/include/honeyd\"
-DPATH_HONEYDDATA=\"/usr/local/share/honeyd\"
-DPATH_HONEYDLIB=\"/usr/local/lib/honeyd\" -DHONEYD_PLUGINS_DECLARE=
-DHONEYD_PLUGINS= -DPATH_RRDTOOL=\"\" -c honeyd_overload.c  -fPIC -DPIC -o
.libs/honeyd_overload.o
honeyd_overload.c: In function 'recvmsg':
honeyd_overload.c:738: sorry, unimplemented: inlining failed in call to
'recvfrom': redefined extern inline functions are not considered for inlining
honeyd_overload.c:873: sorry, unimplemented: called from here


What version of the product are you using? On what operating system?
honeyd-1.5c

What steps will reproduce the problem?

1. Run honeyd with the -d flag
2. or comment out setlogmask(LOG_UPTO(LOG_INFO));
3. Run honeyd
4. Generate alot of traffic ex: nmap -r -p1-65535 honeypot

this will send over 65535 syslog messages to syslog

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

a complete scan of the honeypot will take a few minutes, as opposed to a
few seconds  as is the result for a real machine. 

I"ve logged to syslog using both syslog and rsyslog, neither is taxed by
the load honeyd is putting on it. average syslog message generation was
around 1000 messages a second, with honeyd being the limiting factor.

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

honeyd 1.5c linux

Please provide any additional information below.

What steps will reproduce the problem?
1. ./configure --with-python
2. make
3. make install

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

usr/local/lib -ldnet -lz -lm -Wl,-rpath,/usr/local/lib
-Wl,-rpath,/usr/local/lib
/usr/local/lib/python2.5/config/libpython2.5.so.0.0: warning: tmpnam()
possibly used unsafely; consider using mkstemp()
/usr/local/lib/python2.5/config/libpython2.5.so.0.0: warning: tempnam()
possibly used unsafely; consider using mkstemp()
/usr/local/lib/python2.5/config/libpython2.5.so.0.0: warning: strcpy() is
almost always misused, please use strlcpy()
/usr/local/lib/python2.5/config/libpython2.5.so.0.0: warning: sprintf() is
often misused, please use snprintf()
/usr/local/lib/python2.5/config/libpython2.5.so.0.0: warning: strcat() is
almost always misused, please use strlcat()
honeyd.o(.data+0x144): undefined reference to `pydataprocessing_test'
honeyd.o(.data+0x14c): undefined reference to `pydatahoneyd_test'
collect2: ld returned 1 exit status
*** Error code 1


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

honeyd-1.5c


Please provide any additional information below.

What steps will reproduce the problem?
1. Send a large number of UDP packets of size > HONEYD_MTU which cause
fragmentation over Honeyd proxy.
2. Watch as memory corruption occurs - the pool_alloc function will return
an entry with entry->data set to an invalid pointer.
3. Honeyd will crash in memcpy function in ipfrag.c - ip_send_fragments due
to the returned pointer from pool_alloc being invalid.

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

Honeyd should be able to handle UDP packets > MTU without crashing.

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

Honeyd 1.5c, Linux.

Please provide any additional information below.

When allocating udp packets in the udp_send function in honeyd.c, if the
size of the packet is greater than the pool size, it should use
pool_alloc_size instead of pool_alloc in order to allocate the correct size
pointer. Otherwise it will return a chunk of memory too small to
accommodate the data, and the pool will get corrupted.

Here is a patch which seems to address the problem:

        ip_personality(tmpl, &id);

-       pkt = pool_alloc(pool_pkt);
+       iplen = IP_HDR_LEN + UDP_HDR_LEN + len;

+       if (iplen <= HONEYD_MTU)
+               pkt = pool_alloc(pool_pkt);
+       else
+               pkt = pool_alloc_size(pool_pkt, iplen);
+
        udp = (struct udp_hdr *)(pkt + IP_HDR_LEN);
        udp_pack_hdr(udp, con->con_dport, con->con_sport, UDP_HDR_LEN + len);

-       iplen = IP_HDR_LEN + UDP_HDR_LEN + len;
-
        /* Src and Dst are reversed both for ip and tcp */
        ip_pack_hdr(pkt, 0, iplen, id,
            dontfragment ? IP_DF : 0, honeyd_ttl,

What steps will reproduce the problem?
1. Start Honeyd with a virtual interface.
2. Ping the virtual interface with a packet size >= HONEYD_MTU (1500). I
was able to do this with the command 'ping -s 1472 <honeyd_ip>'
3. Watch the memory usage of the Honeyd process grow without bound.

What is the expected output? What do you see instead?
Memory usage should remain stable.

What version of the product are you using? On what operating system?
Honeyd 1.5c.

Please provide any additional information below.

The 'pool_pkt' structure is initialized with a pool size of HONEYD_MTU in
honeyd.c. Then in two methods in honeyd.c (honeyd_delay_packet and
icmp_echo_reply), there is the following construct:

    if (iplen < HONEYD_MTU)
        pkt = pool_alloc(pool_pkt);
    else
        pkt = pool_alloc_size(pool_pkt, iplen);

It appears that pool_alloc gives a chunk of memory equal to the pool size,
while pool_alloc_size can give a larger chunk of memory. However, in this
case if iplen == HONEYD_MTU, pool_alloc_size allocates a new chunk of
memory equal to the pool size, and then when pool_free is called on the
memory, it does:

    if (entry->size == pool->size)
        SLIST_INSERT_HEAD(&pool->entries, entry, next);
    else {
        free(entry);
        pool->nalloc--;
    }

In this case the entry is added back onto the pool->entries list, however
the next packet that comes in with the same size will cause a new
allocation instead of looking in pool->entries.

This issue can be resolved by changing the line:

    if (iplen < HONEYD_MTU)

to:

    if (iplen <= HONEYD_MTU)

However, it might be a cleaner API to remove pool_alloc_size, and just make
pool_alloc take a size parameter. Then pool_alloc will allocate from the
pool if size <= pool->size, or allocate a new chunk of memory if size >
pool->size.

After making this change, the SCP performance issue reported in issue #12
is much less pronounced. Transferring a 5 MB file to Honeyd now completes
in 11 seconds instead of 32 on my test system (most likely because it
doesn't need to allocate memory for each incoming packet).

I am seeing small memory leaks on startup in Honeyd 1.5c. There are three leaks 
in total:

1)
==22044== 288 bytes in 6 blocks are definitely lost in loss record 20 of 49
==22044==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==22044==    by 0x41A467D: (within /lib/tls/i686/cmov/libc-2.9.so)
==22044==    by 0x41A6C7E: getaddrinfo (in /lib/tls/i686/cmov/libc-2.9.so)
==22044==    by 0x805EF45: cmd_proxy_getinfo (command.c:237)
==22044==    by 0x8060F5A: hydparse (parse.y:624)
==22044==    by 0x8061DD8: parse_configuration (parse.y:1202)
==22044==    by 0x8065360: config_read (config.c:133)
==22044==    by 0x8055440: main (honeyd.c:3544)

2)
==22044== 463 bytes in 98 blocks are definitely lost in loss record 26 of 49
==22044==    at 0x4026FDE: malloc (vg_replace_malloc.c:207)
==22044==    by 0x415434F: strdup (in /lib/tls/i686/cmov/libc-2.9.so)
==22044==    by 0x80678D3: parse_tl (personality.c:1166)
==22044==    by 0x8065EF3: personality_line (personality.c:1294)
==22044==    by 0x8069325: personality_parse (personality.c:1371)
==22044==    by 0x8055393: main (honeyd.c:3488)

3)
==22044== 1,607 (592 direct, 1,015 indirect) bytes in 37 blocks are definitely 
lost in loss 
record 31 of 49
==22044==    at 0x4025092: calloc (vg_replace_malloc.c:397)
==22044==    by 0x806E0DD: get_assoc (xprobe_assoc.c:148)
==22044==    by 0x806E1B2: parse_associations (xprobe_assoc.c:190)
==22044==    by 0x805535B: main (honeyd.c:3481)

Leak #1 is fixed by freeing the result of getaddrinfo when cloning a port. Leak 
#2 is fixed by 
freeing the options string in the personality->tests structure when it is 
freed. Leak #3 is fixed 
by checking if the assoc structure is already in the splay tree and if it is 
already found, then it is 
freed.

What steps will reproduce the problem?
1. Use the "set X.X.X.X ethernet " config option on a IP address, without
previously giving a MAC address to its "parent" template  


What is the expected output? What do you see instead?
Normaly if I set the MAC address of an IP, it should use it. But instead it
only uses it if I also set a MAC address to its "parent" template (by that
I mean the template the IP is bound to)

What version of the product are you using? On what operating system?
SVN HEAD and latest package (1.5c) both have the issue.

Please provide any additional information below.
I've attached a sample config file with comments, as well as a proposed
patch. No side effects were noticed after patching, but we didn't do
extensive testing.

Florian Vichot
hynesim.org

A suggestion is to change the instances of ETH_HDR_LEN in arp_recv_cb
to req->inter->if_dloff.

The offset for standard ethernet packets (DL_EN10MB link type) is 14
but when you set monitoring interface to "any" the offset becomes 16 as
the link type turns to DLT_LINUX_SLL. Thus
the decoding does not succeed as the line
arp = (struct arp_hdr *) (pkt+ETH_HDR_LEN); 
will yield to incorrect offset for arp header.