1

This shouldn't be happening since routing is IP-level phenomenon, and yet it does:

  1. Establish a TCP (or even UDP!) connection:

    nc 1.2.3.4 1234

  2. Observe that you can send and receive data via this connection by typing on console and checking the other end of the connection

  3. Create a new route

    sudo route add -reject 1.2.3.4 127.0.0.1

  4. Observe that the connection established in step 1 is still working

  5. Try creating a new connection to the same host and observe that it's not transmitting data as expected.

I've tried this many times, including with UDP sockets and the behavior is consistently reproducible. Nothing like this happens on Linux or Windows (as one would expect). The only explanation I have is that there's some special handling of TCP and UDP packets in the OS routing mechanism or something like per-process routing tables. But I can't find any mention of that anywhere. Is there documentation on this behavior and how to change it? Or an alternative explanation?

Improve this question
1
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Commented Dec 3, 2024 at 19:18

2 Answers 2

Reset to default
2

Turns out the routing information is indeed cached on per-socket basis in the BSD network stack. It's stored in a structure called inpcb (Internet Protocol Control Block?) attached to every socket. In Darwin, this is defined in bsd/netinet/in_pcb.h.

Improve this answer
2

This is actually the "expected" behavior for TCP. Since it is session oriented, when the session is started, the session is bound to an network interface and that will not changed until a new session is created at which time the "routing" table is consulted to determine which interface should be bound to the new session.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.