Find the answer to your Linux question:
Results 1 to 4 of 4
Hi, Am using the code below in a server, kernel thread to send UDP messages to a client. This works fine mostly (9 out of 10 times). However, every once ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2010
    Posts
    2

    sock_sendmsg in does not send sometimes


    Hi,

    Am using the code below in a server, kernel thread to send UDP messages to a client.

    This works fine mostly (9 out of 10 times). However, every once in awhile, the UDP message does not get put on the network. Packet capture tools show no message being put on the network.

    Usually happens at beginning of operation. Receives message from client, server processes it, appears to send response by calling the function below, but no message appears on the network.

    Return value from sock_sendmsg() is always correct == to len.
    IP addresses and Port numbers are correct.

    How do I diagnose this further?
    netstat increments transmit packets to indicate something was sent out.

    perhaps ARP resolution fails on initial attempt? How do I check this?

    This (server) is running on linux v 2.6.17.

    appreciate any assistance.




    ksockUdp_send(struct socket *sock, struct sockaddr_in* addr, unsigned char* buf, int len )
    {
    struct msghdr msg;
    struct iovec iov;
    mm_segment_t oldfs;
    int size = 0;

    down_interruptible(&kthread_lock);

    iov.iov_base = buf;
    iov.iov_len = len;

    msg.msg_flags = 0;
    msg.msg_name = addr;
    msg.msg_namelen = sizeof(struct sockaddr_in)
    msg.msg_control = NULL;
    msg.msg_controllen = 0;
    msg.msg_iov = &iov;
    msg.msg_iovlen = 1;
    msg.msg_control = NULL;

    oldfs = get_fs();
    set_fs(KERNEL_DS);
    size = sock_sendmsg(sock, &msg, len)l
    set_fs(oldfs);

    up(&kthread_lock);

    }

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,539
    Perhaps there is a hardware problem with your NIC? Have you tried swapping out the controller and trying again? If the controller is built into the motherboard, then have you tried an external PCI controller?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Nov 2010
    Posts
    2

    regarding trying alternate nic

    I have tested this on two different systems with the same results.

    I should mention that the network I am referring to is a WiFI network and NIC - atheros.

    The packet loss seems to be always on the initial packets sent and appears to be before actually putting something out on the WiFI channel.

    Its as though the packet is being lost somewhere between the kernel network stack and the wifi NIC hardware.

    I am thinking the network stack has not finished initial ARP resolution? or something like that and discards these initial packets?

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,539
    Quote Originally Posted by rrelect View Post
    I have tested this on two different systems with the same results.

    I should mention that the network I am referring to is a WiFI network and NIC - atheros.

    The packet loss seems to be always on the initial packets sent and appears to be before actually putting something out on the WiFI channel.

    Its as though the packet is being lost somewhere between the kernel network stack and the wifi NIC hardware.

    I am thinking the network stack has not finished initial ARP resolution? or something like that and discards these initial packets?
    Re. ARP - this could be an issue, since you indicate that this only happens on the initial send to an address. Once the address is resolved, it should be cached so that subsequent lookups are effectively instantaneous. Remember, there is no guarantee of delivery for UDP packets. So, this could be an issue for you, but it is NOT an issue for the protocol.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •