dheeraj@nile.cs.umd.edu (Dheeraj Sanghi) (08/22/89)
Hi, I want to know what happens when I set the IP_LSRR option. Let us assume a client-server model. The client just sends some fixed number of packets to the server. The client wants to route the data via gateway X, and the server wants to route the acks via gateway Y. Client calls setsockopt and gives the next hop as X and 2nd hop as the machine running the server, and everything goes fine. Now, server doesn't know which machine is going to connect to it, so it can't set the LSRR option, it would seem. What I am doing is setting the next hop to be Y, and setting the final hop to be a random number. Surprisingly, I do get the acks and the data goes through fine. Now I tried to look into the TCP/IP code (4.3 BSD) to see if somewhere it "fixes" the final hop, but I don't seem to find any such code. Would anyone explain me what's happening? To me it seems, that the server should just send the ack packet to Y, which can't send the packet any further (after all it sees an address, it doesn't know about, I am using 0.0.0.1 as the "random number") thanks in advance, -dheeraj Dheeraj Sanghi (h):301-345-6024 (o):301-454-1516 Internet: dheeraj@cs.umd.edu UUCP: uunet!mimsy!tove!dheeraj Namaste sada vatsale matrabhume, Twaya hindubhume sukham vardhitoham.
dab@opus.cray.com (Dave Borman) (08/22/89)
> I want to know what happens when I set the IP_LSRR option. > Let us assume a client-server model. The client just sends some fixed > number of packets to the server. The client wants to route the data > via gateway X, and the server wants to route the acks via gateway Y. > Client calls setsockopt and gives the next hop as X and 2nd hop as > the machine running the server, and everything goes fine. Now, server > doesn't know which machine is going to connect to it, so it can't > set the LSRR option, it would seem. What I am doing is setting the > next hop to be Y, and setting the final hop to be a random number. > Surprisingly, I do get the acks and the data goes through fine. > > Now I tried to look into the TCP/IP code (4.3 BSD) to see > if somewhere it "fixes" the final hop, but I don't seem to find any > such code. Would anyone explain me what's happening? To me it seems, > that the server should just send the ack packet to Y, which can't send > the packet any further (after all it sees an address, it doesn't know > about, I am using 0.0.0.1 as the "random number") > > thanks in advance, > > -dheeraj > > Dheeraj Sanghi (h):301-345-6024 (o):301-454-1516 The stock 4.3BSD code does not handle source route options properly. What is supposed to happen is that in the IP layer, the source route option is saved (via save_rte()), and then in tcp_input() it is retreived (via ip_srcroute()) for use in all packets being returned. Thus, the server code in userland doesn't have to do anything at all to have the correct thing happen when a source routed SYN packet arrives. If you set the source route on the socket that you are doing accept() on, that information is not copied into the new socket that is created when a new connection is received. If you do a setsockopt() to set the LSRR option on the new connection after the accept(), you will wipe out the dynamically created LSRR option (if it was created), and you will know the destination address, because it is handed to you in the accept() call. There are two problems in the stock 4.3BSD code. The first is that the source route is not correctly reversed. The final destination address was put at the beginning of the reversed route, not at the end. However, due to a second bug, the fact that the offset into the route was not reset, but left pointing to the end of the option, a loose source route would actually get a reply to it, but the returned packet would not be source routed. Strict source routes did not work. -Dave Borman, dab@cray.com