UDP packet strange behavior

Discussion in 'Linux Networking' started by richard.krehbiel, Aug 10, 2006.

  1. (Fedora Core 4)

    I've got a computer A with two Ethernets, connected to two distinct
    networks (one corporate, one for development only). I make a socket
    for UDP, and I "connect" this socket to a the IP of computer B that's
    reached via one of those interfaces.

    So I "send" one packet. Recipient B gets it, but it's source IP names
    A's other interface! The recipient has no route to get a reply packet
    back.

    I "send" another packet. This time I get errno=113 - network
    unreachable.

    What is going on?
     
    richard.krehbiel, Aug 10, 2006
    #1
    1. Advertisements

  2. richard.krehbiel

    Rick Jones Guest

    I suspect that when you called connect() on your datagram socket, it
    did the implicit bind for you but happened to do it to the other IP on
    the system. But you probably already figured-that out.

    To be certain of the source IP, you probably need to bind() to it
    first before you call connect(). Doing so will make your application
    no longer dependent on stack-specific behaviour such as whether or not
    it is a "strong" or a "weak" end-system model.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
     
    Rick Jones, Aug 10, 2006
    #2
    1. Advertisements

  3. How is one computer supposed to know that the other can only reach it
    using one particular interface? By what magic would you expect this to
    automatically work?
     
    David Schwartz, Aug 11, 2006
    #3
  4. I had expected it to supply the IP of the interface that transmitted
    the packet.
     
    Richard Krehbiel, Aug 11, 2006
    #4
  5. richard.krehbiel

    Lew Pitcher Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1


    Please, on your Linux "computer A",
    echo 1 >/proc/sys/net/ipv4/ip_forward
    and try again

    - --
    Lew Pitcher

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

    iD8DBQFE3HV7agVFX4UWr64RAoT0AJ4+D3oF+7HTMAZY3IpMg4IsQO0OfgCeK85Z
    vP814x9OKnzshJ1dv58+aI0=
    =lyDQ
    -----END PGP SIGNATURE-----
     
    Lew Pitcher, Aug 11, 2006
    #5
  6. Actually, I probably shouldn't. I'm not allowed to route packets from
    one interface to the other. The development network is supposed to be
    somewhat isolated from the production network (and my machine's
    existence on both is barely tolerated).

    OTOH, the IP addresses don't overlap, and I'm sure I could achieve the
    same effect with iptables. But ip_forward=0 was just so much easier...
     
    Richard Krehbiel, Aug 11, 2006
    #6
  7. richard.krehbiel

    Rick Jones Guest

    Please, on your Linux "computer A",
    Besides, by default, even without ip_forward set, the Linux system
    with two NICs will accept traffic addressed to either IP on either
    interface. The question is how to get the remote system to know to
    reach that "remote" IP it should use the first system's other IP as a
    gateway. So, that is where a static route added on the remote system
    would come into play.

    That, or having the application on the first system make that bind()
    call to bind to the IP in the subnet common to both systems.

    rick jones
     
    Rick Jones, Aug 11, 2006
    #7
  8. You should think about packets as passing through interfaces.

    Most operating systems will use the primary IP address of the "closest
    interface" when they originate a packet. They also transmit the packet
    on the closest interface. This assumes you didn't do something to
    change this, such as 'bind'ing the socket to another address.

    DS
     
    David Schwartz, Aug 11, 2006
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.