Wrong IP Source Address Using pppd on Solaris 2.8 - PPP

This is a discussion on Wrong IP Source Address Using pppd on Solaris 2.8 - PPP ; Hi, I have a very strange problem: I have a Solaris 2.8 box with a pppd interface and an ethernet interface. The ethernet interface talks with the LAN and the PPP interface is only used to communicate with an embedded ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Wrong IP Source Address Using pppd on Solaris 2.8

  1. Wrong IP Source Address Using pppd on Solaris 2.8

    Hi,
    I have a very strange problem: I have a Solaris 2.8 box with a pppd
    interface and an ethernet interface. The ethernet interface talks with
    the LAN and the PPP interface is only used to communicate with an
    embedded system. Each interface is on a different network;
    144.121.135.8 for the ethernet and a 172.16.0.1 for the PPP.

    LAN <---> ethernet <--- Solaris 2.8 ---> PPP <---> Embedded System

    When I bring up the PPP interface to the embedded system I can see the
    IP address of the Solaris box's PPP interface (172.16.0.1) and the IP
    address of the embedded system's IP interface (172.16.0.8) being
    successfully negotiated through IPCP.

    However when I then try to send IP datagrams over the PPP interface to
    the embedded system, the source address in the IP datagram header is
    the address of the Solaris box's ethernet interface (144.121.135.8)!

    Has anyone seen a problem like this before? Any help would be
    appreciated.

    Regards,

    Ben

  2. Re: Wrong IP Source Address Using pppd on Solaris 2.8

    Benjamin M. Stocks writes:
    > I have a very strange problem: I have a Solaris 2.8 box with a pppd
    > interface and an ethernet interface. The ethernet interface talks with
    > the LAN and the PPP interface is only used to communicate with an
    > embedded system. Each interface is on a different network;
    > 144.121.135.8 for the ethernet and a 172.16.0.1 for the PPP.
    >
    > LAN <---> ethernet <--- Solaris 2.8 ---> PPP <---> Embedded System
    >
    > When I bring up the PPP interface to the embedded system I can see the
    > IP address of the Solaris box's PPP interface (172.16.0.1) and the IP
    > address of the embedded system's IP interface (172.16.0.8) being
    > successfully negotiated through IPCP.
    >
    > However when I then try to send IP datagrams over the PPP interface to
    > the embedded system, the source address in the IP datagram header is
    > the address of the Solaris box's ethernet interface (144.121.135.8)!
    >
    > Has anyone seen a problem like this before? Any help would be
    > appreciated.


    I've run the opposite configuration, i.e., ethernet to embedded system,
    ppp to rest of world, and I've not seen this problem. One change that
    I made to /etc/init.d/inetinit was:

    ***************
    *** 18,23 ****
    --- 18,28 ----
    ndd -set /dev/tcp tcp_old_urp_interpretation 1

    #
    + # Set default ip_forwarding to OFF.
    + #
    + ndd -set /dev/ip ip_forwarding 0
    +
    + #
    # Configure default routers using the local "/etc/defaultrouter"
    # configuration file. The file can contain the hostnames or IP
    # addresses of one or more default routers. If hostnames are used,

    That disallows forwarding between interfaces and should force the
    box to act like a host (end system) instead of a router. You may
    also need to issue this command too:

    ndd -set /dev/ip ip_strict_dst_multihoming 1

    Here's Sun's description:

    If a machine has two interfaces, the following commands will drop
    packets coming in through one interface that are destined for another
    interface. This can prevent host spoofing. This enables the 'strong
    end system' model from RFC 1122.

    A host that obeys the 'strong end system' model should always set the
    source address of an IP datagram it originates to the IP address of
    the outgoing interface.

    HTH,

    nobody

  3. Re: Wrong IP Source Address Using pppd on Solaris 2.8

    James Carlson wrote in message news:...
    > nobody writes:
    > > Benjamin M. Stocks writes:
    > > > However when I then try to send IP datagrams over the PPP interface to
    > > > the embedded system, the source address in the IP datagram header is
    > > > the address of the Solaris box's ethernet interface (144.121.135.8)!

    >
    > If your application doesn't call bind(3SOCKET) for that address (that
    > is, it's not specifically asking to have that source address), then


    It is not

    > that sounds like it could be a bug. It's not one I've ever seen,
    > though. Could you please post (or send me) 'netstat -navr', 'netstat
    > -na', and 'uname -a' output when the problem is happening?


    Tried '#touch /etc/notrouter' and that did not resolve the issue.

    Here is the output from the uname -a:
    SunOS australia 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-4

    Here is the output from netstat -navr (144.131.215.5 is the ethernet
    interface's address and 172.16.0.1 is the PPP interface's address):

    IRE Table: IPv4
    Destination Mask Gateway Device Mxfrg
    Rtt Ref Flg Out In/Fwd
    -------------------- --------------- -------------------- ------ -----
    ----- --- --- ----- ------
    172.16.0.18 255.255.255.255 172.16.0.1 sppp0
    1500* 0 1 UH 1 0
    144.131.0.0 255.255.0.0 144.131.215.5 hme0
    1500* 0 1 U 28 0
    224.0.0.0 240.0.0.0 144.131.215.5 hme0
    1500* 0 1 U 0 0
    default 0.0.0.0 144.131.215.1
    1500* 0 1 UG 25 0
    0.0.0.0 255.255.255.255 144.131.215.5 hme0
    8192* 0 1 UHB 0 0
    0.0.0.0 255.255.255.255 144.131.215.5 hme0
    1500* 0 1 UHB 0 0
    144.131.0.0 255.255.255.255 144.131.215.5 hme0
    8192* 0 1 UHB 0 0
    144.131.0.0 255.255.255.255 144.131.215.5 hme0
    1500* 0 1 UHB 0 0
    144.131.255.255 255.255.255.255 144.131.215.5 hme0
    8192* 0 1 UHB 6 0
    144.131.255.255 255.255.255.255 144.131.215.5 hme0
    1500* 0 1 UHB 6 0
    172.16.0.18 255.255.255.255 -- sppp0
    1500* 0 2 UHA 3 0
    172.16.0.1 255.255.255.255 -- sppp0
    8232* 0 1 UHL 0 0
    144.131.215.5 255.255.255.255 -- hme0
    8232* 112 25 UHL 3223 202
    144.131.215.6 255.255.255.255 -- hme0
    1500* 0 2 UHA 18 0
    255.255.255.255 255.255.255.255 144.131.215.5 hme0
    8192* 0 1 UHB 0 6
    255.255.255.255 255.255.255.255 144.131.215.5 hme0
    1500* 0 1 UHB 0 0
    127.0.0.1 255.255.255.255 127.0.0.1 lo0
    8232* 522 11 UH 2320 0

    From the netstat -na, the line of real interest under the TCP IPv4
    section was:
    144.131.215.5.32963 172.16.0.18.2602 0 0 24820 0
    SYN_SENT

    The source of the socket opened to the node on the other side of the
    PPP interface is the ethernet device?

    Thanks for any help you can give, I'm stumped!

  4. Re: Wrong IP Source Address Using pppd on Solaris 2.8

    stocksb@ieee.org (Benjamin M. Stocks) writes:
    > > that sounds like it could be a bug. It's not one I've ever seen,
    > > though. Could you please post (or send me) 'netstat -navr', 'netstat
    > > -na', and 'uname -a' output when the problem is happening?

    >
    > Tried '#touch /etc/notrouter' and that did not resolve the issue.


    I wouldn't expect it to fix anything at all. That was in response to
    the other poster's recommendation to turn off IP forwarding. I don't
    think IP forwarding has anything to do with the problem, but if it
    did, editing the /etc/init.d/* scripts isn't how it's administered.

    Sorry for the confusion.

    > Here is the output from the uname -a:
    > SunOS australia 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-4
    >
    > Here is the output from netstat -navr (144.131.215.5 is the ethernet
    > interface's address and 172.16.0.1 is the PPP interface's address):


    OK; nothing looks wrong there.

    > From the netstat -na, the line of real interest under the TCP IPv4
    > section was:
    > 144.131.215.5.32963 172.16.0.18.2602 0 0 24820 0
    > SYN_SENT
    >
    > The source of the socket opened to the node on the other side of the
    > PPP interface is the ethernet device?
    >
    > Thanks for any help you can give, I'm stumped!


    As am I. I set up exactly the same system configuration on Solaris 8
    (with a link intentionally going nowhere), and I got this:

    172.16.0.1.50023 172.16.0.18.23 0 0 25920 0 SYN_SENT

    I wasn't able to get the source address to be incorrect.

    One more thing to check:

    # ndd /dev/ip ipv4_ire_status | fgrep 172.016.000.018 | grep CACHE

    The entry that it prints out should have the source address that the
    system plans to use for any connection to that destination. I see
    this in my test:

    30001f46908 0 300034f2818 172.016.000.018 255.255.255.255 172.016.000.001 000.000.000.000 01480 00000 000000 00000000 002 000000 000000000 000000000 000000 00000000 0000 00000000 00000000 0/4/0 CACHE
    ^^^^^^^^^^^^^^^ dest ^^^^^^^^^^^^^^^ src

    If that shows the correct source address, then I would look into
    whether the application is doing an unexpected bind(3SOCKET) call.
    Use something like this:

    # truss -f -vbind -tbind /my/application/here args...

    You're not setting anything unusual on this system, such as 'ndd
    /dev/ip ip_enable_group_ifs', SunScreen, or perhaps IP-Filter are you?

    If you can, please file a bug.

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: Wrong IP Source Address Using pppd on Solaris 2.8

    stocksb@ieee.org (Benjamin M. Stocks) writes:
    > I don't know if this will help but its Solaris 8 (2/02) running on an
    > E450 without the Maintenance Update 7 (2/02).


    The exact revision should be included with the information for the
    problem report.

    > The system was also
    > installed slightly incorrectly according to our instructions (64-bit
    > support snuck in) so that isainfo returns:
    > # isainfo -v
    > 64-bit sparcv9 applications
    > 32-bit sparc applications


    I'm not sure what you mean by that. When you see both 64-bit and
    32-bit application support, it means that the kernel itself is running
    in 64-bit mode. If you really want only 32-bit support, then boot
    "kernel/unix".

    > If none of these should make a difference we'll see if we can recreate
    > the problem on a second machine and if we can we'll file a bug.


    No, neither _should_ be an issue.

    Unless there's a reason to think that there's some sort of corruption
    problem (which doesn't seem likely to me in this case) or a bad patch
    (also somewhat unlikely), I don't think that testing on a second
    machine is going to help, but if it's easy, it wouldn't hurt.

    > We did get around the problem by employing a MacGyver scotch tape and
    > bubblegum solution: we gave the PPP interfaces addresses from the same
    > network as the Ethernet card and things started working.


    The local address on the PPP link can safely be the same address as
    used on the Ethernet interface. Point-to-point links don't need
    distinct local addresses.

    > So it
    > definetly looks like our application is getting bound to the Ethernet
    > card's network addresss.


    The question of how this could be happening remains. Without seeing
    more detailed debug information (such as a truss of the process that
    creates the socket), I'm left wondering if it's something that the
    application itself is doing.

    Does the same unexpected source address show up when the bundled
    applications (e.g., /usr/bin/telnet) are used?

    There's another issue here: why does it matter? What's the routing
    situation on that PPP peer? Why doesn't that peer consider the PPP
    link to be a return path for the IP address that gets used? And why
    does it consider the "other" IP address (when you move them into the
    same "subnet") to be ok? It doesn't think that point-to-point links
    have subnets associated with them, does it?

    --
    James Carlson, Solaris Networking
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  6. Re: Wrong IP Source Address Using pppd on Solaris 2.8

    > We did get around the problem by employing a MacGyver scotch tape and
    > bubblegum solution: we gave the PPP interfaces addresses from the same
    > network as the Ethernet card and things started working.


    The only issue I could see is if we use an address that is in use on
    the Ethernet's network, we wouldn't be able to reach it while the PPP
    interface is up. Not an issue if we take unassigned addresses.

    > The question of how this could be happening remains. Without seeing
    > more detailed debug information (such as a truss of the process that
    > creates the socket), I'm left wondering if it's something that the
    > application itself is doing.


    I would send a truss but the application is so gawd-awful large that
    finding useful information in it would be very difficult. I doubt its
    something the application is doing, intentionally at least. We can
    install the software on a different machine and it works just fine.

    > There's another issue here: why does it matter? What's the routing
    > situation on that PPP peer? Why doesn't that peer consider the PPP
    > link to be a return path for the IP address that gets used? And why
    > does it consider the "other" IP address (when you move them into the
    > same "subnet") to be ok? It doesn't think that point-to-point links
    > have subnets associated with them, does it?


    The issue is that the PPP peer is an embedded system that uses an
    older protocol stack, when it installs the PPP interface in its
    routing table it applies a classful mask to the address it received
    and enters that network in its routing table. So if we negotiate a
    172.16.x.x address over IPCP, but then send it traffic from 144.x.x.x,
    it doesn't know to route them back on the PPP link.

    I'll advise the engineer who works closest with the Sun platform
    itself that we should submit a bug.

    Thanks for your time and help!

+ Reply to Thread