Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2386 closed Bug (wontfix)

Mac client talking to itself on en0

Reported by: blaked36 Owned by: livings124
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.74
Severity: Normal Keywords: loopback lo* en0 ipfw


I use ipfw, and I have a rule set to allow the computer to talk to itself via loopbacks (i.e., "allow ip from any to any via lo*"). Conversely, I have a rule to deny any other traffic "from me to me" in order to prevent possible spoofing. Transmission commonly gets caught by that rule and is clearly trying to talk to itself on en0 rather than a loopback. Is there a reason for this? What information is being communicated there? Transmission is otherwise working.

Change History (10)

comment:1 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from new to closed

This happens to other clients as well. What's happening is the tracker sends you back your own address in the peer list of IP addresses, and there's not a way to get your public IP address that's all 3 of: simple, reliable, portable.

comment:2 Changed 12 years ago by livings124

  • Component changed from Mac Client to Transmission

comment:3 Changed 12 years ago by Waldorf

  • Resolution invalid deleted
  • Status changed from closed to reopened

I might have a valid suggestion for your "3":

comment:4 Changed 12 years ago by livings124

We can't feasibly be querying a website all the time for that.

comment:5 Changed 12 years ago by Waldorf

Actually, I have no idea why you'd want to do this, or wether this would be necessary, but you could fetch the IP at startup?

comment:6 Changed 12 years ago by livings124

  • Resolution set to wontfix
  • Status changed from reopened to closed

That says it all.

comment:7 Changed 12 years ago by blaked36

Hmmm... I'm still not sure I understand. I get that my public IP address would be in the list of peers, but the address I'm seeing is the private IP behind NAT: from (me) to over en0. Can you elaborate? Also, is there any drawback to not allowing that traffic? As I said, Transmission otherwise seems to be working. Thanks!

comment:8 Changed 12 years ago by blaked36

Actually, maybe I do get it. Please clarify if I'm right. Transmission is actually sending an outbound packet from (me, private) to whatever my public IP happens to be at the time. The router sees the packet's destination is to itself (the WAN side public IP address), translates it back to the private address, then sends it back to me. Correct? That makes sense and explains a lot if I've got it right.

I'm still curious about any drawbacks to blocking the traffic, though. Thanks. This has been enlightening.

comment:9 follow-up: Changed 12 years ago by John Clay

I'm not quite sure how to explain this, other than rehashing what's already been said. The tracker is sending out a list of peers, of which you are one. Not knowing what your external IP address is, Transmission attempts to contact itself. Once the connection is established, and Transmission realizes that it's talking to itself, it hangs up. Unless you've got a subnet setup, your router isn't going to handle any external IPs within the NAT. It's going to translate the forwarded port into a LAN IP (your, and send the packet on its way.

There aren't any drawbacks to the end result of blocking self-direct traffic, but there isn't an easy, reliable, and portable way of creating that block. You'd need to verify the port being used, IP address, etc before blocking. It's simply not worth the time and effort.

comment:10 in reply to: ↑ 9 Changed 12 years ago by blaked36

If you mean that it's not worth the time and effort to get Transmission itself to block the traffic, I agree. My concern was that I'm already blocking the self-directed traffic as a side-effect of one of my ipfw rules to prevent spoofing: "deny log ip from me to me". So blocking the traffic is quite easy, from that perspective, but it wasn't my intent. Apparently it's not an issue, from what everyone here is saying, so I'm not going to worry about unblocking that traffic.

I'm afraid the last two sentences of your first paragraph don't make much sense from a networking perspective. What do you mean by, "Unless you've got a subnet setup"?

Let me see if I can clarify what I now understand is happening, step by step, for anyone getting lost reading this. Let's say my public IP address is, and my private address is, with NAT translation obviously being handled at the router. Let's also say Transmission is configured to use port 55555 at the transport layer. Since Transmission sees as a peer--and doesn't know that the address leads to itself--it attempts to talk to that address. The packet Transmission sends is addressed to, from It is received by the router, which sees the destination IP address of in the packet header and compares that address to its routing table. It then recognizes that the packet is destined for itself (that is, the router--specifically, the router's WAN side address of Examining the TCP or UDP segment header, the router sees the destination port number of 55555. Consulting its port forwarding configuration for that port, it finds the NAT translation of --> and readdresses the packet for Because the packet is not routed out onto the WAN, NAT translation is not done on the source IP address of the packet, which is left at, only the destination address. The packet is then sent from the router back to the host computer (source, destination, where it is received by Transmission.

Actually, looking at that explanation, one way Transmission could block the outbound traffic at least part of the time is to simply look at the port number. If I'm using port 55555 and my peer is using port 55555, then the peer is me. The only time you'd run into trouble is if more than one peer is using the same port (unlikely, but possible), in which case Transmission could simply allow the traffic. Still, I agree that it's not really worth the trouble. But it is interesting.

Note: See TracTickets for help on using tickets.