locked
IPv6 Raw sockets. Problem receiving on SIO_RCVALL socket. RRS feed

  • Question

  • Hello everybody,

    I'm using Windows Server 2008 R2 for production purposes, so it must be no problem for me to utilize raw socket functionality. But instead I got a problem receiving data on inbound RCVALL socket. What am I doing:

    1) m_recv_socket = socket( AF_INET6 , SOCK_RAW , IPPROTO_IPV6 ),

    2) setsockopt( m_recv_socket, SOL_SOCKET, SO_RCVTIMEO, reinterpret_cast<const char*>( &recv_timeout_ms ), sizeof(int) );

    3) bind( m_recv_socket, reinterpret_cast<sockaddr *>( &sa ), sizeof( sa ) );

    (I'm binding it here to the my nic's LINK-Local address, i.e. fe80::a077:5573:5f:3ca5)

    4) WSAIoctl( m_recv_socket, SIO_RCVALL , &dwBufferInLen, sizeof(dwBufferInLen),

    &dwBufferLen, sizeof(dwBufferLen),
    &dwBytesReturned , NULL , NULL );

    (Where dwBufferInLen equals to 1)

    When I try to recv data on this socket, I constantly receive WSA_TIMEDOUT and no data have been received. In the meantime Wireshark proves both inbound and outboud traffic exists on this interface. What is wrong? Any help please? The same code, modified for IPv4 usage works correctly. All return codes for the above calls are OK.

    Best regards, Alexander Chernyaev.


    Sincerely yours, Alexander Chernyaev.

    • Changed type Zorgiev Monday, June 11, 2012 4:34 PM
    Friday, June 8, 2012 9:33 AM

All replies

  • Anybody? Please? Help? SIO_RCVALL isn't working?

    Sincerely yours, Alexander Chernyaev.


    • Edited by Zorgiev Monday, June 11, 2012 4:33 PM
    Monday, June 11, 2012 8:59 AM
  • Let me give some clue. There exists unbound send socket of type (AF_INET6, SOCK_RAW, IPPROTO_IPV6); IPV6_HDRINCL is being set. I send manually formed TCP packet through it. Wireshark proves it passes fine. Next I see incoming TCP(RST, ACK) to it exactly to the address I bound receiving socket to. But application remains blocked upon data receiving trial. All checksums are ok, otherwise there wouldn't be any response incoming packets. I'm sure this incoming packet is a response to my TCP(SYN) request because SEQ/ACK numbers prove this(Wireshark also shows me this stream's sequence). So what can be done wrong to this receiving socket? Anybody? Please?

    Sincerely yours, Alexander Chernyaev.

    Monday, June 11, 2012 4:06 PM