-
-
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). |
Found this post because I was investigation a 192.168.49.1 on my home network.
Looks like its the FireTv advertising that it has the capability to receive media casts.
Related: https://github.com/jloutsenhizer/CR-Cast/wiki/Chromecast-Implementation-Documentation-WIP#dialssdp
HTTP/1.1 200 OK
USN: uuid:<UUID here>::urn:dial-multiscreen-org:service:dial:1
CACHE-CONTROL: max-age=1800
EXT:
ST: urn:dial-multiscreen-org:service:dial:1
LOCATION: http://<IP of fireTV>:38729/upnp/dev/<UUID here>/desc
SERVER: Linux/3.10.61 UPnP/1.0 Cling/2.0
I just opened Chrome in Incognito Mode and my firewall picked up 192.168.49.1 trying to connect to my computer.. We've got a FireStick here as well. I just let it sit there, then it went away. How interesting.
Latest update of Little Snitch started alerting me of incoming connections to Chrome from this IP (on my 10.1.1.x network). Weird. Thanks for doing the work to identify this, saved me a bunch of work!
Same here. Last Little Snitch update alerted me of Chrome connection to 192.168.49.1 on random UDP ports: 49872, 56508, 64666, etc.
I recall now having had this issue in the past but must've forgotten I added to the accepted list.
FireStick here as well.
Getting the same thing with Little Snitch picking up incoming traffic (specifically to Google Chrome - usually use Safari, but when I started Chrome for something the LS alert popped up). I have an Amazon Fire TV on the network (haven't used it in quite a while). And yeah, it's a 10.0.1.x/24 network, so the 192.168.49.1 address is completely out of place. I'm guessing that Chrome must have broadcast something on the local network that elicited this response from the Fire TV.
And thanks to the OP for being easy to find via a Google (ha!) search for "Incoming connections from 192.168.49.1".
Another Little Snitch user. :) This seems so broken. The source IP is bogus and not reachable, so I don't get what this is supposed to accomplish.
Verbose dump of a packet:
Frame 32: 358 bytes on wire (2864 bits), 358 bytes captured (2864 bits) on interface 0
Interface id: 0 (en0)
Encapsulation type: Ethernet (1)
Arrival Time: Sep 29, 2017 13:26:37.349179000 EDT
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1506705997.349179000 seconds
[Time delta from previous captured frame: 1.554922000 seconds]
[Time delta from previous displayed frame: 1.554922000 seconds]
[Time since reference or first frame: 844.432111000 seconds]
Frame Number: 32
Frame Length: 358 bytes (2864 bits)
Capture Length: 358 bytes (2864 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:data]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: AmazonTe_a8:91:52 (0c:47:c9:a8:91:52), Dst: 1c:1b:0d:6a:1c:38 (1c:1b:0d:6a:1c:38)
Destination: 1c:1b:0d:6a:1c:38 (1c:1b:0d:6a:1c:38)
Address: 1c:1b:0d:6a:1c:38 (1c:1b:0d:6a:1c:38)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: AmazonTe_a8:91:52 (0c:47:c9:a8:91:52)
Address: AmazonTe_a8:91:52 (0c:47:c9:a8:91:52)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.49.1, Dst: 10.3.2.40
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 344
Identification: 0xdd0a (56586)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x5eb6 [validation disabled]
[Good: False]
[Bad: False]
Source: 192.168.49.1
Destination: 10.3.2.40
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 36730 (36730), Dst Port: 61172 (61172)
Source Port: 36730
Destination Port: 61172
Length: 324
Checksum: 0x5fd0 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[Stream index: 7]
Data (316 bytes)
Data: 485454502f312e3120323030204f4b0d0a55534e3a207575...
Text [truncated]: HTTP/1.1 200 OK\r\nUSN: uuid:e7b784b8-cc6c-170c-ffff-ffffea61377c::urn:dial-multiscreen-org:service:dial:1\r\nCACHE-CONTROL: max-age=1800\r\nEXT: \r\nST: urn:dial-multiscreen-org:service:dial:1\r\nLOCATION: http://10.3.2.
[Length: 316]
And the data chunk:
HTTP/1.1 200 OK
USN: uuid:e7b784b8-cc6c-170c-ffff-ffffea61377c::urn:dial-multiscreen-org:service:dial:1
CACHE-CONTROL: max-age=1800
EXT:
ST: urn:dial-multiscreen-org:service:dial:1
LOCATION: http://10.3.2.64:35569/upnp/dev/e7b784b8-cc6c-170c-ffff-ffffea61377c/desc
SERVER: Linux/3.10.61 UPnP/1.0 Cling/2.0
Adding to the pile, and ended up here via google... and also, yes a firestick + littlesnitch.
+1 little snitch and an Amazon FireTV (device, not stick). This is not good design. I have no 192.168.x.x addresses on my network, and pings to the 192.168.49.1 IP get no returns, yet there it is mysteriously on my internal network periodically sending unsolicited packets to my laptop whenever Spotify is running. Thanks for the work finding this.
+1 little snitch and an Amazon FireTV
I think this is something to do with wifi-direct network feature on the FireTV, but i could be wrong
I just installed little snitch and was alerted to incoming connections to Google Chrome from 192.168.49.1, which is an IP range that I'm not using on my home network 172.30.0.x. A google search led me to this page, and I can confirm I also have a FireTV.
I disabled the "Local Media Router Component" extension in Chrome (chrome://flags/#load-media-router-component-extension) and restarted and the messages did not appear again.
And thanks to the OP for being easy to find via a Google (ha!) search for "Incoming connections from 192.168.49.1".
+1
+1
Same here, Little Snitch blocks some bogus UDP connection which trys to connect to my browser (Vivaldi). Seems really odd, but good to know, will be blocked now as rule. Thanks!
Yep another one here same Little Snitch + Firetv and found this via Google...at least it explains it thanks to OP!
+1 for this.
I bought a FireTV last week for the first time and Little Snitch has been working over time. I am seeing alerts every couple of minutes from 192.168.49.1 to multiple posts -- 49276, 50622, and 54842.
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:
- Laptop
-- 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. - FireTV
-- 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!
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
Did you ever find any additional info? My Debian router's arpwatch lead me to your post. I have (2) amazon firesticks and they both have this bogus IP and I get flip-flop alerts from them. Very annoying.