-
-
Save ewxrjk/93808cdab43bcc5610519bd1f1a8c577 to your computer and use it in GitHub Desktop.
| ** Please do not post any more messages which amount to "I have the same issue" with no additional information. | |
| ** I get a notification for each one and it is just noise; knowing that one more person has the same issue does | |
| ** not help anyone. If these content-free comments continue to appear I will delete this gist to cut down on | |
| ** the noise. You have been warned. | |
| Aug 21 20:02:57 sfere kernel: [107297.977252] IPv4: martian source 172.17.207.66 from 192.168.49.1, on dev br1 | |
| Aug 21 20:02:57 sfere kernel: [107297.981023] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:02:57 sfere kernel: [107298.729160] IPv4: martian source 172.17.207.66 from 192.168.49.1, on dev br1 | |
| Aug 21 20:02:57 sfere kernel: [107298.736326] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:02:58 sfere kernel: [107299.793616] IPv4: martian source 172.17.207.66 from 192.168.49.1, on dev br1 | |
| Aug 21 20:02:58 sfere kernel: [107299.797572] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:03:00 sfere kernel: [107301.109844] IPv4: martian source 172.17.207.66 from 192.168.49.1, on dev br1 | |
| Aug 21 20:03:00 sfere kernel: [107301.113650] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| "martian source 172.17.207.66 from 192.168.49.1" actually means the destination is 172.17.207.66 | |
| and the source is 192.168.49.1. | |
| 172.17.207.66 is a Windows PC. | |
| 00 04 a7 05 ac 0c is the MAC address of br1 on my router. | |
| 84 d6 d0 91 67 b4 is my Fire TV. | |
| My Fire TV's actual IP address is 172.31.59.7. | |
| Later I captured the packets involved: | |
| Aug 21 20:34:26 sfere kernel: [109187.279705] IPv4: martian source 172.17.207.14 from 192.168.49.1, on dev br1 | |
| Aug 21 20:34:26 sfere kernel: [109187.283539] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:34:27 sfere kernel: [109188.295180] IPv4: martian source 172.17.207.14 from 192.168.49.1, on dev br1 | |
| Aug 21 20:34:27 sfere kernel: [109188.299023] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:34:28 sfere kernel: [109189.272922] IPv4: martian source 172.17.207.14 from 192.168.49.1, on dev br1 | |
| Aug 21 20:34:28 sfere kernel: [109189.276742] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| Aug 21 20:34:29 sfere kernel: [109190.456286] IPv4: martian source 172.17.207.14 from 192.168.49.1, on dev br1 | |
| Aug 21 20:34:29 sfere kernel: [109190.460115] ll header: 00000000: 00 04 a7 05 ac 0c 84 d6 d0 91 67 b4 08 00 ..........g... | |
| 20:34:15.582903 84:d6:d0:91:67:b4 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 56: 172.31.59.7 > 239.255.255.250: igmp v2 report 239.255.255.250 | |
| 20:34:26.390094 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 172.31.59.7.56175 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:26.390192 00:04:a7:05:ac:0c > 84:d6:d0:91:67:b4, ethertype IPv4 (0x0800), length 388: 172.31.59.1 > 172.31.59.7: ICMP 172.17.207.14 udp port 38226 unreachable, length 354 | |
| 20:34:26.390211 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 192.168.49.1.35088 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:27.405574 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 172.31.59.7.56175 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:27.405668 00:04:a7:05:ac:0c > 84:d6:d0:91:67:b4, ethertype IPv4 (0x0800), length 388: 172.31.59.1 > 172.31.59.7: ICMP 172.17.207.14 udp port 38226 unreachable, length 354 | |
| 20:34:27.405687 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 192.168.49.1.35088 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:28.383295 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 172.31.59.7.56175 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:28.383413 00:04:a7:05:ac:0c > 84:d6:d0:91:67:b4, ethertype IPv4 (0x0800), length 388: 172.31.59.1 > 172.31.59.7: ICMP 172.17.207.14 udp port 38226 unreachable, length 354 | |
| 20:34:28.383430 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 192.168.49.1.35088 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:29.566667 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 172.31.59.7.56175 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:29.566775 00:04:a7:05:ac:0c > 84:d6:d0:91:67:b4, ethertype IPv4 (0x0800), length 388: 172.31.59.1 > 172.31.59.7: ICMP 172.17.207.14 udp port 38226 unreachable, length 354 | |
| 20:34:29.566794 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype IPv4 (0x0800), length 360: 192.168.49.1.35088 > 172.17.207.14.38226: UDP, length 318 | |
| 20:34:31.398565 00:04:a7:05:ac:0c > 84:d6:d0:91:67:b4, ethertype ARP (0x0806), length 42: Request who-has 172.31.59.7 tell 172.31.59.1, length 28 | |
| 20:34:31.399380 84:d6:d0:91:67:b4 > 00:04:a7:05:ac:0c, ethertype ARP (0x0806), length 56: Reply 172.31.59.7 is-at 84:d6:d0:91:67:b4, length 42 | |
| 172.17.207.14 is a service address (specifically, for SMTP submission) on a Linux box. | |
| The packet contents lead me to http://www.dial-multiscreen.org/ though I'm not sure why: | |
| 1) My Fire TV is sending these packets to these addresses | |
| 2) Why sometimes it sets a source address of 192.168.49.1 | |
| 239.255.255.250 is the multicast address for SSDP, a service discovery for uPnP devices, so the answer to 1 | |
| may be in there somewhere (although nothing I spotted in the packet capture really added to this point). |
One more with the same problem.
I have put an Amazon FireTV and my network does not stop receiving requests of 192.168.49.1 when I do not use that range of ip's.
As it seems the Amazon FireTV in addition to sending UPNP requests from its real IP assigned by the DHCP server, it also sends UPNP requests from 192.168.49.1.
Please do not post any more messages which amount to "I have the same issue" with no additional information. I get a notification for each one and it is just noise; knowing that one more person has the same issue does not help anyone. If these content-free comments continue to appear I will delete this gist to cut down on the noise. You have been warned.
Comments with new information are fine.
Do a tcpdump on port 60000. You'll see pairs of packets, right after each other:
35 120.847510 172.16.1.50 172.16.0.97 UDP 360 60000 → 56146 Len=318 64
36 120.848625 192.168.49.1 172.16.0.97 UDP 360 60000 → 56146 Len=318 64
37 121.337758 172.16.1.50 172.16.0.97 UDP 360 60000 → 58475 Len=318 64
38 121.338567 192.168.49.1 172.16.0.97 UDP 360 60000 → 58475 Len=318 64
Shelling into the FireTV Stick Voice, I see:
$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
7: wlan0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 172.16.1.50/16 brd 172.16.255.255 scope global wlan0
valid_lft forever preferred_lft forever
8: p2p-wlan0-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 192.168.49.1/24 brd 192.168.49.255 scope global p2p-wlan0-0
valid_lft forever preferred_lft forever
So 192.168.49.1 is an address of an interface. If someone wrote code that said, "when I receive an SSDP request, respond with a packet sent on each interface's IP address" you'd see this behavior.
But why is a packet with a source address of 192.168.49.1 being emitted on wlan0? I'm not sure. It's possible iptables is doing something weird. But I don't have root on the Fire TV, and I'd need it to look at the iptables.
Other UPnP software can have similar bugs. See xbmc/xbmc#14743
I tried attaching a wired Ethernet interface to the Fire TV. This doesn't get rid of the p2p interface:
$ ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
8: p2p-wlan0-0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 192.168.49.1/24 brd 192.168.49.255 scope global p2p-wlan0-0
valid_lft forever preferred_lft forever
9: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 172.16.2.203/16 brd 172.16.255.255 scope global eth0
valid_lft forever preferred_lft forever
and there are still martians being delivered, this time over eth0.
This looks like Amazon's bug. The last time I tried to make a detailed bug report to Amazon, they tried to divert me to "premium support" (no, I am not paying for the privilege of helping your engineers debug your buggy code) so personally I'm not inclined to report this to them. My guess is that this problem could be reproduced on a network segment solely populated with Amazon clients; you'll need a second device to issue the SSDP queries that trigger the bad responses.
A lot of UPnP code doesn't deal very well with multiple networks. I was running BubbleUPnP's transcode server on a machine running Docker, and BubbleUPnP was broadcasting "hey I'm available at IP address X" for each internal Docker bridge as X....
(In case anybody needs to fix that, see https://forum.xda-developers.com/showpost.php?p=73974270&postcount=12692; summary: specify the following variables on the Java command line.)
-Dorg.fourthline.cling.network.useInterfaces: comma-separated list of network interface names.-Dorg.fourthline.cling.network.useAddresses: comma-separated list of ipv4 ip addresses
Here is a bit of additional information. I just ran a series of tests leveraging my preferred VPN service on both the FireTV device and my laptop (five tests per device, with and without VPN). Here is what I found:
-- When the VPN is active on the laptop the alerts stop. To ensure this was the case, I deleted the Little Snitch Rules, and still no alerts.
-- Within a minute of deactivating the the VPN on the laptop, the alerts started in rapid succession.
-- When the VPN is active on FireTV the alerts stop, even with the Little Snitch Rules deleted as before.
-- Within a minute of deactivating the VPN on FireTV, the alerts reappear.
I am currently running VPN on both devices and have had no alerts the entire time taken to write this update.
I would strongly consider a quality VPN service. I have been using the same service for 5+ years (I'm a software developer and security is a must) and can say that they have done an amazing job of providing the level of security I need. The company is Private Internet Access, and their website is https://privateinternetaccess.com (this is not a referral link and I get nothing for saying this).
I've used their service on MacOS, iOS, Linux, Windows, and Android. And by the way, their Android app runs without issue on FireTV. They have a setting that will activate the VPN on startup, which is makes this something you would not have to do every time you use your device.
Apologies for the monologue!