How would a PCAP filter look like to capture all DHCP related traffic

Ping packets should use an ICMP type of 8 (echo) or 0 (echo reply), so you could use a capture filter of:

icmp

and a display filter of:

icmp.type == 8 || icmp.type == 0

For HTTP, you can use a capture filter of:

tcp port 80

or a display filter of:

tcp.port == 80

or:

http

Note that a filter of http is not equivalent to the other two, which will include handshake and termination packets.

If you want to measure the number of connections rather than the amount of data, you can limit the capture or display filters to one side of the communication. For example, to capture only packets sent to port 80, use:

dst tcp port 80 

Couple that with an http display filter, or use:

tcp.dstport == 80 && http

For more on capture filters, read "Filtering while capturing" from the Wireshark user guide, the capture filters page on the Wireshark wiki, or pcap-filter (7) man page. For display filters, try the display filters page on the Wireshark wiki. The "Filter Expression" dialog box can help you build display filters.

My best bet would be to use something like:

 tcpdump -ieth0 -s96 -w traffic.dump 'ip or icmp or tcp or udp'

Where the "tricky" part will be to chose a correct value for the "-s" (snaplen) parameter (snaplen is the maximum length of the packet tcpdump will capture).

From the tcpdump man pages:

Snarf snaplen bytes of data from each packet rather than the default of 68 (with NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in.

In this example i'm using 96 to be "almost" sure that I would capture 100% of ethernet+ip+(icmp || udp || tcp) header values.

In case your traffic have IP or TCP options (i.e. timestamps) and you want to also capture this info, then you will have to play with the snaplen parameter (i.e. increase/decrease it).

In case the length of the headers of your packet is less than snaplen, you may also capture part of the payload.

Finally, to read the traffic captured, I would use something like:

tcpdump -e -nn -vv -r traffic.dump   

Where the important part is to use the "-e" option so you can get the ethernet headers printed.

This page gives you an idea about the size of the ethernet/tcp/udp headers under different circumstances and may help you to arrive to a "correct" value for the snaplen parameter.