Find the answer to your Linux question:
Results 1 to 2 of 2
Not sure whether to put this here or in the kernel section. I am writing a small network driver that is based on the snull driver found in Linux Device ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2012
    Posts
    5

    Driver responding to ping\UDP sockets but unable to open TCP socket


    Not sure whether to put this here or in the kernel section.

    I am writing a small network driver that is based on the snull driver found in Linux Device Drivers, Third Edition.

    As we do not yet have hardware to talk to, my driver opens a UDP socket that pushes data to a small listener app in user space which, in turn, pushes data to a hardware emulator application. This mechanism seems to be working adequately as I am able to ping through my driver between two VMs (each running the listener app and talking to their respective ports on the hardware emulation app. I also verified connectivity by opening a UDP socket between two VMs through my driver. So far so good...

    However, I am unable to open a TCP socket through my driver. Further, Tshark is reporting some unexpected traffic when I try this.

    First, a working example through the regular network (eth0):

    Server side:
    Capturing on eth0
    0.000000 192.168.56.7 -> 192.168.56.6 NFS 214 V4 Call ACCESS FH:0x53dcb22b, [Check: RD LU MD XT DL]
    0.000149 192.168.56.6 -> 192.168.56.7 NFS 298 V4 Reply (Call In 1) ACCESS, [Allowed: RD LU MD XT DL]
    0.000366 192.168.56.7 -> 192.168.56.6 TCP 66 982 > nfs [ACK] Seq=149 Ack=233 Win=22161 Len=0 TSval=721884 TSecr=3673908
    5.004841 CadmusCo_f8:ec:f0 -> CadmusCo_c0:ee:84 ARP 42 Who has 192.168.56.7? Tell 192.168.56.6
    5.005107 CadmusCo_c0:ee:84 -> CadmusCo_f8:ec:f0 ARP 60 192.168.56.7 is at 08:00:27:c0:ee:84
    6.004516 192.168.56.7 -> 192.168.56.6 NFS 222 V4 Call ACCESS FH:0x2a97fc15, [Check: RD LU MD XT DL]
    6.004628 192.168.56.6 -> 192.168.56.7 NFS 298 V4 Reply (Call In 6) ACCESS, [Allowed: RD LU MD XT DL]
    6.004847 192.168.56.7 -> 192.168.56.6 TCP 66 982 > nfs [ACK] Seq=305 Ack=465 Win=22161 Len=0 TSval=723385 TSecr=3675409

    And the client side:
    Capturing on eth0
    0.000000 192.168.56.6 -> 192.168.56.7 TCP 74 57451 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=3940687 TSecr=0 WS=16
    0.000306 192.168.56.7 -> 192.168.56.6 TCP 74 italk > 57451 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=988713 TSecr=3940687 WS=16
    0.000329 192.168.56.6 -> 192.168.56.7 TCP 66 57451 > italk [ACK] Seq=1 Ack=1 Win=14608 Len=0 TSval=3940687 TSecr=988713
    10.028556 192.168.56.6 -> 192.168.56.7 TCP 72 57451 > italk [PSH, ACK] Seq=1 Ack=1 Win=14608 Len=6 TSval=3943194 TSecr=988713
    10.028861 192.168.56.7 -> 192.168.56.6 TCP 66 italk > 57451 [ACK] Seq=1 Ack=7 Win=14480 Len=0 TSval=991220 TSecr=3943194
    10.028936 192.168.56.7 -> 192.168.56.6 TCP 84 italk > 57451 [PSH, ACK] Seq=1 Ack=7 Win=14480 Len=18 TSval=991220 TSecr=3943194
    10.028979 192.168.56.6 -> 192.168.56.7 TCP 66 57451 > italk [ACK] Seq=7 Ack=19 Win=14608 Len=0 TSval=3943194 TSecr=991220

    ------------------------------------

    And now through my driver (after verifying connectivity using ping, of course)

    Server side:
    Capturing on f6drv0
    0.000000 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=821136 TSecr=0 WS=16
    3.005281 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=821888 TSecr=0 WS=16
    9.340143 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=823392 TSecr=0 WS=16
    21.094735 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=826400 TSecr=0 WS=16
    45.124780 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=832416 TSecr=0 WS=16
    93.225817 10.5.5.2 -> 10.5.5.1 TCP 74 41009 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=844448 TSecr=0 WS=16

    And the client side:
    Capturing on f6drv0
    0.000000 10.5.5.1 -> 10.5.5.2 TCP 74 35571 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4001890 TSecr=0 WS=16
    3.004962 10.5.5.1 -> 10.5.5.2 TCP 74 35571 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4002642 TSecr=0 WS=16
    9.013570 10.5.5.1 -> 10.5.5.2 TCP 74 35571 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4004144 TSecr=0 WS=16
    21.045044 10.5.5.1 -> 10.5.5.2 TCP 74 35571 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4007152 TSecr=0 WS=16
    45.109053 10.5.5.1 -> 10.5.5.2 TCP 74 35571 > italk [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=4013168 TSecr=0 WS=16

    --------------

    So... any clue?

  2. #2
    Just Joined!
    Join Date
    Apr 2012
    Posts
    5
    UPDATE: I found that unlike sending ping packets or opening UDP sockets, when one tries to open a TCP socket the IOCTL routine in the device driver gets called. Currently my IOCTL routine simply returns 0. So... any advice on exactly what my IOCTL routine should do to make TCP sockets happy?

Posting Permissions

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