The relation between MUX and END? - VxWorks

This is a discussion on The relation between MUX and END? - VxWorks ; Dear All, Could anyone explain the relationship between MUX and END? If there are two ENDs (interfaces) attached to MUX, one END works as LAN Port (I called it L_END) and another works as WAN port (I called it W_END). ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: The relation between MUX and END?

  1. The relation between MUX and END?

    Dear All,
    Could anyone explain the relationship between MUX and END?

    If there are two ENDs (interfaces) attached to MUX, one END works as
    LAN Port (I called it L_END) and another works as WAN port (I called
    it W_END). (In router mode)

    And I do below test.
    PC1----ping-----> PC2

    But I do know the packets flow in vxWorks.

    I think the packet flow may be:
    ping request : PC1 ==> L_END_recv() --> muxRecv() --> muxSend() --
    > W_END_send() ==> PC2

    ping reply: PC2 ==> W_END_recv() --> muxRecv() --> muxSend()
    --> L_END_send() ==> PC1


    Is it right?


    Thanks for Your help,


    Best Regards,




  2. Re: The relation between MUX and END?

    On Apr 23, 8:46 pm, "Raymond.Lin" wrote:
    > Dear All,
    > Could anyone explain the relationship between MUX and END?
    >
    > If there are two ENDs (interfaces) attached to MUX, one END works as
    > LAN Port (I called it L_END) and another works as WAN port (I called
    > it W_END). (In router mode)
    >
    > And I do below test.
    > PC1----ping-----> PC2
    >
    > But I do know the packets flow in vxWorks.
    >
    > I think the packet flow may be:
    > ping request : PC1 ==> L_END_recv() --> muxRecv() --> muxSend() --> W_END_send() ==> PC2
    >
    > ping reply: PC2 ==> W_END_recv() --> muxRecv() --> muxSend()
    > --> L_END_send() ==> PC1
    >
    > Is it right?
    >
    > Thanks for Your help,
    >
    > Best Regards,


    *sigh* What _VERSION_ of VxWorks are you using? (Yes, this matters.
    No, I can't guess.)

    END drivers sit below the MUX. Network protocols sit above the MUX.
    The MUX allow you to bind multiple protocols to the same physical
    network interface. (muxReceive() looks at the protcol field in the
    ethernet header and dispatches the frame to a protocol that matches.)

    Your diagram is basically correct, but missing some steps:

    ping request : PC1 ==> L_END_recv() --> muxRecv() --> ip_input() -->
    ip_forward() --> ip_output() --> muxSend() --> W_END_send() ==> PC2

    Note: this is true of VxWorks 6.4 and earlier. In VxWorks 6.5 and
    later, the BSD-derived coreip stack has been replaced with the IPNET
    stack, so the function names are different (though the idea is the
    same).

    The important point is that there isn't an unbroken line between
    muxReceive() and muxSend(): there's some protocol processing that
    happens in between. It is the IP code that makes the routing decision
    and figures out that the ping that arrived from L_END should be
    forwarded out W_END.

    When you do an ipAttach(), you are not attaching an interface to the
    MUX. The interface is already attached to the MUX (the startup code in
    usrNetwork.c does a muxDevLoad()/muxDevStart() for every device in the
    system). What you do with ipAttach() is bind the TCP/IP protocol to a
    particular END device using muxBind(). The muxBind() routine returns a
    cookie that you use as an argument when you call muxSend() or
    muxIoctl(). With the VxWorks BSD-based stack, the stack creates an
    ifnet stucture (which is how BSD represents a network interface) and
    hides the cookie in it, so that the stack associates its logical
    interface definition with the underlying END interface to which it is
    bound.

    I suspect that part of the reason why the MUX exists in the first
    place is to allow the TCP/IP protocol stack and network device support
    to be scaled out independently. That is, you can build a VxWorks image
    that contains only the MUX code and END drivers, but not the TCP/IP
    stack code.

    Suppose you want to build a device using VxWorks that needs some
    limited networking facilities, but not necessarily a full TCP/IP
    stack, and your device has very little RAM. Maybe you only need to
    send some beacon or heartbeat frames periodically so that your device
    can be monitored from your own proprietary control system. You can
    design your own little proprietary heartbeat protocol stack that
    consumes only a tiny amount of memory and sits above the MUX, and just
    remove the VxWorks TCP/IP stack entirely.

    Alternatively, you might decide to just write (or license) a totally
    different TCP/IP stack, or use a custom stack for a totally different
    protocol.

    With the original BSD TCP/IP code, this was a little tricky to do,
    because the ifnet driver interface and the TCP/IP stack were very
    tighly integrated: both the stack and driver code shared data
    structures and header files. This made it hard to separate them. With
    the MUX and END, the END drivers are totally separate from protocol
    stack code, and have no knowledge of any stack-level structures or
    semantics. This line has been blurred in some cases, especially now
    that so many ethernet controller support TCP/IP accelleration features
    (checksum offload, TCP segmentation offload, etc...). In general
    though, END drivers have no idea what protocols will be using them.

    -Bill

  3. Re: The relation between MUX and END?


    Hello Bill, thanks for your reply. I spent much time to study it.

    My system is vxWorks 5.5, with no PNE(Platform Network Equipment)
    intalled (in other words, my system is built under cygwin without PNE
    libraries)

    Because non-PNE, I did not have the source code of ip_input(),
    ip_forward() and ip_output(). And some problems occurred but I can not
    trace it.

    scenario 1: PC1 ping PC2, the result is:
    PC1 ==>L_END_recv() --> muxRecv() --> W_END_send() ==> PC2

    muxSend() is lost....!!?? But PC2 still received the packets. I means
    ping is successful.

    scenario 2: PC2 ping my_device, the result is:
    PC2 ==> W_END_recv() --> muxRecv() --> ....

    I think the binding between IP-stack, MUX, L_END, W_END is correct
    because scenario 2 seems correct.

    But did you have any idea of why muxSend() sleeps in scenario 1??


    Thank You,
    Best Regards,


    Raymond.Lin

+ Reply to Thread