2
0

NETWORKING 3.2 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. This is the network infrastructure documentation for tinc, a Virtual Private
  2. Network daemon.
  3. Copyright 2001-2002 Guus Sliepen <guus@sliepen.eu.org>
  4. Permission is granted to make and distribute verbatim copies of
  5. this documentation provided the copyright notice and this
  6. permission notice are preserved on all copies.
  7. Permission is granted to copy and distribute modified versions of
  8. this documentation under the conditions for verbatim copying,
  9. provided that the entire resulting derived work is distributed
  10. under the terms of a permission notice identical to this one.
  11. $Id: NETWORKING,v 1.1.2.3 2002/06/21 10:11:10 guus Exp $
  12. 1. Packet flow
  13. ==============
  14. There are two directions for packets. There are packets received from the tap
  15. device that have to be sent out to other tinc daemon, and there are packets
  16. that are received from other tinc daemons which have to be send to the tap
  17. device. The first direction will be called the outgoing direction, while the
  18. latter will be called the incoming direction.
  19. 1.1 Outgoing flow
  20. -----------------
  21. handle_tap_input()
  22. |
  23. |
  24. V
  25. route_outgoing()
  26. |
  27. |
  28. V
  29. send_packet() ----
  30. / \ / \
  31. / \ | queue
  32. V V V /
  33. send_tcppacket() send_udppacket()--
  34. Packets are read from the tap device by handle_tap_input(). The packets will be
  35. marked as coming from ourself, and are then handled by route_outgoing(). This
  36. function will determine the destination tinc daemon this packet has to be sent
  37. to, and in the future it may also determine if this packet has to be broadcast
  38. or multicast. route_outgoing() will call send_packet() (in case of
  39. broad/multicast several times). send_packet() will check the destination
  40. connection_t entry to see if it is a valid destination, and whether it has to
  41. be sent via TCP or UDP. It will then either call send_tcppacket() or
  42. send_udppacket(). Since a different key is used for UDP packets, which might
  43. not be available at that time, send_udppacket() might put the packet in a queue
  44. and send a REQ_KEY to the destination tinc daemon. If the key has been retrieved,
  45. the packet will be fed to send_udppacket() again.
  46. 1.2 Incoming flow
  47. -----------------
  48. handle_vpn_input()
  49. |
  50. |
  51. V
  52. tcppacket_h() receive_udppacket()
  53. \ /
  54. \ /
  55. V V
  56. receive_packet()
  57. |
  58. |
  59. V
  60. route_incoming()
  61. |
  62. |
  63. V
  64. accept_packet()
  65. Packets from other tinc daemons can be received by tcppacket_h(), for TCP
  66. packets, and receive_udppacket() via handle_vpn_input() for UDP packets.
  67. receive_packet() actually does not have to do much, except logging and calling
  68. route_incoming(), but it's there for symmetry with the scheme for the outgoing
  69. flow. route_incoming() will change the MAC header of the packet if necessary to
  70. let the kernel accept the packet after it has been sent to the tap device by
  71. accept_packet().