[CLUE-Tech] OT: socket question.

[David Anselmi]

Any socket gurus out there?

Suppose I have a router with IP addresses r1 and r2 on its interfaces. 
The route to client c is r1 and to server s is r2 like so:

client(c)--------(r1)router(r2)--------(s)server

The router has routes to the r1 & r2 networks (obviously) and the 
default route is r2.

Can a program on the router send a UDP packet from r1 to s and receive 
the reply by listening on r1?  Obviously it works from r2 to s, though I 
don't know if "listening" is what it does to get the response.

Here are the gory details.  This is for the ISC DHCP relay agent.  The 
client broadcasts to get its IP address and the router unicasts it to 
the server.

The reason I ask is that the relay agent has to be set up to listen for 
DHCP on both r1 and r2.  Here's the sequence:

c: 0.0.0.0 -> 255.255.255.255 (send me an IP somebody)
r: r2 -> s (send me an IP, with an option specifying r1)
s: s -> r2 (here's your IP, with the same option)
r: r1 -> 255.255.255.255 (here's your IP)(actually this may get unicast)

So, since the agent sends from r2, it has to listen to r2 to hear the 
reply from s.  That means that is also relays any broadcasts that come 
in from r2 and s potentially gets them twice.  The agent keeps straight 
where to send the reply using the option field, but it would seem that 
the same could be done just using r1 as the source for the traffic to s.

Does the socket interface support this sort of thing?  Is it legal for 
the router to send from r1 even if it knows the destination is out r2?

The docs say the router can't be smarter about relaying without 
understanding the network topology (which would complicate it). 
Apparently this code was a hack to do testing, not really production. 
But the protocols seem to support a better way, if the APIs allow that 
sort of thing.

Thanks for listening.

Dave