Common Problems

• Got Root?

CCH uses injection and sniffing, which requires root permissions on the box.

• Appropriate hardware/network configuration.

Because CCH uses sniffing/injection, your host-based firewall has no affect
on it's ability to see packets on the wire, or send packets. This can lead
to false positives.

Make sure you use a "real world" environment. This can be tricky to set up
in a home lab. You need two hosts (VM's may exhibit the SAME problem caused
by CCH's ability to sniff traffic on the wire -- false positives), and two
firewalls, with a DNS server/Coordinator in the "open" network between the
firewalls (or, at least, accessible to both peers).

Make sure you have physical wire separation. If you're using an older hub,
packets may be visible on each wire, so even though the packets may be
logically dropped by the firewalls and not "routed", the CCH sniffer may
still see them (yes, all this happened to me while testing!)

• Host Kernel Sending RST's

Make sure to use the silent-port.sh script to kill outbound RST's from
your peers, or the kernel will stifle your connections before they get
started.

• DNS access / Contacting the Coordinator

Make sure you configure the coordinator's DNS zone files appropriately,
and do some basic tests with dig.

If you are not using a public DNS name, and are running this in a lab
environment, make sure your host's name resolver is configured to talk
to the coordinator (etc/resolv.conf). CCH uses libresolv to communicate
with the Coordinator, so if your using an internal name, the DNS requests
have to get to the Coordinator. Normally, this is done using the regular
DNS query delegation, but you might have to help in a lab environment.

Again, use dig to check that your host resolves the name correctly (for
example, "dig private.lan").