Use tcpdump to find out tablet's OTA update server


I have an Android tablet, specifically an Amazon Fire HD 10, and want to block it from contacting its over-the-air update servers.

Unfortunately, this blocking cannot be implemented in the tablet itself (was possible in Fire OS version, but no longer in, and so I want to use my OpenWrt router's firewall rules to block all connections to Amazon's update servers.

To do that, I first need to find out what the domain or IP address of those servers are.

So my plan is to give WiFi connection to the tablet in its out-of-the-box condition and use the tcpdump command to capture (trace) all connections to and from the tablet.

It seems to me the particular command to use would be:

tcpdump host

where is the IP address of the tablet.

Once the command gives me the outside hosts contacted by the tablet, I would then set up firewall rules blocking connections to those hosts.

The question is: Is that the right tcpdump command?

Just to put the question in context, I am not a "computer person" at all and have often had the experience of having it turn out that what looked to me like the obviously right thing to do was completely wrong.

Please give the heads-up too if another part of the plan is plain crazy. For example:

  • I realize that the plan assumes that the tablet will never go to Internet except through my own router.
  • Some people say that the plan will fail once Amazon changes the update server's address. But here, I don't see how the table would know what the future (new) server addresses will be. (Short of Amazon's having loaded the OS with "future looking" server addresses, some of which are unused today but are gradually activated over the years. But why? Just to defeat someone like me?)
1 Like

my daughters light bulbs stop working if they lose internet access for a few days... just sayin...

if amazon wont let you disable in the UI... then odds are that you'll be getting some fun side effects if/when you block it upstream...

consider ditching amazon for an Honorable user respecting vendor


Yes, already considering. It was only $75 though.

1 Like

yeah capture it to a file (on tmp) and scp/open on wireshark on a pc so you can

  • sort it and
  • look for sparser flows
  • exclude known media flows

etc. etc.

tcpdump -i $interface -w /tmp/capture0.1
  • if you want to filter at the capture stage do it by mac not ipv4
  • power cycling the device is probably a good way to induce more 'control' trafiic... if there are no update buttons in the OS

you may also try wiresharkhelper which is ipv4 only but skips the step of having to copy the file to pc... and you can watch in realtime

echo -e -n 'untrusted comment: OpenWrt usign key of Stan Grishin\nRWR//HUXxMwMVnx7fESOKO7x8XoW4/dRidJPjt91hAAU2L59mYvHy0Fa\n' > /etc/opkg/keys/7ffc7517c4cc0c56
sed -i '/stangri_repo/d' /etc/opkg/customfeeds.conf
! grep -q 'stangri_repo' /etc/opkg/customfeeds.conf && echo 'src/gz stangri_repo' >> /etc/opkg/customfeeds.conf
opkg update
opkg install luci-app-wireshark-helper
1 Like

Thank you. I'd never have thought of capturing to file in a million years.

Staying with the scp method for now, should my command look like:

tcpdump -i eth0 ether host aa:bb:cc:11:22:33 -w /tmp/capture0.1

Note. When I run ip addr I get: lo, eth0, br-lan, eth0.1, eth0.2, wlan1.

use br-lan probably... just try them all and see what happens... you cant break anything...

after you get the hang of it an know what you are looking for... you will probably want the -nn or whatever stops dns resolutions of addresses... but its probably handy to see names at this point...

1 Like

Thank you again.

With luci-app-wireshark-helper, I presume that installing it (per your instruct) will give me a new menu item in Luci and that, once I am there, it'd be all intuitive click and choose?

yeah... intuitive...

  • interface
  • ip of pc to send to (the one running wireshark)
  • ip you are going to capture (maybe... this is easily done in wireshark with a small filter line... that's the hardest bit)


In the Wireshark app, set the filter to the monitored IP, for example if the IP of the device you want to sniff packets to/from is, then set the Wireshark filter to
(ip.src == || (ip.dst ==
1 Like

another option might be to sign up for cloudshark.

the traffic data will be sent to their servers, and is browsable online.

free accounts last 30 days, which should be more than enough.

don't forget to install the cshark package.



ntop is fantastic for this kind of thing cause all the specific connections per host are grouped...

capture for a day or two and all the connections are at your fingertips without having to squint your eyes... and dig down to the packet level...

1 Like

Does 'ntop' refer to this:

Am I right to understand:

  • cloudshark and ntop are equivalent services.
  • Both take the place of wireshark.
  • ntop does "grouping by host," which cloudshark or wireshark does not?

Sorry. I have not even used wireshark (haven't heard of it till just now), and it's not easy for me to visualize as yet.

cloudshark will probably do similar to what ntop does... the way they acquire their data is slightly different...

ntop is not available for openwrt... but if you run it on the pc you are sending wireshark helper stuff to... it will work...

1 Like

doesn't probably matter, since you should be able to set a filter, based on MAC/IP anyway ...


If you capture the packets as the device tries to update, aren't you risking that the device could update?

1 Like

Well yes.

I am trying to catch the device while it goes, "Let's see any more update? Okay I guess not."

For now, I have already updated to the latest (and bad) (when I didn't know what I was doing). I am trying not to update to the next (and potentially even worse) version.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.