And, while this likely doesn't apply yet depending how young your kids are, but typing in the IP instead of a youtube domain name into a browser will bypass it as well.Īs far as the youtube app goes, try the lines I suggested and see. same thing if you're not intercepting DNS queries and a device uses a server other than your local dnsmasq. If a device has the correct dns response for *. cached already ( more likely for a mobile device that switches over to the providers internet access when off of wi-fi ) it may very well just open a connection directly to the IP which renders this approach useless. Note that using this method in general isn't very reliable. This will return a dns response of 127.0.0.1 for and any of its subdomains ( *. ).

To see all the details open up the details in the packet details pane, or, if using TShark, add the -V flag to get verbose output.Click to expand.That config line can be bypassed simply by using instead of in a browser. You're capturing these packets and they're dissected right there. Note: I think you'll see the proper ordering is UDP packet first, and in response you'll see the ICMP packetĪs for the question on what you should do to read the contents of the packets, you're already doing that. Otherwise the network stack at the destination node wants to inform you that the destination is unreachable, because the (UDP) port is unreachable (or rather, it's closed). This succeeds iff there's a proces at the destination node which has opened that UDP port. This packet is used to transport a datagram over IP to the destination node at a specific UDP port. When sending out ICMP echo packets you get a reply, so that's good.

One The use of ping shows you that basic IP networking between the nodes is possible. These two observations are only partly related.

Wireshark captures googlevideos