https://facebook.com redirects to https://www.facebook.com which has a different IP Address than facebook.com. There is also ssl.facebook.com but I am not sure what it is used for:
$ host facebook.com
facebook.com has address 69.171.229.11
facebook.com has address 69.171.224.37
facebook.com has address 66.220.158.11
facebook.com has address 66.220.149.11
facebook.com has address 69.171.242.11
facebook.com has IPv6 address 2a03:2880:10:1f02:face:b00c:0:25
facebook.com has IPv6 address 2a03:2880:2110:3f01:face:b00c::
facebook.com has IPv6 address 2a03:2880:10:8f01:face:b00c:0:25
facebook.com mail is handled by 10 smtpin.mx.facebook.com.
$ host www.facebook.com
www.facebook.com has address 69.171.237.16
www.facebook.com has IPv6 address 2a03:2880:10:1f03:face:b00c:0:25
$ host ssl.facebook.com
ssl.facebook.com is an alias for star.facebook.com.
star.facebook.com has address 69.171.234.39
star.facebook.com has IPv6 address 2a03:2880:10:cf02:face:b00c:0:4
For java.com on the other hand the entries are the same for both www.java.com and java.com:
$ host java.com
java.com has address 137.254.16.66
java.com mail is handled by 10 mx5.sun.com.
java.com mail is handled by 10 mx6.sun.com.
java.com mail is handled by 10 mx8.sun.com.
java.com mail is handled by 10 mx9.sun.com.
$ host www.java.com
www.java.com is an alias for java.com.
java.com has address 137.254.16.66
java.com mail is handled by 10 mx5.sun.com.
java.com mail is handled by 10 mx6.sun.com.
java.com mail is handled by 10 mx8.sun.com.
java.com mail is handled by 10 mx9.sun.com.
According to the Packet flow in Netfilter and General Networking schematic, tcpdump captures (AF_PACKET) after egress (qdisc). So it's normal you don't see the delay in tcpdump: the delay was already present at initial capture.
You'd have to capture it one step earlier, so involve a 3rd system:
S1: system1, runs tcpdump on outgoing interface
R: router (or bridge, at your convenience, this changes nothing), runs the qdisc netem
S2: system2, runs tcpdump on incoming interface
__________________ ________________ __________________
| | | | | |
| (S1) -- tcpdump -+---+- (R) -- netem -+---+- tcpdump -- (S2) |
|__________________| |________________| |__________________|
That means 3 network stacks involved, be they real, vm, network namespace (including ip netns, LXC, ...)
Optionally, It's also possible to cheat and move every special settings on the router (or bridge) by using an IFB interface with mirred traffic: allows by a trick (dedicated for this case) to insert netem sort-of-after ingress rather than on egress:
_______ ______________________________________________ _______
| | | | | |
| (S1) -+---+- tcpdump -- ifb0 -- netem -- (R) -- tcpdump -+---+- (S2) |
|_______| |______________________________________________| |_______|
There's a basic IFB usage example in tc mirred manpage:
Using an ifb interface, it is possible to send ingress traffic through an instance of sfq:
# modprobe ifb
# ip link set ifb0 up
# tc qdisc add dev ifb0 root sfq
# tc qdisc add dev eth0 handle ffff: ingress
# tc filter add dev eth0 parent ffff: u32 \
match u32 0 0 \
action mirred egress redirect dev ifb0
Just use netem on ifb0 instead of sfq (and in non-initial network namespace, ip link add name ifbX type ifb
works fine, without modprobe).
This still requires 3 network stacks for proper working.
After a suggestion from JenyaKh, it turns out it's possible to capture a packet with tcpdump, before egress (thus before qdisc) and then on egress (after qdisc): by using iptables (or nftables) to log full packets to the netlink log infrastructure, and still reading them with tcpdump, then again using tcpdump on the egress interface. This requires only settings on S1 (and doesn't need a router/bridge anymore).
So with iptables on S1, something like:
iptables -A OUTPUT -o eth0 -j NFLOG --nflog-group 1
Specific filters should probably be added to match the test done, because tcpdump filter is limited on nflog interface (wireshark should handle it better).
If the answer capture is needed (here done in a different group, thus requiring an additional tcpdump):
iptables -A INPUT -i eth0 -j NFLOG --nflog-group 2
Depending on needs it's also possible to move them to raw/OUTPUT and raw/PREROUTING instead.
With tcpdump:
# tcpdump -i nflog:1 -n -tt ...
If a different group (= 2) was used for input:
# tcpdump -i nflog:2 -n -tt ...
Then at the same time, as usual:
# tcpdump -i eth0 -n -tt ...
Best Answer
Yes, that's what I meant by that. The "any" device doesn't work by opening all devices independently and capturing on them, it works by opening a "packet socket" and, instead of binding it to a particular device (which is how you capture on that device on Linux), leaving it unbound so it listens to all sockets.
The call to set promiscuous mode would fail on an unbound socket (I just tested it on a fairly recent kernel), so libpcap will not turn promiscuous mode on for the "any" device.