New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tap device support for Linux and FreeBSD #207

Merged
merged 1 commit into from Nov 4, 2015

Conversation

Projects
None yet
2 participants
@demirten
Contributor

demirten commented Nov 3, 2015

Tap devices must be up and running before using with tcpreplay.

Tap support in Apple devices works a little bit different and it is not compatible with main flow of tcpreplay.

Patch tested in Linux and FreeBSD with different capture files.

@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Nov 3, 2015

Member

Hi Murat. From your comments, can I assume that OS X tun/tap is not supported?

I looked at the code and it looks good to me. I will want to test before merging, but will not be able to work on Tcpreplay until Nov. 23.

Member

fklassen commented Nov 3, 2015

Hi Murat. From your comments, can I assume that OS X tun/tap is not supported?

I looked at the code and it looks good to me. I will want to test before merging, but will not be able to work on Tcpreplay until Nov. 23.

@demirten

This comment has been minimized.

Show comment
Hide comment
@demirten

demirten Nov 3, 2015

Contributor

Yes, I wrote tuntap support for OS X but later I have to remove it.

You need to open /dev/tapX char device and set interface status up in OS X. But all of the procedure must be done within same process. On the other hand, tcpreplay wants to see interfaces on startup, it must be configured before tcpreplay.

So I couldn't find any way to configure tap interface in one process and use it in another process under OS X. If this is possible, adding OS X support will be same as FreeBSD.

Contributor

demirten commented Nov 3, 2015

Yes, I wrote tuntap support for OS X but later I have to remove it.

You need to open /dev/tapX char device and set interface status up in OS X. But all of the procedure must be done within same process. On the other hand, tcpreplay wants to see interfaces on startup, it must be configured before tcpreplay.

So I couldn't find any way to configure tap interface in one process and use it in another process under OS X. If this is possible, adding OS X support will be same as FreeBSD.

fklassen added a commit that referenced this pull request Nov 4, 2015

Merge pull request #207 from demirten/tuntap-device-enhancement
Tap device support for Linux and FreeBSD

@fklassen fklassen merged commit 4019ed1 into appneta:master Nov 4, 2015

@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Nov 4, 2015

Member

Had a chance to play with this, so I merged. Thanks again for contribution.

Member

fklassen commented Nov 4, 2015

Had a chance to play with this, so I merged. Thanks again for contribution.

@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 15, 2015

Should this be /dev/net/<device_name> ?? For example, /dev/net/tap0 ??

fklassen commented on src/common/sendpacket.c in 737f68b Dec 15, 2015

Should this be /dev/net/<device_name> ?? For example, /dev/net/tap0 ??

This comment has been minimized.

Show comment
Hide comment
@demirten

demirten Dec 15, 2015

Owner

No, you should use /dev/net/tun control device both of the TUN and TAP interfaces and use ioctl with IFF_TUN or IFF_TAP. See: https://www.kernel.org/doc/Documentation/networking/tuntap.txt

Owner

demirten replied Dec 15, 2015

No, you should use /dev/net/tun control device both of the TUN and TAP interfaces and use ioctl with IFF_TUN or IFF_TAP. See: https://www.kernel.org/doc/Documentation/networking/tuntap.txt

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 16, 2015

Right, I got confused between device name and interface name. Name is correct.

fklassen replied Dec 16, 2015

Right, I got confused between device name and interface name. Name is correct.

@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 15, 2015

Taps and Tuns are different on Linux. If device name is tapX suspect that you should use IFF_TAP. If device name is tunX, flag should be IFF_TUN. But above you give the device a name of '/dev/net/tun'. Should be '/dev/net/tapX'.

Also, Tun may be harder to implement. Packets must be fed without Ethernet layer (feed Layer 3 packets rather than Layer 2 frames). For now, I suggest only supporting Tap.

fklassen commented on src/common/sendpacket.c in 737f68b Dec 15, 2015

Taps and Tuns are different on Linux. If device name is tapX suspect that you should use IFF_TAP. If device name is tunX, flag should be IFF_TUN. But above you give the device a name of '/dev/net/tun'. Should be '/dev/net/tapX'.

Also, Tun may be harder to implement. Packets must be fed without Ethernet layer (feed Layer 3 packets rather than Layer 2 frames). For now, I suggest only supporting Tap.

This comment has been minimized.

Show comment
Hide comment
@demirten

demirten Dec 15, 2015

Owner

See my previous line comments about /dev/net/tun. I'm using tap device support in tcpdump effectively, on the other hand I can't see any usefull example with tun device support. I don't have much experience with tun devices so maybe we should get more comments to clarify.

Owner

demirten replied Dec 15, 2015

See my previous line comments about /dev/net/tun. I'm using tap device support in tcpdump effectively, on the other hand I can't see any usefull example with tun device support. I don't have much experience with tun devices so maybe we should get more comments to clarify.

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 16, 2015

I implemented a TUN server/client so that any 2 clients are not on the same collision domain. It works well for security, making sure that one client will never see the other client's traffic. On the client side, you see one TUN interface (in this example ani0). On the server side you see many aniX interfaces, one per connection.

I plan to do some compression optimization in a few months. I'll take a stab at implementing the TUN interface at that time, if you like. It will get well used, and therefore well tested. I may have to use a PTP DLT instead of Ethernet, so it may be a bit more work than just simply flipping the bit.

Here is what a TUN looks like...

ani0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.18.1.158  P-t-P:172.18.1.158  Mask:255.255.255.252
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:155810 errors:0 dropped:0 overruns:0 frame:0
          TX packets:174179 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:23256221 (22.1 MiB)  TX bytes:12869314 (12.2 MiB)

eth0      Link encap:Ethernet  HWaddr f0:ad:4e:01:14:3e  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:89 

eth1      Link encap:Ethernet  HWaddr f0:ad:4e:01:14:3f  
          inet addr:172.16.124.32  Bcast:172.16.125.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67667585 errors:0 dropped:1268 overruns:0 frame:0
          TX packets:31241239 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3919479366 (3.6 GiB)  TX bytes:3896468586 (3.6 GiB)
          Interrupt:90 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:498078 errors:0 dropped:0 overruns:0 frame:0
          TX packets:498078 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34185290 (32.6 MiB)  TX bytes:34185290 (32.6 MiB)

fklassen replied Dec 16, 2015

I implemented a TUN server/client so that any 2 clients are not on the same collision domain. It works well for security, making sure that one client will never see the other client's traffic. On the client side, you see one TUN interface (in this example ani0). On the server side you see many aniX interfaces, one per connection.

I plan to do some compression optimization in a few months. I'll take a stab at implementing the TUN interface at that time, if you like. It will get well used, and therefore well tested. I may have to use a PTP DLT instead of Ethernet, so it may be a bit more work than just simply flipping the bit.

Here is what a TUN looks like...

ani0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.18.1.158  P-t-P:172.18.1.158  Mask:255.255.255.252
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:155810 errors:0 dropped:0 overruns:0 frame:0
          TX packets:174179 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:23256221 (22.1 MiB)  TX bytes:12869314 (12.2 MiB)

eth0      Link encap:Ethernet  HWaddr f0:ad:4e:01:14:3e  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:89 

eth1      Link encap:Ethernet  HWaddr f0:ad:4e:01:14:3f  
          inet addr:172.16.124.32  Bcast:172.16.125.255  Mask:255.255.254.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67667585 errors:0 dropped:1268 overruns:0 frame:0
          TX packets:31241239 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3919479366 (3.6 GiB)  TX bytes:3896468586 (3.6 GiB)
          Interrupt:90 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:498078 errors:0 dropped:0 overruns:0 frame:0
          TX packets:498078 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:34185290 (32.6 MiB)  TX bytes:34185290 (32.6 MiB)
@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 15, 2015

Should this be SP_TYPE_TAP, and we can implement SP_TYPE_TUN in the future?

fklassen commented on src/common/sendpacket.h in 737f68b Dec 15, 2015

Should this be SP_TYPE_TAP, and we can implement SP_TYPE_TUN in the future?

@fklassen

This comment has been minimized.

Show comment
Hide comment
@fklassen

fklassen Dec 15, 2015

Member

@demirten I added some comments. If you feel so included, please make updates and send another PR. Tnx, Fred.

Member

fklassen commented Dec 15, 2015

@demirten I added some comments. If you feel so included, please make updates and send another PR. Tnx, Fred.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment