[SOLVED] sending MAC packets --- again, and again

From: Daniel Valencia (fetrovsky_at_yahoo.com)
Date: 05/21/05

  • Next message: Vaibhave Agarwal: "npxintr from nowhere"
    Date: Sat, 21 May 2005 11:21:34 -0700 (PDT)
    To: freebsd-net@freebsd.org
    
    

    Hello all

    Thanks to your answers, and thanks to Charles Swiger
    for mentioning the timeout value, i went to the
    manpage and re-read that, and figured out that I had
    misinterpreted the timeout purpose. I thought that if
    I set it to zero, I would wait forever and as soon as
    a packet arrived I would be notified... I was wrong...
    When I set it to zero, pcap_loop would actually wait
    forever before notifying me of any received packets.
    Setting the timeout to 1 I get the packets immediately
    after pcap sees them.

    The only problem is, I'm imposing an artificial 1ms
    delay in my receiving of packets. It's not actually
    important at this point, but it would be nice if it
    weren't that way.

    Again, thank you all

    - Daniel

    --- Daniel Valencia <fetrovsky@yahoo.com> wrote:
    > Hello
    >
    > --- Charles Swiger <cswiger@mac.com> wrote:
    > > pcap_dispatch() will not
    > > necessarily
    > > return when the read times out; on
    > some
    > > platforms, the read
    > > timeout
    > > isn't supported, and, on other platforms,
    > > the timer doesn't
    > > start until
    > > at least one packet arrives. This means
    >
    > If I read this correctly, pcap will sometimes wait
    > forever until a packet appears, which I don't
    > actually
    > mind because it's actually the behaviour that I'm
    > expecting. What is really odd is that even when
    > packets ARE arriving, pcap_loop just sits there,
    > lets
    > the packets pile up, and then shows all the messages
    > at once... then it blocks again for a while, even as
    > I
    > send messages from the other computer, just to show
    > them all at once again, and so on...
    >
    > > you'll probably find yourself either going
    > > multithreaded or using
    >
    > I'm actually going multithreaded, but I'd expect a
    > packet to show up immediately, so I can process it
    > and
    > perform the routing in a timely manner, rather than
    > delivering a packet a minute after it was sent.
    >
    > Thank you very much!
    >
    > - Daniel
    >
    >
    >
    >
    > __________________________________
    > Yahoo! Mail Mobile
    > Take Yahoo! Mail with you! Check email on your
    > mobile phone.
    > http://mobile.yahoo.com/learn/mail
    > _______________________________________________
    > freebsd-net@freebsd.org mailing list
    >
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    > To unsubscribe, send any mail to
    > "freebsd-net-unsubscribe@freebsd.org"
    >

                    
    Discover Yahoo!
    Find restaurants, movies, travel and more fun for the weekend. Check it out!
    http://discover.yahoo.com/weekend.html

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: Vaibhave Agarwal: "npxintr from nowhere"

    Relevant Pages

    • Not reading, or sending, fast enough on my serial application
      ... I'm past that hurdle (the ... but now I'm seeing that my application drops packets. ... on the descriptor and then use selectwith a timeout of 30 seconds on ... setting VMIN to 255, is select extraneous? ...
      (comp.unix.programmer)
    • Re: read() returns ETIMEDOUT on steady TCP connection
      ... 3382078274 data packets ... 86369 connections established ... 131 connections dropped by rexmit timeout ... 68139 segment rexmits in SACK recovery episodes ...
      (freebsd-net)
    • Re: read() returns ETIMEDOUT on steady TCP connection
      ... 3382078274 data packets ... 86369 connections established ... 131 connections dropped by rexmit timeout ... 68139 segment rexmits in SACK recovery episodes ...
      (freebsd-net)
    • Re: Strange packet log: hacked?
      ... Quite often a connection track entry reaches its timeout yet traffic still ... packets being logged and dropped. ... > I'm fairly new at reading packet logs, ...
      (comp.os.linux.security)
    • [NT] Yahoo! Messenger URL Handler Remote DoS
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... A denial of service vulnerability exists in the way Yahoo! ... When these packets are sent Yahoo! ... Messenger version 6.0 ...
      (Securiteam)