Re: Sending UDP packets over Ethernet - TCP-IP

This is a discussion on Re: Sending UDP packets over Ethernet - TCP-IP ; (comp.protocols.tcp-ip added) Fred wrote: > I've been tasked to write some code for an FPGA to interface to 10BASE- > T Ethernet using differential drivers and receivers. > The information is one way, transmit only! I will have an IP ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: Sending UDP packets over Ethernet

  1. Re: Sending UDP packets over Ethernet

    (comp.protocols.tcp-ip added)

    Fred wrote:

    > I've been tasked to write some code for an FPGA to interface to 10BASE-
    > T Ethernet using differential drivers and receivers.


    > The information is one way, transmit only! I will have an IP address
    > within the network range, give myself a MAC number and know the MAC
    > and IP address of the destination PC.


    > Do I require any ARP or any other protocol? Will it just work, with
    > the destination PC receiving UDP packets?


    Normally you would use ARP to find the destination MAC given
    the IP address. Since you seem to already know it, you shouldn't
    need ARP. If you don't need to receive, or the sender already
    knows your MAC address then you don't need to receive and
    reply to ARP. (Most will add you to the ARP table on receiving
    your data. The entry will eventually time out, though.)

    You could also broadcast. (Set the destination to X'ffffffffffff').
    That isn't recommended if there are other hosts on the net, and it
    might be that some IP implementations ignore broadcast packets
    without a broadcast IP address.

    -- glen


  2. Re: Sending UDP packets over Ethernet

    In comp.protocols.tcp-ip glen herrmannsfeldt wrote:
    > (comp.protocols.tcp-ip added)


    > Fred wrote:


    > > I've been tasked to write some code for an FPGA to interface to
    > > 10BASE- T Ethernet using differential drivers and receivers.


    > > The information is one way, transmit only! I will have an IP
    > > address within the network range, give myself a MAC number and
    > > know the MAC and IP address of the destination PC.


    > > Do I require any ARP or any other protocol? Will it just work,
    > > with the destination PC receiving UDP packets?


    > Normally you would use ARP to find the destination MAC given the IP
    > address. Since you seem to already know it, you shouldn't need ARP.
    > If you don't need to receive, or the sender already knows your MAC
    > address then you don't need to receive and reply to ARP. (Most will
    > add you to the ARP table on receiving your data. The entry will
    > eventually time out, though.)


    Is the destination "always" going to be in the same broadcast domain
    as the FPGA? If so, then why bother with IP and UDP? The only value
    IP adds in this case would seem to be fragmentation and reassembly,
    but then only if you implement fragmentation in your FPGA.

    If the destination can be "remote" (on the other side of an IP router)
    then there are a rather large host (as it were) of things expected of
    an IP implementation besides just "slap a header on there and go"
    described in a number of the RFC's one can find at places such as
    www.ietf.org.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    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...

  3. Re: Sending UDP packets over Ethernet

    Rick Jones wrote:
    (snip)

    >>Fred wrote:


    >>>I've been tasked to write some code for an FPGA to interface to
    >>>10BASE- T Ethernet using differential drivers and receivers.


    (snip, then I wrote)
    >>Normally you would use ARP to find the destination MAC given the IP
    >>address. Since you seem to already know it, you shouldn't need ARP.
    >>If you don't need to receive, or the sender already knows your MAC
    >>address then you don't need to receive and reply to ARP. (Most will
    >>add you to the ARP table on receiving your data. The entry will
    >>eventually time out, though.)


    > Is the destination "always" going to be in the same broadcast domain
    > as the FPGA? If so, then why bother with IP and UDP? The only value
    > IP adds in this case would seem to be fragmentation and reassembly,
    > but then only if you implement fragmentation in your FPGA.


    It means you don't have to do so much work on the receiver
    if it already has IP running. In many cases, it isn't easy
    to receive raw data on a host already running IP.

    Adding the UDP header is pretty easy. You can even put in
    zero for the checksum to ignore it. You still have to
    generate the ethernet CRC, though.

    > If the destination can be "remote" (on the other side of an IP router)
    > then there are a rather large host (as it were) of things expected of
    > an IP implementation besides just "slap a header on there and go"
    > described in a number of the RFC's one can find at places such as
    > www.ietf.org.


    Well, you need the MAC address of the router instead of
    the destination host. Implementing route redirect would
    be nice, but not needed. Otherwise, just adding a UDP header
    should work. You might also want source quench or some
    kind of flow control. For transmit only you can't use the
    reply packets for flow control.

    -- glen


  4. Re: Sending UDP packets over Ethernet

    In article ,
    Rick Jones wrote:

    >Is the destination "always" going to be in the same broadcast domain
    >as the FPGA? If so, then why bother with IP and UDP? The only value
    >IP adds in this case would seem to be fragmentation and reassembly,
    >but then only if you implement fragmentation in your FPGA.
    >
    >If the destination can be "remote" (on the other side of an IP router)
    >then there are a rather large host (as it were) of things expected of
    >an IP implementation besides just "slap a header on there and go"
    >described in a number of the RFC's one can find at places such as
    >www.ietf.org.


    My answer to the question at the start is that in the real world
    there are *always* situations where the absolutely guaranteed
    for certain always and forever promise that there will never be
    a router is broken. Therefore the low the costs of slapping fake
    but servicable UDP/IP headers in front of the payload are so low that
    you can't afford not to pay them. There are always test networks if
    the promises about no routers are always and forever met when the
    application is deployed...and the promises usually are broken in some
    deployed case.


    Vernon Schryver vjs@rhyolite.com

  5. Re: Sending UDP packets over Ethernet

    In article ,
    glen herrmannsfeldt wrote:

    >Also, you can't accept route redirect or source quench,
    >two others that would seem useful in some cases.


    ICMP Redirect might be useful, but might involve a lot of machinery
    given the target situations of no routers.
    I think ICMP Source has been deprecated for more than 20 years. See
    http://www.google.com/search?q=icmp+...nch+deprecated

    For an application like this that might otherwise use raw Ethernet
    packets, Source Quench is obviously useless. In general, Source Quench
    is of little use, because transport protocols that real networks can
    tolerate have their own congestion avoidance and recovery machinery.
    Even if your UDP or other datagram application doesn't have official
    congestion management stuff, it ought to have some sort of pacing
    machinery that responds to losses caused by losses, which tends to make
    ICMP Source Quench irrelevant.

    Besides, ICMP Source Quench uses bandwidth, which can make a merely
    marginal situation into a bad situation. So we get things like TCP
    Explicit Congestion Notification http://www.google.com/search?q=tcp+ecn


    Vernon Schryver vjs@rhyolite.com

  6. Re: Sending UDP packets over Ethernet

    Vernon Schryver wrote:
    (snip regarding generating UDP in an FPGA)

    > My answer to the question at the start is that in the real world
    > there are *always* situations where the absolutely guaranteed
    > for certain always and forever promise that there will never be
    > a router is broken. Therefore the low the costs of slapping fake
    > but servicable UDP/IP headers in front of the payload are so low that
    > you can't afford not to pay them. There are always test networks if
    > the promises about no routers are always and forever met when the
    > application is deployed...and the promises usually are broken in some
    > deployed case.


    But if you supply the MAC address of the router, it will even
    work through a router. The main problem it does have is that
    if you change the net around it won't adapt to the change.

    If you have no ability to receive you can't do ARP, anyway.
    Also, you can't accept route redirect or source quench,
    two others that would seem useful in some cases.

    But networks do change...

    -- glen


  7. Re: Sending UDP packets over Ethernet

    Vernon Schryver wrote:
    (snip)

    > I think ICMP Source has been deprecated for more than 20 years. See
    > http://www.google.com/search?q=icmp+...nch+deprecated


    Is it that long ago?

    I remember trying to ftp a new version of NCSA Telnet to a PC,
    (all the way from NCSA), the PC sending out source quench as
    fast as it could, as its buffers kept overrunning. That would
    have been a little less than 20 years ago.

    Many early PC ethernet cards had small buffers.

    -- glen


  8. Re: Sending UDP packets over Ethernet

    glen herrmannsfeldt wrote:
    > > I think ICMP Source has been deprecated for more than 20 years. See
    > > http://www.google.com/search?q=icmp+...nch+deprecated

    >
    > Is it that long ago?
    >
    > I remember trying to ftp a new version of NCSA Telnet to a PC,
    > (all the way from NCSA), the PC sending out source quench as
    > fast as it could, as its buffers kept overrunning. That would
    > have been a little less than 20 years ago.
    >
    > Many early PC ethernet cards had small buffers.


    Geesh! I just read a post by Dan Lanciani and it made me think of all
    the installs I did with Crynwr pkt drivers and BYU's IPX.

    Then I come here and I'm treated to another trip down the memory lane
    with NCSA Telnet!

    I wonder if I'll now run into someone asking a question about Pegasus
    Mail, Spyder analyzers, and Coherent (Unix clone) Or a flame war will
    break about about Kermit being superior to NCSA Telnet!

    --

    hsb


    "Somehow I imagined this experience would be more rewarding" Calvin
    ************************************************** ******************
    Due to the volume of email that I receive, I may not be able to
    reply to emails sent to my account. Please post a followup instead.
    ************************************************** ******************

+ Reply to Thread