diff --git a/libs/stund/Stun.sln b/libs/stund/Stun.sln
deleted file mode 100644
index b2977f58af4ffbdf307fde74427eebf1ba3dc18d..0000000000000000000000000000000000000000
--- a/libs/stund/Stun.sln
+++ /dev/null
@@ -1,38 +0,0 @@
-Microsoft Visual Studio Solution File, Format Version 7.00
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WinStun", "WinStun\WinStun.vcproj", "{717021E7-DCC4-41E7-9CDA-FA7596F18C56}"
-EndProject
-Project("{54435603-DBB4-11D2-8724-00A0C9A8B90C}") = "WinStunSetup", "WinStunSetup\WinStunSetup.vdproj", "{EB812030-9F2E-4FB7-813D-2E99AE2C5E4E}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "client", "client.vcproj", "{76E56991-C964-444B-82A6-AFDA5145E18A}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "server", "server.vcproj", "{2011B7B6-6932-431D-83A3-E825A271F8A8}"
-EndProject
-Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug
- ConfigName.1 = Release
- EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
- {717021E7-DCC4-41E7-9CDA-FA7596F18C56}.Debug.ActiveCfg = Debug|Win32
- {717021E7-DCC4-41E7-9CDA-FA7596F18C56}.Debug.Build.0 = Debug|Win32
- {717021E7-DCC4-41E7-9CDA-FA7596F18C56}.Release.ActiveCfg = Release|Win32
- {717021E7-DCC4-41E7-9CDA-FA7596F18C56}.Release.Build.0 = Release|Win32
- {EB812030-9F2E-4FB7-813D-2E99AE2C5E4E}.Debug.ActiveCfg = Debug
- {EB812030-9F2E-4FB7-813D-2E99AE2C5E4E}.Release.ActiveCfg = Release
- {EB812030-9F2E-4FB7-813D-2E99AE2C5E4E}.Release.Build.0 = Release
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Debug.ActiveCfg = Debug|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Debug.Build.0 = Debug|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Release.ActiveCfg = Release|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Release.Build.0 = Release|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Debug.ActiveCfg = Debug|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Debug.Build.0 = Debug|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Release.ActiveCfg = Release|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Release.Build.0 = Release|Win32
- EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
-EndGlobal
diff --git a/libs/stund/WinStun/WinStun.cpp b/libs/stund/WinStun/WinStun.cpp
deleted file mode 100644
index e5bdc3bf9d15760468ebaafd18684e3a62cd8907..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStun.cpp
+++ /dev/null
@@ -1,67 +0,0 @@
-// WinStun.cpp : Defines the class behaviors for the application.
-//
-
-#include "stdafx.h"
-#include "WinStun.h"
-#include "WinStunDlg.h"
-
-#ifdef _DEBUG
-#define new DEBUG_NEW
-#endif
-
-
-// CWinStunApp
-
-BEGIN_MESSAGE_MAP(CWinStunApp, CWinApp)
- ON_COMMAND(ID_HELP, CWinApp::OnHelp)
-END_MESSAGE_MAP()
-
-
-// CWinStunApp construction
-
-CWinStunApp::CWinStunApp()
-{
- // TODO: add construction code here,
- // Place all significant initialization in InitInstance
-}
-
-
-// The one and only CWinStunApp object
-
-CWinStunApp theApp;
-
-
-// CWinStunApp initialization
-
-BOOL CWinStunApp::InitInstance()
-{
- // InitCommonControls() is required on Windows XP if an application
- // manifest specifies use of ComCtl32.dll version 6 or later to enable
- // visual styles. Otherwise, any window creation will fail.
- InitCommonControls();
-
- CWinApp::InitInstance();
-
- if (!AfxSocketInit())
- {
- AfxMessageBox(IDP_SOCKETS_INIT_FAILED);
- return FALSE;
- }
-
- AfxEnableControlContainer();
-
-
- CWinStunDlg dlg;
- m_pMainWnd = &dlg;
- INT_PTR nResponse = dlg.DoModal();
-
- if (nResponse == IDCANCEL)
- {
- // TODO: Place code here to handle when the dialog is
- // dismissed with Cancel
- }
-
- // Since the dialog has been closed, return FALSE so that we exit the
- // application, rather than start the application's message pump.
- return FALSE;
-}
diff --git a/libs/stund/WinStun/WinStun.h b/libs/stund/WinStun/WinStun.h
deleted file mode 100644
index 34a36db1521e4dad9182fb717c0c62fdca9e0e40..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStun.h
+++ /dev/null
@@ -1,31 +0,0 @@
-// WinStun.h : main header file for the PROJECT_NAME application
-//
-
-#pragma once
-
-#ifndef __AFXWIN_H__
- #error include 'stdafx.h' before including this file for PCH
-#endif
-
-#include "resource.h" // main symbols
-
-
-// CWinStunApp:
-// See WinStun.cpp for the implementation of this class
-//
-
-class CWinStunApp : public CWinApp
-{
-public:
- CWinStunApp();
-
-// Overrides
- public:
- virtual BOOL InitInstance();
-
-// Implementation
-
- DECLARE_MESSAGE_MAP()
-};
-
-extern CWinStunApp theApp;
\ No newline at end of file
diff --git a/libs/stund/WinStun/WinStun.rc b/libs/stund/WinStun/WinStun.rc
deleted file mode 100644
index 56c1757bf173ca40f2fb86f54ea71ae4cc5d3286..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStun.rc
+++ /dev/null
@@ -1,210 +0,0 @@
-// Microsoft Visual C++ generated resource script.
-//
-#include "resource.h"
-
-#define APSTUDIO_READONLY_SYMBOLS
-/////////////////////////////////////////////////////////////////////////////
-//
-// Generated from the TEXTINCLUDE 2 resource.
-//
-#include "afxres.h"
-
-/////////////////////////////////////////////////////////////////////////////
-#undef APSTUDIO_READONLY_SYMBOLS
-
-/////////////////////////////////////////////////////////////////////////////
-// English (U.S.) resources
-
-#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
-#ifdef _WIN32
-LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
-#pragma code_page(1252)
-#endif //_WIN32
-
-#ifdef APSTUDIO_INVOKED
-/////////////////////////////////////////////////////////////////////////////
-//
-// TEXTINCLUDE
-//
-
-1 TEXTINCLUDE
-BEGIN
- "resource.h\0"
-END
-
-2 TEXTINCLUDE
-BEGIN
- "#include ""afxres.h""\r\n"
- "\0"
-END
-
-3 TEXTINCLUDE
-BEGIN
- "#define _AFX_NO_SPLITTER_RESOURCES\r\n"
- "#define _AFX_NO_OLE_RESOURCES\r\n"
- "#define _AFX_NO_TRACKER_RESOURCES\r\n"
- "#define _AFX_NO_PROPERTY_RESOURCES\r\n"
- "\r\n"
- "#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)\r\n"
- "LANGUAGE 9, 1\r\n"
- "#pragma code_page(1252)\r\n"
- "#include ""res\\WinStun.rc2"" // non-Microsoft Visual C++ edited resources\r\n"
- "#include ""afxres.rc"" // Standard components\r\n"
- "#endif\r\n"
- "\0"
-END
-
-#endif // APSTUDIO_INVOKED
-
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// Icon
-//
-
-// Icon with lowest ID value placed first to ensure application icon
-// remains consistent on all systems.
-IDR_MAINFRAME ICON "res\\WinStun.ico"
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// Dialog
-//
-
-IDD_ABOUTBOX DIALOGEX 0, 0, 235, 55
-STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION |
- WS_SYSMENU
-CAPTION "About WinStun"
-FONT 8, "MS Shell Dlg", 0, 0, 0x1
-BEGIN
- ICON IDR_MAINFRAME,IDC_STATIC,11,17,20,20
- LTEXT "WinStun Version 0.92",IDC_STATIC,40,10,119,8,
- SS_NOPREFIX
- LTEXT "Cullen Jennings",IDC_STATIC,40,25,119,8
- DEFPUSHBUTTON "OK",IDOK,178,7,50,16,WS_GROUP
-END
-
-IDD_WINSTUN_DIALOG DIALOGEX 0, 0, 209, 129
-STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_VISIBLE |
- WS_CAPTION | WS_SYSMENU
-EXSTYLE WS_EX_APPWINDOW
-CAPTION "WinStun"
-FONT 8, "MS Shell Dlg", 0, 0, 0x1
-BEGIN
- PUSHBUTTON "Quit",IDCANCEL,116,106,50,16
- PUSHBUTTON "Run Test",IDC_TEST,19,108,50,14
- LTEXT "Stun Server",IDC_STATIC,7,7,39,8
- EDITTEXT IDC_SERVER,48,7,142,12,ES_AUTOHSCROLL
- EDITTEXT IDC_RESULT,7,24,190,77,ES_MULTILINE | ES_AUTOVSCROLL |
- ES_READONLY | WS_VSCROLL | NOT WS_TABSTOP,
- WS_EX_STATICEDGE
-END
-
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// Version
-//
-
-VS_VERSION_INFO VERSIONINFO
- FILEVERSION 0,92,0,0
- PRODUCTVERSION 0,92,0,0
- FILEFLAGSMASK 0x3fL
-#ifdef _DEBUG
- FILEFLAGS 0x1L
-#else
- FILEFLAGS 0x0L
-#endif
- FILEOS 0x4L
- FILETYPE 0x1L
- FILESUBTYPE 0x0L
-BEGIN
- BLOCK "StringFileInfo"
- BEGIN
- BLOCK "040904e4"
- BEGIN
- VALUE "FileDescription", "STUN Client"
- VALUE "FileVersion", "0, 92, 0, 0"
- VALUE "InternalName", "WinStun.exe"
- VALUE "OriginalFilename", "WinStun.exe"
- VALUE "ProductName", "WinStun"
- VALUE "ProductVersion", "0.92.0.0"
- END
- END
- BLOCK "VarFileInfo"
- BEGIN
- VALUE "Translation", 0x409, 1252
- END
-END
-
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// DESIGNINFO
-//
-
-#ifdef APSTUDIO_INVOKED
-GUIDELINES DESIGNINFO
-BEGIN
- IDD_ABOUTBOX, DIALOG
- BEGIN
- LEFTMARGIN, 7
- RIGHTMARGIN, 228
- TOPMARGIN, 7
- BOTTOMMARGIN, 48
- END
-
- IDD_WINSTUN_DIALOG, DIALOG
- BEGIN
- LEFTMARGIN, 7
- RIGHTMARGIN, 202
- TOPMARGIN, 7
- BOTTOMMARGIN, 122
- END
-END
-#endif // APSTUDIO_INVOKED
-
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// RT_MANIFEST
-//
-
-IDR_MANIFEST RT_MANIFEST "res\\WinStun.manifest"
-
-/////////////////////////////////////////////////////////////////////////////
-//
-// String Table
-//
-
-STRINGTABLE
-BEGIN
- IDS_ABOUTBOX "&About WinStun..."
- IDP_SOCKETS_INIT_FAILED "Windows sockets initialization failed."
-END
-
-#endif // English (U.S.) resources
-/////////////////////////////////////////////////////////////////////////////
-
-
-
-#ifndef APSTUDIO_INVOKED
-/////////////////////////////////////////////////////////////////////////////
-//
-// Generated from the TEXTINCLUDE 3 resource.
-//
-#define _AFX_NO_SPLITTER_RESOURCES
-#define _AFX_NO_OLE_RESOURCES
-#define _AFX_NO_TRACKER_RESOURCES
-#define _AFX_NO_PROPERTY_RESOURCES
-
-#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)
-LANGUAGE 9, 1
-#pragma code_page(1252)
-#include "res\WinStun.rc2" // non-Microsoft Visual C++ edited resources
-#include "afxres.rc" // Standard components
-#endif
-
-/////////////////////////////////////////////////////////////////////////////
-#endif // not APSTUDIO_INVOKED
-
diff --git a/libs/stund/WinStun/WinStun.vcproj b/libs/stund/WinStun/WinStun.vcproj
deleted file mode 100644
index 8d0f05e0722e3edddc6c1df690cb1cd1742b7644..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStun.vcproj
+++ /dev/null
@@ -1,186 +0,0 @@
-<?xml version="1.0" encoding = "Windows-1252"?>
-<VisualStudioProject
- ProjectType="Visual C++"
- Version="7.00"
- Name="WinStun"
- ProjectGUID="{717021E7-DCC4-41E7-9CDA-FA7596F18C56}"
- Keyword="MFCProj">
- <Platforms>
- <Platform
- Name="Win32"/>
- </Platforms>
- <Configurations>
- <Configuration
- Name="Debug|Win32"
- OutputDirectory="Debug"
- IntermediateDirectory="Debug"
- ConfigurationType="1"
- UseOfMFC="2"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="0"
- PreprocessorDefinitions="WIN32;_WINDOWS;_DEBUG"
- MinimalRebuild="TRUE"
- BasicRuntimeChecks="3"
- RuntimeLibrary="3"
- TreatWChar_tAsBuiltInType="TRUE"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="4"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- LinkIncremental="2"
- GenerateDebugInformation="TRUE"
- SubSystem="2"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"
- PreprocessorDefinitions="_DEBUG"
- MkTypLibCompatible="FALSE"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"
- PreprocessorDefinitions="_DEBUG"
- Culture="1033"
- AdditionalIncludeDirectories="$(IntDir)"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- <Configuration
- Name="Release|Win32"
- OutputDirectory="Release"
- IntermediateDirectory="Release"
- ConfigurationType="1"
- UseOfMFC="2"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="2"
- InlineFunctionExpansion="1"
- OmitFramePointers="TRUE"
- PreprocessorDefinitions="WIN32;_WINDOWS;NDEBUG"
- StringPooling="TRUE"
- MinimalRebuild="FALSE"
- RuntimeLibrary="2"
- EnableFunctionLevelLinking="TRUE"
- TreatWChar_tAsBuiltInType="TRUE"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="3"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- LinkIncremental="1"
- GenerateDebugInformation="TRUE"
- SubSystem="2"
- OptimizeReferences="2"
- EnableCOMDATFolding="2"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"
- PreprocessorDefinitions="NDEBUG"
- MkTypLibCompatible="FALSE"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"
- PreprocessorDefinitions="NDEBUG"
- Culture="1033"
- AdditionalIncludeDirectories="$(IntDir)"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- </Configurations>
- <Files>
- <Filter
- Name="Source Files"
- Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm">
- <File
- RelativePath="WinStun.cpp">
- </File>
- <File
- RelativePath="WinStunDlg.cpp">
- </File>
- <File
- RelativePath="stdafx.cpp">
- <FileConfiguration
- Name="Debug|Win32">
- <Tool
- Name="VCCLCompilerTool"
- UsePrecompiledHeader="1"/>
- </FileConfiguration>
- <FileConfiguration
- Name="Release|Win32">
- <Tool
- Name="VCCLCompilerTool"
- UsePrecompiledHeader="1"/>
- </FileConfiguration>
- </File>
- <File
- RelativePath="..\stun.cxx">
- </File>
- <File
- RelativePath="..\udp.cxx">
- </File>
- </Filter>
- <Filter
- Name="Header Files"
- Filter="h;hpp;hxx;hm;inl;inc">
- <File
- RelativePath="Resource.h">
- </File>
- <File
- RelativePath="WinStun.h">
- </File>
- <File
- RelativePath="WinStunDlg.h">
- </File>
- <File
- RelativePath="stdafx.h">
- </File>
- <File
- RelativePath="..\stun.h">
- </File>
- <File
- RelativePath="..\udp.h">
- </File>
- </Filter>
- <Filter
- Name="Resource Files"
- Filter="rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;jpg;jpeg;jpe;manifest">
- <File
- RelativePath="res\WinStun.ico">
- </File>
- <File
- RelativePath="res\WinStun.manifest">
- </File>
- <File
- RelativePath="WinStun.rc">
- </File>
- <File
- RelativePath="res\WinStun.rc2">
- </File>
- </Filter>
- </Files>
- <Globals>
- </Globals>
-</VisualStudioProject>
diff --git a/libs/stund/WinStun/WinStunDlg.cpp b/libs/stund/WinStun/WinStunDlg.cpp
deleted file mode 100644
index 19507aa3c14421514403558719c5d46d2a13dbba..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStunDlg.cpp
+++ /dev/null
@@ -1,246 +0,0 @@
-
-#include "stdafx.h"
-#include "WinStun.h"
-#include "WinStunDlg.h"
-
-#include <cassert>
-
-#include "../stun.h"
-
-#ifdef _DEBUG
-#define new DEBUG_NEW
-#endif
-
-
-// CAboutDlg dialog used for App About
-
-class CAboutDlg : public CDialog
-{
-public:
- CAboutDlg();
-
-// Dialog Data
- enum { IDD = IDD_ABOUTBOX };
-
- protected:
- virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
-
-// Implementation
-protected:
- DECLARE_MESSAGE_MAP()
-};
-
-CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
-{
-}
-
-void CAboutDlg::DoDataExchange(CDataExchange* pDX)
-{
- CDialog::DoDataExchange(pDX);
-}
-
-BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
-END_MESSAGE_MAP()
-
-
-// CWinStunDlg dialog
-
-
-
-CWinStunDlg::CWinStunDlg(CWnd* pParent /*=NULL*/)
- : CDialog(CWinStunDlg::IDD, pParent)
- , mServerName(_T(""))
-{
- m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
-}
-
-void CWinStunDlg::DoDataExchange(CDataExchange* pDX)
-{
- mServerName = _T("larry.gloo.net");
- CDialog::DoDataExchange(pDX);
- DDX_Text(pDX, IDC_SERVER, mServerName);
- DDV_MaxChars(pDX, mServerName, 128);
-}
-
-BEGIN_MESSAGE_MAP(CWinStunDlg, CDialog)
- ON_WM_SYSCOMMAND()
- ON_WM_PAINT()
- ON_WM_QUERYDRAGICON()
- //}}AFX_MSG_MAP
- ON_BN_CLICKED(IDC_TEST, OnBnClickedTest)
-END_MESSAGE_MAP()
-
-
-// CWinStunDlg message handlers
-
-BOOL CWinStunDlg::OnInitDialog()
-{
- CDialog::OnInitDialog();
-
- // Add "About..." menu item to system menu.
-
- // IDM_ABOUTBOX must be in the system command range.
- ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
- ASSERT(IDM_ABOUTBOX < 0xF000);
-
- CMenu* pSysMenu = GetSystemMenu(FALSE);
- if (pSysMenu != NULL)
- {
- CString strAboutMenu;
- strAboutMenu.LoadString(IDS_ABOUTBOX);
- if (!strAboutMenu.IsEmpty())
- {
- pSysMenu->AppendMenu(MF_SEPARATOR);
- pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
- }
- }
-
- // Set the icon for this dialog. The framework does this automatically
- // when the application's main window is not a dialog
- SetIcon(m_hIcon, TRUE); // Set big icon
- SetIcon(m_hIcon, FALSE); // Set small icon
-
- // TODO: Add extra initialization here
-
- return TRUE; // return TRUE unless you set the focus to a control
-}
-
-void CWinStunDlg::OnSysCommand(UINT nID, LPARAM lParam)
-{
- if ((nID & 0xFFF0) == IDM_ABOUTBOX)
- {
- CAboutDlg dlgAbout;
- dlgAbout.DoModal();
- }
- else
- {
- CDialog::OnSysCommand(nID, lParam);
- }
-}
-
-// If you add a minimize button to your dialog, you will need the code below
-// to draw the icon. For MFC applications using the document/view model,
-// this is automatically done for you by the framework.
-
-void CWinStunDlg::OnPaint()
-{
- if (IsIconic())
- {
- CPaintDC dc(this); // device context for painting
-
- SendMessage(WM_ICONERASEBKGND, reinterpret_cast<WPARAM>(dc.GetSafeHdc()), 0);
-
- // Center icon in client rectangle
- int cxIcon = GetSystemMetrics(SM_CXICON);
- int cyIcon = GetSystemMetrics(SM_CYICON);
- CRect rect;
- GetClientRect(&rect);
- int x = (rect.Width() - cxIcon + 1) / 2;
- int y = (rect.Height() - cyIcon + 1) / 2;
-
- // Draw the icon
- dc.DrawIcon(x, y, m_hIcon);
- }
- else
- {
- CDialog::OnPaint();
- }
-}
-
-// The system calls this function to obtain the cursor to display while the user drags
-// the minimized window.
-HCURSOR CWinStunDlg::OnQueryDragIcon()
-{
- return static_cast<HCURSOR>(m_hIcon);
-}
-
-void CWinStunDlg::OnBnClickedTest()
-{
- // TODO: Add your control notification handler code here
- CString& server = mServerName;
-
- CEdit* display = (CEdit*)GetDlgItem(IDC_RESULT);
- assert(display);
- display->SetWindowText( CString( _T("Running...\r\n")) );
-
- CEdit* edit = (CEdit*)GetDlgItem(IDC_SERVER);
- assert(edit);
- edit->GetWindowText(server);
-
- StunAddress4 stunServerAddr;
-
- LPCTSTR str;
- str = server;
- char* s;
- s = (char*)str;
- stunParseServerName( s, stunServerAddr);
-
- bool verbose = false;
- StunAddress4 sAddr;
- sAddr.port = 0;
- sAddr.addr = 0;
- bool preservePort;
- bool hairpin;
- int port=0;
- NatType stype = stunNatType( stunServerAddr, verbose, &preservePort, &hairpin, port, &sAddr );
-
- CString text;
-
- switch (stype)
- {
- case StunTypeOpen:
- text = _T("No NAT detected - VoIP should work");
- break;
- case StunTypeConeNat:
- text = _T("Cone Nat detect - VoIP will work with STUN");
- break;
- case StunTypeRestrictedNat:
- text = _T("Address restricted NAT detected - VoIP will work with STUN");
- break;
- case StunTypePortRestrictedNat:
- text = _T("Port restricted NAT detected - VoIP will work with STUN");
- break;
- case StunTypeSymNat:
- text = _T("Symetric - VOIP will NOT work");
- break;
- case StunTypeSymFirewall:
- text = _T("Symetric firewall - VOIP will NOT work");
- break;
- case StunTypeBlocked:
- text = _T("Could not reach the stun server - check server name is correct");
- break;
- default:
- text = _T("Unkown NAT type");
- break;
- }
-
- text += _T("\r\n");
-
- if (preservePort)
- {
- text+= _T("Preserves port number\r\n");
- }
- else
- {
- text+= _T("Does not preserve port number\r\n");
- }
-
- if (hairpin)
- {
- text+= _T("Supports hairpin of media\r\n");
- }
- else
- {
- text+= _T("Does not supports hairpin of media\r\n");
- }
-
-
- CString strAddr;
- strAddr.Format(_T("Public IP address: %d.%d.%d.%d"),
- (sAddr.addr>>24)&0xFF,(sAddr.addr>>16)&0xFF,(sAddr.addr>>8)&0xFF,(sAddr.addr>>0)&0xFF
- );
-
- text += strAddr;
-
- display->SetWindowText( text + CString( _T("\r\n")) );
-}
diff --git a/libs/stund/WinStun/WinStunDlg.h b/libs/stund/WinStun/WinStunDlg.h
deleted file mode 100644
index 368d26018884eef176e2a9326e1b6a19a38807d8..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/WinStunDlg.h
+++ /dev/null
@@ -1,35 +0,0 @@
-// WinStunDlg.h : header file
-//
-
-#pragma once
-
-
-// CWinStunDlg dialog
-class CWinStunDlg : public CDialog
-{
-// Construction
-public:
- CWinStunDlg(CWnd* pParent = NULL); // standard constructor
-
-// Dialog Data
- enum { IDD = IDD_WINSTUN_DIALOG };
-
- protected:
- virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
-
-
-// Implementation
-protected:
- HICON m_hIcon;
-
- // Generated message map functions
- virtual BOOL OnInitDialog();
- afx_msg void OnSysCommand(UINT nID, LPARAM lParam);
- afx_msg void OnPaint();
- afx_msg HCURSOR OnQueryDragIcon();
- DECLARE_MESSAGE_MAP()
-public:
- afx_msg void OnBnClickedTest();
- // the name of the stun server to use
- CString mServerName;
-};
diff --git a/libs/stund/WinStun/res/WinStun.ico b/libs/stund/WinStun/res/WinStun.ico
deleted file mode 100644
index c920902960a34a21a46c5335471a847e43dedbfe..0000000000000000000000000000000000000000
Binary files a/libs/stund/WinStun/res/WinStun.ico and /dev/null differ
diff --git a/libs/stund/WinStun/res/WinStun.manifest b/libs/stund/WinStun/res/WinStun.manifest
deleted file mode 100644
index 39ecae9fe14e7a8eb48d4819e39a7bdd824170c8..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/res/WinStun.manifest
+++ /dev/null
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
-<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
-<assemblyIdentity
- version="1.0.0.0"
- processorArchitecture="X86"
- name="Microsoft.Windows.WinStun"
- type="win32"
-/>
-<description>Your app description here</description>
-<dependency>
- <dependentAssembly>
- <assemblyIdentity
- type="win32"
- name="Microsoft.Windows.Common-Controls"
- version="6.0.0.0"
- processorArchitecture="X86"
- publicKeyToken="6595b64144ccf1df"
- language="*"
- />
- </dependentAssembly>
-</dependency>
-</assembly>
diff --git a/libs/stund/WinStun/res/WinStun.rc2 b/libs/stund/WinStun/res/WinStun.rc2
deleted file mode 100644
index 345909a79d5e75eb0611cf8a94ba33dfb2990057..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/res/WinStun.rc2
+++ /dev/null
@@ -1,13 +0,0 @@
-//
-// WinStun.RC2 - resources Microsoft Visual C++ does not edit directly
-//
-
-#ifdef APSTUDIO_INVOKED
-#error this file is not editable by Microsoft Visual C++
-#endif //APSTUDIO_INVOKED
-
-
-/////////////////////////////////////////////////////////////////////////////
-// Add manually edited resources here...
-
-/////////////////////////////////////////////////////////////////////////////
diff --git a/libs/stund/WinStun/resource.h b/libs/stund/WinStun/resource.h
deleted file mode 100644
index 9a333540d8d59c1c2adbe6f36a568682848fffe5..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/resource.h
+++ /dev/null
@@ -1,26 +0,0 @@
-//{{NO_DEPENDENCIES}}
-// Microsoft Visual C++ generated include file.
-// Used by WinStun.rc
-//
-#define IDR_MANIFEST 1
-#define IDM_ABOUTBOX 0x0010
-#define IDD_ABOUTBOX 100
-#define IDS_ABOUTBOX 101
-#define IDD_WINSTUN_DIALOG 102
-#define IDP_SOCKETS_INIT_FAILED 103
-#define IDR_MAINFRAME 128
-#define IDC_TEST 1000
-#define IDC_SERVER 1001
-#define IDC_EDIT2 1002
-#define IDC_RESULT 1002
-
-// Next default values for new objects
-//
-#ifdef APSTUDIO_INVOKED
-#ifndef APSTUDIO_READONLY_SYMBOLS
-#define _APS_NEXT_RESOURCE_VALUE 129
-#define _APS_NEXT_COMMAND_VALUE 32771
-#define _APS_NEXT_CONTROL_VALUE 1003
-#define _APS_NEXT_SYMED_VALUE 101
-#endif
-#endif
diff --git a/libs/stund/WinStun/stdafx.cpp b/libs/stund/WinStun/stdafx.cpp
deleted file mode 100644
index e20fa31c57dc4bb29151be8c207bb2411c26372a..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/stdafx.cpp
+++ /dev/null
@@ -1,7 +0,0 @@
-// stdafx.cpp : source file that includes just the standard includes
-// WinStun.pch will be the pre-compiled header
-// stdafx.obj will contain the pre-compiled type information
-
-#include "stdafx.h"
-
-
diff --git a/libs/stund/WinStun/stdafx.h b/libs/stund/WinStun/stdafx.h
deleted file mode 100644
index 69dcbe280db7867b1ae49fe6132869a79d84fc95..0000000000000000000000000000000000000000
--- a/libs/stund/WinStun/stdafx.h
+++ /dev/null
@@ -1,43 +0,0 @@
-// stdafx.h : include file for standard system include files,
-// or project specific include files that are used frequently,
-// but are changed infrequently
-
-#pragma once
-
-#ifndef VC_EXTRALEAN
-#define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
-#endif
-
-// Modify the following defines if you have to target a platform prior to the ones specified below.
-// Refer to MSDN for the latest info on corresponding values for different platforms.
-#ifndef WINVER // Allow use of features specific to Windows 95 and Windows NT 4 or later.
-#define WINVER 0x0400 // Change this to the appropriate value to target Windows 98 and Windows 2000 or later.
-#endif
-
-#ifndef _WIN32_WINNT // Allow use of features specific to Windows NT 4 or later.
-#define _WIN32_WINNT 0x0400 // Change this to the appropriate value to target Windows 98 and Windows 2000 or later.
-#endif
-
-#ifndef _WIN32_WINDOWS // Allow use of features specific to Windows 98 or later.
-#define _WIN32_WINDOWS 0x0410 // Change this to the appropriate value to target Windows Me or later.
-#endif
-
-#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.
-#define _WIN32_IE 0x0400 // Change this to the appropriate value to target IE 5.0 or later.
-#endif
-
-#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
-
-// turns off MFC's hiding of some common and often safely ignored warning messages
-#define _AFX_ALL_WARNINGS
-
-#include <afxwin.h> // MFC core and standard components
-#include <afxext.h> // MFC extensions
-#include <afxdisp.h> // MFC Automation classes
-
-#include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls
-#ifndef _AFX_NO_AFXCMN_SUPPORT
-#include <afxcmn.h> // MFC support for Windows Common Controls
-#endif // _AFX_NO_AFXCMN_SUPPORT
-
-#include <afxsock.h> // MFC socket extensions
diff --git a/libs/stund/WinStunSetup/WinStunSetup.vdproj b/libs/stund/WinStunSetup/WinStunSetup.vdproj
deleted file mode 100644
index 71023929170c7a668fa6036c3106750d5d26e365..0000000000000000000000000000000000000000
--- a/libs/stund/WinStunSetup/WinStunSetup.vdproj
+++ /dev/null
@@ -1,797 +0,0 @@
-"DeployProject"
-{
-"VSVersion" = "3:700"
-"ProjectType" = "8:{5443560c-dbb4-11d2-8724-00a0c9a8b90c}"
-"IsWebType" = "8:FALSE"
-"ProjectName" = "8:WinStunSetup"
-"LanguageId" = "3:1033"
-"CodePage" = "3:1252"
-"UILanguageId" = "3:1033"
-"SccProjectName" = "8:"
-"SccLocalPath" = "8:"
-"SccAuxPath" = "8:"
-"SccProvider" = "8:"
- "Hierarchy"
- {
- "Entry"
- {
- "MsmKey" = "8:_09250952BF7CDB5CAADD71B62AF74DB4"
- "OwnerKey" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "MsmSig" = "8:C:\\WINDOWS\\SYSTEM32\\WSOCK32.DLL"
- }
- "Entry"
- {
- "MsmKey" = "8:_18DB37B1E06F4ECDBE22138D2E3423BA"
- "OwnerKey" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "MsmSig" = "8:VC_User_MFC.BA9B6D6E_0DE0_11D5_A548_0090278A1BB8"
- }
- "Entry"
- {
- "MsmKey" = "8:_4B317DFBE5B54D45BA632D40E0B2978C"
- "OwnerKey" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "MsmSig" = "8:VC_User_STL.BA9B76E9_0DE0_11D5_A548_0090278A1BB8"
- }
- "Entry"
- {
- "MsmKey" = "8:_4D3B42BBD8694AA0A7E8B8681774E515"
- "OwnerKey" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "MsmSig" = "8:VC_User_CRT.BA9B6D09_0DE0_11D5_A548_0090278A1BB8"
- }
- "Entry"
- {
- "MsmKey" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "OwnerKey" = "8:_UNDEFINED"
- "MsmSig" = "8:C:\\VOCAL\\STUND\\WINSTUN\\DEBUG\\WINSTUN.EXE"
- }
- }
- "Configurations"
- {
- "Debug"
- {
- "DisplayName" = "8:Debug"
- "IsDebugOnly" = "11:TRUE"
- "IsReleaseOnly" = "11:FALSE"
- "OutputFilename" = "8:Debug\\WinStunSetup.msi"
- "PackageFilesAs" = "3:2"
- "PackageFileSize" = "3:-2147483648"
- "CabType" = "3:1"
- "Compression" = "3:2"
- "SignOutput" = "11:FALSE"
- "CertificateFile" = "8:"
- "PrivateKeyFile" = "8:"
- "TimeStampServer" = "8:"
- "InstallerBootstrapper" = "3:2"
- }
- "Release"
- {
- "DisplayName" = "8:Release"
- "IsDebugOnly" = "11:FALSE"
- "IsReleaseOnly" = "11:TRUE"
- "OutputFilename" = "8:Release\\WinStunSetup.msi"
- "PackageFilesAs" = "3:2"
- "PackageFileSize" = "3:-2147483648"
- "CabType" = "3:1"
- "Compression" = "3:3"
- "SignOutput" = "11:FALSE"
- "CertificateFile" = "8:"
- "PrivateKeyFile" = "8:"
- "TimeStampServer" = "8:"
- "InstallerBootstrapper" = "3:2"
- }
- }
- "Deployable"
- {
- "CustomAction"
- {
- }
- "DefaultFeature"
- {
- "Name" = "8:DefaultFeature"
- "Title" = "8:"
- "Description" = "8:"
- }
- "Feature"
- {
- }
- "File"
- {
- "{54DA9790-1474-11D3-8E00-00C04F6837D0}:_09250952BF7CDB5CAADD71B62AF74DB4"
- {
- "Signature" = "8:2000000000e0230e7df7c201409bc8ce88f8c30100e0230e7df7c20100000000005400000000000000000000770073006f0063006b00330032002e0064006c006c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
- "SourcePath" = "8:WSOCK32.dll"
- "TargetName" = "8:WSOCK32.dll"
- "Tag" = "8:"
- "Folder" = "8:_1ACFCA01E86242009E7DA340371B556E"
- "Condition" = "8:"
- "Transitive" = "11:FALSE"
- "Vital" = "11:TRUE"
- "ReadOnly" = "11:FALSE"
- "Hidden" = "11:FALSE"
- "System" = "11:FALSE"
- "Permanent" = "11:FALSE"
- "SharedLegacy" = "11:FALSE"
- "PackageAs" = "3:1"
- "Register" = "3:1"
- "Exclude" = "11:TRUE"
- "IsDependency" = "11:TRUE"
- "IsolateTo" = "8:"
- }
- }
- "FileType"
- {
- }
- "Folder"
- {
- "{EE62640D-12F2-11D3-8D6C-00A0C9CFCEE6}:_1ACFCA01E86242009E7DA340371B556E"
- {
- "DefaultLocation" = "8:[ProgramFilesFolder][Manufacturer]\\[ProductName]"
- "Name" = "8:#1925"
- "AlwaysCreate" = "11:FALSE"
- "Condition" = "8:"
- "Transitive" = "11:FALSE"
- "Property" = "8:TARGETDIR"
- "Folders"
- {
- }
- }
- "{777C097F-0ED8-11D3-8D6C-00A0C9CFCEE6}:_9F73FB694078487ABBE751685A98BAE5"
- {
- "Name" = "8:#1919"
- "AlwaysCreate" = "11:FALSE"
- "Condition" = "8:"
- "Transitive" = "11:FALSE"
- "Property" = "8:ProgramMenuFolder"
- "Folders"
- {
- }
- }
- "{777C097F-0ED8-11D3-8D6C-00A0C9CFCEE6}:_CD285AFD3A9A4AF09C71F647BCB5F55F"
- {
- "Name" = "8:#1916"
- "AlwaysCreate" = "11:FALSE"
- "Condition" = "8:"
- "Transitive" = "11:FALSE"
- "Property" = "8:DesktopFolder"
- "Folders"
- {
- }
- }
- }
- "LaunchCondition"
- {
- }
- "Locator"
- {
- }
- "Shortcut"
- {
- "{D0C99CFE-1238-11D3-8E00-00C04F6837D0}:_9DD31FDA83A043F7A0E558517B5725D3"
- {
- "Name" = "8:WinSTUN"
- "Arguments" = "8:"
- "Description" = "8:"
- "ShowCmd" = "3:1"
- "IconIndex" = "3:0"
- "Transitive" = "11:FALSE"
- "Target" = "8:_F6B936BEEBCC457AA39994BB0B8A53A5"
- "Folder" = "8:_9F73FB694078487ABBE751685A98BAE5"
- "WorkingFolder" = "8:_1ACFCA01E86242009E7DA340371B556E"
- "Icon" = "8:"
- "Feature" = "8:"
- }
- }
- "Sequences"
- {
- }
- "Registry"
- {
- "HKLM"
- {
- "Keys"
- {
- "{7DF0CD0A-FF27-11D2-8D6B-00A0C9CFCEE6}:_40E4B8C97A03455C8DF5FA68455B929E"
- {
- "Name" = "8:Software"
- "Condition" = "8:"
- "AlwaysCreate" = "11:FALSE"
- "DeleteAtUninstall" = "11:FALSE"
- "Transitive" = "11:FALSE"
- "Keys"
- {
- "{7DF0CD0A-FF27-11D2-8D6B-00A0C9CFCEE6}:_50DC98EDDEAB4F63A5B6A17D733642C2"
- {
- "Name" = "8:[Manufacturer]"
- "Condition" = "8:"
- "AlwaysCreate" = "11:FALSE"
- "DeleteAtUninstall" = "11:FALSE"
- "Transitive" = "11:FALSE"
- "Keys"
- {
- }
- "Values"
- {
- }
- }
- }
- "Values"
- {
- }
- }
- }
- }
- "HKCU"
- {
- "Keys"
- {
- "{7DF0CD0A-FF27-11D2-8D6B-00A0C9CFCEE6}:_D404EAC782F44270A6D873736C45FB23"
- {
- "Name" = "8:Software"
- "Condition" = "8:"
- "AlwaysCreate" = "11:FALSE"
- "DeleteAtUninstall" = "11:FALSE"
- "Transitive" = "11:FALSE"
- "Keys"
- {
- "{7DF0CD0A-FF27-11D2-8D6B-00A0C9CFCEE6}:_221FC41A7DD547B182BD9DE45E0E8EB2"
- {
- "Name" = "8:[Manufacturer]"
- "Condition" = "8:"
- "AlwaysCreate" = "11:FALSE"
- "DeleteAtUninstall" = "11:FALSE"
- "Transitive" = "11:FALSE"
- "Keys"
- {
- }
- "Values"
- {
- }
- }
- }
- "Values"
- {
- }
- }
- }
- }
- "HKCR"
- {
- "Keys"
- {
- }
- }
- "HKU"
- {
- "Keys"
- {
- }
- }
- "HKPU"
- {
- "Keys"
- {
- }
- }
- }
- "ProjectOutput"
- {
- "{B1E2BB22-187D-11D3-8E02-00C04F6837D0}:_F6B936BEEBCC457AA39994BB0B8A53A5"
- {
- "SourcePath" = "8:..\\WinStun\\Release\\WinStun.exe"
- "TargetName" = "8:"
- "Tag" = "8:"
- "Folder" = "8:_1ACFCA01E86242009E7DA340371B556E"
- "Condition" = "8:"
- "Transitive" = "11:FALSE"
- "Vital" = "11:TRUE"
- "ReadOnly" = "11:FALSE"
- "Hidden" = "11:FALSE"
- "System" = "11:FALSE"
- "Permanent" = "11:FALSE"
- "SharedLegacy" = "11:FALSE"
- "PackageAs" = "3:1"
- "Register" = "3:1"
- "Exclude" = "11:FALSE"
- "IsDependency" = "11:FALSE"
- "IsolateTo" = "8:"
- "ProjectOutputGroupRegister" = "3:1"
- "OutputConfiguration" = "8:"
- "OutputGroupCanonicalName" = "8:Built"
- "OutputProjectCanonicalName" = "8:WinStun\\WinStun.vcproj"
- "OutputProjectGuid" = "8:{717021E7-DCC4-41E7-9CDA-FA7596F18C56}"
- "ShowKeyOutput" = "11:TRUE"
- "ExcludeFilters"
- {
- }
- }
- }
- "Product"
- {
- "Name" = "8:Microsoft Visual Studio"
- "ProductName" = "8:WinStun"
- "ProductCode" = "8:{8B7B86B7-1FB6-4907-AD02-B5C8D480A324}"
- "PackageCode" = "8:{63782D74-DA83-46E2-BBEA-C3448AAF05DA}"
- "UpgradeCode" = "8:{2F0F50F5-2556-4068-8E05-1BDCCFBF66D7}"
- "RestartWWWService" = "11:FALSE"
- "RemovePreviousVersions" = "11:TRUE"
- "DetectNewerInstalledVersion" = "11:TRUE"
- "ProductVersion" = "8:0.91"
- "Manufacturer" = "8:fluffy"
- "ARPHELPTELEPHONE" = "8:"
- "ARPHELPLINK" = "8:www.vovida.org"
- "Title" = "8:WinStun"
- "Subject" = "8:"
- "ARPCONTACT" = "8:fluffy"
- "Keywords" = "8:Stun"
- "ARPCOMMENTS" = "8:Stun Test Program"
- "ARPURLINFOABOUT" = "8:"
- "ARPPRODUCTICON" = "8:"
- "ARPIconIndex" = "3:0"
- "SearchPath" = "8:"
- "UseSystemSearchPath" = "11:TRUE"
- }
- "MsiBootstrapper"
- {
- "LangId" = "3:1033"
- }
- "MergeModule"
- {
- "{AC8774A4-3E09-11D3-8E14-00C04F6837D0}:_18DB37B1E06F4ECDBE22138D2E3423BA"
- {
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:TRUE"
- "SourcePath" = "8:vc_mfc.msm"
- "ModuleSignature" = "8:VC_User_MFC.BA9B6D6E_0DE0_11D5_A548_0090278A1BB8"
- "Properties"
- {
- "DIR_RETARGET_TARGETDIR"
- {
- "Name" = "8:DIR_RETARGET_TARGETDIR"
- "DisplayName" = "8:Module Retargetable Folder"
- "Description" = "8:"
- "Type" = "3:10"
- "ContextData" = "8:IsolationDir"
- "Attributes" = "3:6"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:FALSE"
- }
- }
- "LanguageId" = "3:0"
- "Exclude" = "11:FALSE"
- "Folder" = "8:"
- "Feature" = "8:"
- "IsolateTo" = "8:"
- }
- "{AC8774A4-3E09-11D3-8E14-00C04F6837D0}:_4B317DFBE5B54D45BA632D40E0B2978C"
- {
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:TRUE"
- "SourcePath" = "8:vc_stl.msm"
- "ModuleSignature" = "8:VC_User_STL.BA9B76E9_0DE0_11D5_A548_0090278A1BB8"
- "Properties"
- {
- "DIR_RETARGET_TARGETDIR"
- {
- "Name" = "8:DIR_RETARGET_TARGETDIR"
- "DisplayName" = "8:Module Retargetable Folder"
- "Description" = "8:"
- "Type" = "3:10"
- "ContextData" = "8:IsolationDir"
- "Attributes" = "3:6"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:FALSE"
- }
- }
- "LanguageId" = "3:0"
- "Exclude" = "11:FALSE"
- "Folder" = "8:"
- "Feature" = "8:"
- "IsolateTo" = "8:"
- }
- "{AC8774A4-3E09-11D3-8E14-00C04F6837D0}:_4D3B42BBD8694AA0A7E8B8681774E515"
- {
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:TRUE"
- "SourcePath" = "8:vc_crt.msm"
- "ModuleSignature" = "8:VC_User_CRT.BA9B6D09_0DE0_11D5_A548_0090278A1BB8"
- "Properties"
- {
- "DIR_RETARGET_TARGETDIR"
- {
- "Name" = "8:DIR_RETARGET_TARGETDIR"
- "DisplayName" = "8:Module Retargetable Folder"
- "Description" = "8:"
- "Type" = "3:10"
- "ContextData" = "8:IsolationDir"
- "Attributes" = "3:6"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:FALSE"
- }
- }
- "LanguageId" = "3:0"
- "Exclude" = "11:FALSE"
- "Folder" = "8:"
- "Feature" = "8:"
- "IsolateTo" = "8:"
- }
- }
- "UserInterface"
- {
- "{E4ECAB26-4AB7-11D3-8D78-00A0C9CFCEE6}:_309D912E287A4301B573A2B8BF79CA47"
- {
- "UseDynamicProperties" = "11:FALSE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdBasicDialogs.wim"
- "ModuleSignature" = "8:VsdDialogs.CE4B864F_F1C1_4B85_98D4_2A2BF5FFB12B"
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_3AAC016866E5446D98CAA124E4E70365"
- {
- "Name" = "8:#1900"
- "Sequence" = "3:2"
- "Attributes" = "3:1"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_6453CD704CE541EDB46A6A6F40AD5B11"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Welcome"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdAdminWelcomeDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.E35A0E2C_F131_4B57_B946_59A1A2A8F45F"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- "CopyrightWarning"
- {
- "Name" = "8:CopyrightWarning"
- "DisplayName" = "8:#1002"
- "Description" = "8:#1102"
- "Type" = "3:3"
- "ContextData" = "8:"
- "Attributes" = "3:0"
- "Setting" = "3:1"
- "Value" = "8:#1202"
- "DefaultValue" = "8:#1202"
- "UsePlugInResources" = "11:TRUE"
- }
- "Welcome"
- {
- "Name" = "8:Welcome"
- "DisplayName" = "8:#1003"
- "Description" = "8:#1103"
- "Type" = "3:3"
- "ContextData" = "8:"
- "Attributes" = "3:0"
- "Setting" = "3:1"
- "Value" = "8:#1203"
- "DefaultValue" = "8:#1203"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_8866EC8182F44659BA8DB0975A01235C"
- {
- "Sequence" = "3:200"
- "DisplayName" = "8:Installation Folder"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdAdminFolderDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.2DED2424_5429_4616_A1AD_4D62837C2ADA"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_93025AA9E4EB456B92CEA130A0F3BCF4"
- {
- "Sequence" = "3:300"
- "DisplayName" = "8:Confirm Installation"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdAdminConfirmDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.FA58E60A_A1E8_4876_95FC_2AC3B5AAA5F8"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_3EA2C9B465F54D72A7DDDFCC5621F1D0"
- {
- "Name" = "8:#1902"
- "Sequence" = "3:1"
- "Attributes" = "3:3"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_16667F6AD73F471591FDCB7F4172769C"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Finished"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdFinishedDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.1DB77F5A_BA5C_4470_89B6_0B0EC07E3A10"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_91E8D85BC8534AFE80406ED50E981274"
- {
- "Name" = "8:#1902"
- "Sequence" = "3:2"
- "Attributes" = "3:3"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_8BD23B7A446C400F965A22995B56653C"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Finished"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdAdminFinishedDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.83D22742_1B79_46f6_9A99_DF0F2BD4C077"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_A4071551ACF7452A8194ECACD3822A24"
- {
- "Name" = "8:#1901"
- "Sequence" = "3:2"
- "Attributes" = "3:2"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_487DF826178549ADAA991554EE93AC62"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Progress"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdAdminProgressDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.EE9A1AFA_41DD_4514_B727_DF0ACA1D7389"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- "ShowProgress"
- {
- "Name" = "8:ShowProgress"
- "DisplayName" = "8:#1009"
- "Description" = "8:#1109"
- "Type" = "3:5"
- "ContextData" = "8:1;True=1;False=0"
- "Attributes" = "3:0"
- "Setting" = "3:0"
- "Value" = "3:1"
- "DefaultValue" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- "{E4ECAB26-4AB7-11D3-8D78-00A0C9CFCEE6}:_B77D9D04895542BC9E437226DBC206BA"
- {
- "UseDynamicProperties" = "11:FALSE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdUserInterface.wim"
- "ModuleSignature" = "8:VsdUserInterface.524F4245_5254_5341_4C45_534153783400"
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_CB82D982E7E04D1BB99B02029BFF4BB4"
- {
- "Name" = "8:#1900"
- "Sequence" = "3:1"
- "Attributes" = "3:1"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_1C9C413826E7442292BDADA01492608D"
- {
- "Sequence" = "3:200"
- "DisplayName" = "8:Installation Folder"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdFolderDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.C113BC36_2532_4D45_8099_4818B1133B2F"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_9949CC0ADBD947A7B1C91226942F4FEE"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Welcome"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdWelcomeDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.68F69290_BB7C_474E_A153_6679845F3DDF"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- "CopyrightWarning"
- {
- "Name" = "8:CopyrightWarning"
- "DisplayName" = "8:#1002"
- "Description" = "8:#1102"
- "Type" = "3:3"
- "ContextData" = "8:"
- "Attributes" = "3:0"
- "Setting" = "3:1"
- "Value" = "8:#1202"
- "DefaultValue" = "8:#1202"
- "UsePlugInResources" = "11:TRUE"
- }
- "Welcome"
- {
- "Name" = "8:Welcome"
- "DisplayName" = "8:#1003"
- "Description" = "8:#1103"
- "Type" = "3:3"
- "ContextData" = "8:"
- "Attributes" = "3:0"
- "Setting" = "3:1"
- "Value" = "8:#1203"
- "DefaultValue" = "8:#1203"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_C35965DAA3654FD188EB3BE51C84178E"
- {
- "Sequence" = "3:300"
- "DisplayName" = "8:Confirm Installation"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdConfirmDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.6DBC9783_3677_4D68_8BF5_D749558A0AC1"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- "{7DFFC192-4ABE-11D3-8D78-00A0C9CFCEE6}:_F18016A4BE774D76B6D7D70741C9C574"
- {
- "Name" = "8:#1901"
- "Sequence" = "3:1"
- "Attributes" = "3:2"
- "Dialogs"
- {
- "{E4ECAB24-4AB7-11D3-8D78-00A0C9CFCEE6}:_4CBDFAD72B2541849D7DFA35D5E52B1F"
- {
- "Sequence" = "3:100"
- "DisplayName" = "8:Progress"
- "UseDynamicProperties" = "11:TRUE"
- "IsDependency" = "11:FALSE"
- "SourcePath" = "8:<VsdDialogDir>\\VsdProgressDlg.wid"
- "ModuleSignature" = "8:VsdDialogs.4FB12620_0D15_42D0_8677_2766FFA6923F"
- "Properties"
- {
- "BannerBitmap"
- {
- "Name" = "8:BannerBitmap"
- "DisplayName" = "8:#1001"
- "Description" = "8:#1101"
- "Type" = "3:8"
- "ContextData" = "8:Bitmap"
- "Attributes" = "3:4"
- "Setting" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- "ShowProgress"
- {
- "Name" = "8:ShowProgress"
- "DisplayName" = "8:#1009"
- "Description" = "8:#1109"
- "Type" = "3:5"
- "ContextData" = "8:1;True=1;False=0"
- "Attributes" = "3:0"
- "Setting" = "3:0"
- "Value" = "3:1"
- "DefaultValue" = "3:1"
- "UsePlugInResources" = "11:TRUE"
- }
- }
- }
- }
- }
- }
- }
-}
diff --git a/libs/stund/client.cxx b/libs/stund/client.cxx
deleted file mode 100644
index 87b23dfe7172c2e2d30f33aa971568126e820d33..0000000000000000000000000000000000000000
--- a/libs/stund/client.cxx
+++ /dev/null
@@ -1,399 +0,0 @@
-#include <cassert>
-#include <cstring>
-#include <iostream>
-#include <cstdlib>
-
-#ifdef WIN32
-#include <time.h>
-#else
-#include <sys/time.h>
-#include <sys/types.h>
-#include <unistd.h>
-#include <netinet/in.h>
-#include <errno.h>
-#endif
-
-#include "udp.h"
-#include "stun.h"
-
-using namespace std;
-
-
-void
-usage()
-{
- cerr << "Usage:" << endl
- << " ./client stunServerHostname [testNumber] [-v] [-p srcPort] [-i nicAddr1] [-i nicAddr2] [-i nicAddr3]" << endl
- << "For example, if the STUN server was larry.gloo.net, you could do:" << endl
- << " ./client larry.gloo.net" << endl
- << "The testNumber is just used for special tests." << endl
- << " test 1 runs test 1 from the RFC. For example:" << endl
- << " ./client larry.gloo.net 0" << endl << endl
- << "Return Values:" << endl
- << " -1 Generic Error" << endl << endl
- << "low order bits (mask 0x07)" << endl
- << " 0 No NAT Present (Open)" << endl
- << " 1 Full Cone NAT" << endl
- << " 2 Address Restricted Cone NAT" << endl
- << " 3 Port Restricted Cone NAT" << endl
- << " 4 Symmetric NAT" << endl
- << " 5 Symmetric Firewall" << endl
- << " 6 Blocked or Network Error" << endl
- << "0x08 bit is set if the NAT does NOT supports hairpinning" << endl
- << "0x10 bit is set if the NAT tries to preserver port numbers" << endl
- << endl;
-}
-
-#define MAX_NIC 3
-
-int
-main(int argc, char* argv[])
-{
- assert( sizeof(UInt8 ) == 1 );
- assert( sizeof(UInt16) == 2 );
- assert( sizeof(UInt32) == 4 );
-
- initNetwork();
-
- cout << "STUN client version " << STUN_VERSION << endl;
-
- int testNum = 0;
- bool verbose = false;
-
- StunAddress4 stunServerAddr;
- stunServerAddr.addr=0;
-
- int srcPort=0;
- StunAddress4 sAddr[MAX_NIC];
- int retval[MAX_NIC];
- int numNic=0;
-
- for ( int i=0; i<MAX_NIC; i++ )
- {
- sAddr[i].addr=0;
- sAddr[i].port=0;
- retval[i]=0;
- }
-
- for ( int arg = 1; arg<argc; arg++ )
- {
- if ( !strcmp( argv[arg] , "-v" ) )
- {
- verbose = true;
- }
- else if ( !strcmp( argv[arg] , "-i" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- if ( numNic >= MAX_NIC )
- {
- cerr << "Can not have more than "<< MAX_NIC <<" -i options" << endl;
- usage();
- exit(-1);
- }
-
- stunParseServerName(argv[arg], sAddr[numNic++]);
- }
- else if ( !strcmp( argv[arg] , "-p" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- srcPort = strtol( argv[arg], NULL, 10);
- }
- else
- {
- char* ptr;
- int t = strtol( argv[arg], &ptr, 10 );
- if ( *ptr == 0 )
- {
- // conversion worked
- testNum = t;
- cout << "running test number " << testNum << endl;
- }
- else
- {
- bool ret = stunParseServerName( argv[arg], stunServerAddr);
- if ( ret != true )
- {
- cerr << argv[arg] << " is not a valid host name " << endl;
- usage();
- exit(-1);
- }
- }
- }
- }
-
- if ( numNic == 0 )
- {
- // use default
- numNic = 1;
- }
-
- for ( int nic=0; nic<numNic; nic++ )
- {
- sAddr[nic].port=srcPort;
- if ( stunServerAddr.addr == 0 )
- {
- usage();
- exit(-1);
- }
-
- if (testNum==0)
- {
- bool presPort=false;
- bool hairpin=false;
-
- NatType stype = stunNatType( stunServerAddr, verbose, &presPort, &hairpin,
- srcPort, &sAddr[nic]);
-
- if ( nic == 0 )
- {
- cout << "Primary: ";
- }
- else
- {
- cout << "Secondary: ";
- }
-
- switch (stype)
- {
- case StunTypeFailure:
- cout << "Some error detetecting NAT type";
- retval[nic] = -1;
- exit(-1);
- break;
- case StunTypeUnknown:
- cout << "Some error detetecting NAT type";
- retval[nic] = 0x07;
- break;
- case StunTypeOpen:
- cout << "Open";
- retval[nic] = 0;
- break;
- case StunTypeConeNat:
- cout << "Full Cone Nat";
- if ( presPort ) cout << ", preserves ports"; else cout << ", random port";
- if ( hairpin ) cout << ", will hairpin"; else cout << ", no hairpin";
- retval[nic] = 0x01;
- break;
- case StunTypeRestrictedNat:
- cout << "Address Restricted Nat";
- if ( presPort ) cout << ", preserves ports"; else cout << ", random port";
- if ( hairpin ) cout << ", will hairpin"; else cout << ", no hairpin";
- retval[nic] = 0x02;
- break;
- case StunTypePortRestrictedNat:
- cout << "Port Restricted Nat";
- if ( presPort ) cout << ", preserves ports"; else cout << ", random port";
- if ( hairpin ) cout << ", will hairpin"; else cout << ", no hairpin";
- retval[nic] = 0x03;
- break;
- case StunTypeSymNat:
- cout << "Symmetric Nat";
- if ( presPort ) cout << ", preserves ports"; else cout << ", random port";
- if ( hairpin ) cout << ", will hairpin"; else cout << ", no hairpin";
- retval[nic] = 0x04;
- break;
- case StunTypeSymFirewall:
- cout << "Symmetric Firewall";
- if ( hairpin ) cout << ", will hairpin"; else cout << ", no hairpin";
- retval[nic] = 0x05;
- break;
- case StunTypeBlocked:
- cout << "Blocked or could not reach STUN server";
- retval[nic] = 0x06;
- break;
- default:
- cout << stype;
- cout << "Unkown NAT type";
- retval[nic] = 0x07; // Unknown NAT type
- break;
- }
- cout << "\t"; cout.flush();
-
- if (!hairpin)
- {
- retval[nic] |= 0x08;
- }
-
- if (presPort)
- {
- retval[nic] |= 0x10;
- }
- }
- else if (testNum==100)
- {
- Socket myFd = openPort(srcPort,sAddr[nic].addr,verbose);
-
- StunMessage req;
- memset(&req, 0, sizeof(StunMessage));
-
- StunAtrString username;
- StunAtrString password;
- username.sizeValue = 0;
- password.sizeValue = 0;
-
- stunBuildReqSimple( &req, username,
- false , false ,
- 0x0c );
-
- char buf[STUN_MAX_MESSAGE_SIZE];
- int len = STUN_MAX_MESSAGE_SIZE;
-
- len = stunEncodeMessage( req, buf, len, password,verbose );
-
- if ( verbose )
- {
- cout << "About to send msg of len " << len
- << " to " << stunServerAddr << endl;
- }
-
- while (1)
- {
- for ( int i=0; i<100; i++ )
- {
- sendMessage( myFd,
- buf, len,
- stunServerAddr.addr,
- stunServerAddr.port,verbose );
- }
-#ifdef WIN32 // !cj! TODO - should fix this up in windows
- clock_t now = clock();
- assert( CLOCKS_PER_SEC == 1000 );
- while ( clock() <= now+10 ) { };
-#else
- usleep(10*1000);
-#endif
- }
- }
- else if (testNum==-2)
- {
- const int numPort = 5;
- int fd[numPort];
- StunAddress4 mappedAddr;
-
- for( int i=0; i<numPort; i++ )
- {
- fd[i] = stunOpenSocket( stunServerAddr, &mappedAddr,
- (srcPort==0)?0:(srcPort+i), &sAddr[nic],
- verbose );
- cout << "Got port at " << mappedAddr.port << endl;
- }
-
- for( int i=0; i<numPort; i++ )
- {
- closesocket(fd[i]);
- }
- }
- else if (testNum==-1)
- {
- int fd3,fd4;
- StunAddress4 mappedAddr;
-
- bool ok = stunOpenSocketPair(stunServerAddr,
- &mappedAddr,
- &fd3,
- &fd4,
- srcPort,
- &sAddr[nic],
- verbose);
- if ( ok )
- {
- closesocket(fd3);
- closesocket(fd4);
- cout << "Got port pair at " << mappedAddr.port << endl;
- }
- else
- {
- cerr << "Opened a stun socket pair FAILED" << endl;
- }
- }
- else
- {
- stunTest( stunServerAddr,testNum,verbose,&(sAddr[nic]) );
- }
- } // end of for loop
- cout << endl;
-
- UInt32 ret=0;
- for ( int i=numNic-1; i>=0; i-- )
- {
- if ( retval[i] == -1 )
- {
- ret = 0xFFFFFFFF;
- break;
- }
- ret = ret << 8;
- ret = ret | ( retval[i] & 0xFF );
- }
-
- cout << "Return value is " << hex << "0x" << ret << dec << endl;
-
- return ret;
-}
-
-
-/* ====================================================================
- * The Vovida Software License, Version 1.0
- *
- * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. The names "VOCAL", "Vovida Open Communication Application Library",
- * and "Vovida Open Communication Application Library (VOCAL)" must
- * not be used to endorse or promote products derived from this
- * software without prior written permission. For written
- * permission, please contact vocal@vovida.org.
- *
- * 4. Products derived from this software may not be called "VOCAL", nor
- * may "VOCAL" appear in their name, without prior written
- * permission of Vovida Networks, Inc.
- *
- * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
- * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA
- * NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES
- * IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
- * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
- * DAMAGE.
- *
- * ====================================================================
- *
- * This software consists of voluntary contributions made by Vovida
- * Networks, Inc. and many individuals on behalf of Vovida Networks,
- * Inc. For more information on Vovida Networks, Inc., please see
- * <http://www.vovida.org/>.
- *
- */
-
-// Local Variables:
-// mode:c++
-// c-file-style:"ellemtel"
-// c-file-offsets:((case-label . +))
-// indent-tabs-mode:nil
-// End:
diff --git a/libs/stund/client.sln b/libs/stund/client.sln
deleted file mode 100644
index 007f252883a669ad535fa4593f22e1fc559f53fa..0000000000000000000000000000000000000000
--- a/libs/stund/client.sln
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsoft Visual Studio Solution File, Format Version 7.00
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "client", "client.vcproj", "{76E56991-C964-444B-82A6-AFDA5145E18A}"
-EndProject
-Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug
- ConfigName.1 = Release
- EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Debug.ActiveCfg = Debug|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Debug.Build.0 = Debug|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Release.ActiveCfg = Release|Win32
- {76E56991-C964-444B-82A6-AFDA5145E18A}.Release.Build.0 = Release|Win32
- EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
-EndGlobal
diff --git a/libs/stund/client.vcproj b/libs/stund/client.vcproj
deleted file mode 100644
index d9694121e69efdc4a3d033494304a0ee91d8de7d..0000000000000000000000000000000000000000
--- a/libs/stund/client.vcproj
+++ /dev/null
@@ -1,134 +0,0 @@
-<?xml version="1.0" encoding = "Windows-1252"?>
-<VisualStudioProject
- ProjectType="Visual C++"
- Version="7.00"
- Name="client"
- ProjectGUID="{76E56991-C964-444B-82A6-AFDA5145E18A}"
- Keyword="Win32Proj">
- <Platforms>
- <Platform
- Name="Win32"/>
- </Platforms>
- <Configurations>
- <Configuration
- Name="Debug|Win32"
- OutputDirectory="ClientDebug"
- IntermediateDirectory="ClientDebug"
- ConfigurationType="1"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="0"
- PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
- MinimalRebuild="TRUE"
- BasicRuntimeChecks="3"
- RuntimeLibrary="5"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="4"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- AdditionalDependencies="Ws2_32.lib"
- OutputFile="$(OutDir)/client.exe"
- LinkIncremental="2"
- GenerateDebugInformation="TRUE"
- ProgramDatabaseFile="$(OutDir)/client.pdb"
- SubSystem="1"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- <Configuration
- Name="Release|Win32"
- OutputDirectory="ClientRelease"
- IntermediateDirectory="ClientRelease"
- ConfigurationType="1"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="2"
- InlineFunctionExpansion="1"
- OmitFramePointers="TRUE"
- PreprocessorDefinitions="WIN32;NDEBUG;_CONSOLE"
- StringPooling="TRUE"
- RuntimeLibrary="4"
- EnableFunctionLevelLinking="TRUE"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="3"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- AdditionalDependencies="Ws2_32.lib"
- OutputFile="$(OutDir)/client.exe"
- LinkIncremental="1"
- GenerateDebugInformation="TRUE"
- SubSystem="1"
- OptimizeReferences="2"
- EnableCOMDATFolding="2"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- </Configurations>
- <Files>
- <Filter
- Name="Source Files"
- Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm">
- <File
- RelativePath="client.cxx">
- </File>
- <File
- RelativePath="stun.cxx">
- </File>
- <File
- RelativePath="udp.cxx">
- </File>
- </Filter>
- <Filter
- Name="Header Files"
- Filter="h;hpp;hxx;hm;inl;inc">
- <File
- RelativePath="stun.h">
- </File>
- <File
- RelativePath="udp.h">
- </File>
- </Filter>
- <Filter
- Name="Resource Files"
- Filter="rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe">
- </Filter>
- </Files>
- <Globals>
- </Globals>
-</VisualStudioProject>
diff --git a/libs/stund/id.pem b/libs/stund/id.pem
deleted file mode 100644
index 184c4619a4cebd5fdc9e07c84f4d44626f8e228a..0000000000000000000000000000000000000000
--- a/libs/stund/id.pem
+++ /dev/null
@@ -1,15 +0,0 @@
------BEGIN CERTIFICATE-----
-MIICazCCAdQCAQMwDQYJKoZIhvcNAQEEBQAwgYAxCzAJBgNVBAYTAlVBMQswCQYD
-VQQIEwJDQTERMA8GA1UEBxMITWlscGl0YXMxDjAMBgNVBAoTBUZvb0NvMRMwEQYD
-VQQLEwp3aWRnZXQgZGl2MRIwEAYDVQQDEwlsb2NhbGhvc3QxGDAWBgkqhkiG9w0B
-CQEWCWZvb0Bmb28uYzAeFw0wMjExMDEwMzUyMjhaFw0wMjEyMDEwMzUyMjhaMHsx
-CzAJBgNVBAYTAkdCMRIwEAYDVQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB05ld2J1
-cnkxFzAVBgNVBAoTDk15IENvbXBhbnkgTHRkMRIwEAYDVQQDEwlsb2NhbGhvc3Qx
-GTAXBgkqhkiG9w0BCQEWCnNlcnZlci5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
-MIGJAoGBAO0DwcHArwHx2XoX3XAcjc9lc/ERveDqFO9NJChtA2R3/b7EaH4FOlv1
-QxL5aaCxiwhqHVo7F/BG2OxcIIBCp8HBLRYwmKnWwta4s4imD3ZI/AAaTPm5r/KJ
-GbAh0vpF7WIdtsEOaSYbnLVnQTXTgfswgoH502sM13fVY0qJhjrTAgMBAAEwDQYJ
-KoZIhvcNAQEEBQADgYEAUSwhHT7j9ammZBo/VHT8mZylqOzBakMuASiUQNwL40sc
-0eb3MtKEg2GLlX8GtB0g2+bieA337XSXe4kyhpQ7j9ClajI3Dpr463ZKLJ43JFH0
-Ynqkfo61d9fQYtxJTXjYIatzLNXpzsxADEQ2MGokQmEMGJcBftLdMfvtOy8Kh7I=
------END CERTIFICATE-----
diff --git a/libs/stund/id_key.pem b/libs/stund/id_key.pem
deleted file mode 100644
index d8c4973181c6d8920037a9985b068ee1551243b8..0000000000000000000000000000000000000000
--- a/libs/stund/id_key.pem
+++ /dev/null
@@ -1,15 +0,0 @@
------BEGIN RSA PRIVATE KEY-----
-MIICXQIBAAKBgQDtA8HBwK8B8dl6F91wHI3PZXPxEb3g6hTvTSQobQNkd/2+xGh+
-BTpb9UMS+WmgsYsIah1aOxfwRtjsXCCAQqfBwS0WMJip1sLWuLOIpg92SPwAGkz5
-ua/yiRmwIdL6Re1iHbbBDmkmG5y1Z0E104H7MIKB+dNrDNd31WNKiYY60wIDAQAB
-AoGAJt7C2/+5s9vyCq/3RPep2iWNSi/asBQzsrs3/tlCASwclTio2mIJHCOxCF+X
-Dx+O6aZdgfrHBkTYNos1WVOVJ0S3K47HQ5gPZgIus855SEmfINzJkTPz0kahjUj9
-hMeKfmtM6uRqkVcs+H35chhXg2rW0uQRP3tlgd5wq+uRjoECQQD30oykMIbA32i6
-nHw1u1zJNZXaABoUsXlu5ylwXZp39FYxQiMmwTzI7AJAKTCf2YiHP4C9YLKnjKMo
-8D+HudAxAkEA9NXo91TuOYtxYn3NJi4FCpo+hcrHH33M+ttB8L+lO9ctgzGuvI63
-pNszIVTNnV+RwnSyR+CtO7q/PQOcrK8eQwJAVCXVBYdIqkLxv7OU5XXKKrQcPtqc
-AHzGm+a4BmRyJ9r6TV2ErAsfRaYFmZ2i2hQ2LJ5ea29jGktBt4vkNoTccQJBAL49
-dE6ybITEJ+8axwwSmBI79bbp8D0099A4DA2wLAjKUu/s69RRpLpxJFKS3U2aE90f
-5eNZ3eFaYvxa0SOQ0pcCQQDEaX+MPPNUlOk4Im7XTaiT/qQDJyIHyl7+UeHOZbvN
-X9HHnTnImOk38K3zFpEvCF9LHR3BTUzVcOEIPR/3hTor
------END RSA PRIVATE KEY-----
diff --git a/libs/stund/nattest b/libs/stund/nattest
deleted file mode 100644
index fb8e71daa8f0ee5ba898832213a032ac31241a54..0000000000000000000000000000000000000000
--- a/libs/stund/nattest
+++ /dev/null
@@ -1,54 +0,0 @@
-#!/bin/bash
-# nattest shell script
-
-# set defaults
-# Interfaces typically begin eth on Linux, en on Macintosh, le or hme on Solaris
-# type ifconfig -a or ifconfig -l to see a list of all interfaces
-serverint=eth0
-clientint=eth1
-serverip1=1.1.1.2
-serverip2=1.1.1.3
-servermask=255.255.255.0
-clientip1=192.168.0.2
-clientip2=192.168.0.3
-clientmask=255.255.255.0
-
-# print warning, get confirmation
-cat nattestwarning.txt
-read -p "Are you sure you want to run this? [yes]" confirm
-case $confirm in
- [nN] ) exit;;
- [nN][oO] ) exit;;
-esac
-
-# off we go then....
-# add second IP address to each interface
-ifconfig $serverint $serverip2 netmask 255.255.255.255 alias
-ifconfig $clientint $clientip2 netmask 255.255.255.255 alias
-# for Solaris, use these instead
-# ifconfig ${serverint}:1 $serverip2 netmask $servermask
-# ifconfig ${clientint}:1 $clientip2 netmask $clientmask
-
-./stund -h $serverip1 -a $serverip2 -b
-# verify server is running
-
-./stunner $serverip1 -i $clientip1 -i2 $clientip2
-# process results of stunner and print pass/fail
-case "$?" in
- 10 ) echo "[PASS] (Address) Restricted Cone NAT with Hairpinning";;
- 11 ) echo "[PASS] Port Restricted Cone NAT with Hairpinning";;
- 8 ) echo "[No NAT] You have open internet access";;
- 2 ) echo "[FAIL] Your (Address) Restricted Cone NAT doesn't do hairpinning";;
- 3 ) echo "[FAIL] Your Port Restricted Cone NAT doesn't do hairpinning";;
- -1 ) echo "ERROR! the STUN test program had an error";;
- * ) echo "[FAIL] You have a NAT or Firewall type which is NOT RECOMMENDED.";;
-esac
-
-# cleanup
-killall -HUP stund
-ifconfig $serverint $serverip2 -alias
-ifconfig $clientint $clientip2 -alias
-# for Solaris, use these instead
-# ifconfig ${serverint}:1 unplumb
-# ifconfig ${clientint}:1 unplumb
-
diff --git a/libs/stund/nattestwarning.txt b/libs/stund/nattestwarning.txt
deleted file mode 100644
index 48c536a4a584a717a466ab14ed9071570600566c..0000000000000000000000000000000000000000
--- a/libs/stund/nattestwarning.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-WARNING: This script runs as "root" and makes changes to your network interface
-configuration. This script makes several assumptions about the test environment
-you might be using. Several of these assumptions may not hold in your environment
-and could cause you to lose all connectivity to this or other computers.
-It is designed to be run from the console on two networks which are connected
-only to a NAT in a configuration like the one shown below:
-
- Logical Configuration
-
- +--------+
- | STUN |192.168.0.2 +-------+
- | Client |---------------| |
- +--------+ | |public +--------+
- | |side | STUN | 1.1.1.2
- 192.168.0.1 | NAT |------------| Server | 1.1.1.3
- private side| |1.1.1.1 +--------+
- | |
- +--------+ | |
- | STUN |---------------| |
- | Client |192.168.0.3 +-------+
- +--------+
-
-The test actually just requires a single computer with two interfaces which acts
-as a STUN server and a pair of cooperating STUN clients. The physical configuration
-is shown below. First plug in the NAT and computer and configure the primary IP
-interface on each interface. There should be no other computers or networks
-connected to the test bed.
-
- Physical Configuration
-
- Private Public
- or "inside" or "outside"
- interface +--------------+ interface
- | NAT device |
- 192.168.0.1 +-----| under |-----+ 1.1.1.1
- | | test | |
- | | | |
- | +--------------+ |
- | |
- | |
- | +--------------+ |
- | | test | |
- 192.168.0.2 +-----| computer |-----+ 1.1.1.2
- 192.168.0.3 eth1| |eth0 1.1.1.3
- | |
- +--------------+
-
diff --git a/libs/stund/rfc3489.txt b/libs/stund/rfc3489.txt
deleted file mode 100644
index 226b4a633c8e3a5da5de62cf5ece793bf0741723..0000000000000000000000000000000000000000
--- a/libs/stund/rfc3489.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Rosenberg
-Request for Comments: 3489 J. Weinberger
-Category: Standards Track dynamicsoft
- C. Huitema
- Microsoft
- R. Mahy
- Cisco
- March 2003
-
-
- STUN - Simple Traversal of User Datagram Protocol (UDP)
- Through Network Address Translators (NATs)
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- Simple Traversal of User Datagram Protocol (UDP) Through Network
- Address Translators (NATs) (STUN) is a lightweight protocol that
- allows applications to discover the presence and types of NATs and
- firewalls between them and the public Internet. It also provides the
- ability for applications to determine the public Internet Protocol
- (IP) addresses allocated to them by the NAT. STUN works with many
- existing NATs, and does not require any special behavior from them.
- As a result, it allows a wide variety of applications to work through
- existing NAT infrastructure.
-
-Table of Contents
-
- 1. Applicability Statement ................................... 3
- 2. Introduction .............................................. 3
- 3. Terminology ............................................... 4
- 4. Definitions ............................................... 5
- 5. NAT Variations ............................................ 5
- 6. Overview of Operation ..................................... 6
- 7. Message Overview .......................................... 8
- 8. Server Behavior ........................................... 10
- 8.1 Binding Requests .................................... 10
-
-
-
-Rosenberg, et al. Standards Track [Page 1]
-
-RFC 3489 STUN March 2003
-
-
- 8.2 Shared Secret Requests .............................. 13
- 9. Client Behavior ........................................... 14
- 9.1 Discovery ........................................... 15
- 9.2 Obtaining a Shared Secret ........................... 15
- 9.3 Formulating the Binding Request ..................... 17
- 9.4 Processing Binding Responses ........................ 17
- 10. Use Cases ................................................. 19
- 10.1 Discovery Process ................................... 19
- 10.2 Binding Lifetime Discovery .......................... 21
- 10.3 Binding Acquisition ................................. 23
- 11. Protocol Details .......................................... 24
- 11.1 Message Header ...................................... 25
- 11.2 Message Attributes .................................. 26
- 11.2.1 MAPPED-ADDRESS .............................. 27
- 11.2.2 RESPONSE-ADDRESS ............................ 27
- 11.2.3 CHANGED-ADDRESS ............................. 28
- 11.2.4 CHANGE-REQUEST .............................. 28
- 11.2.5 SOURCE-ADDRESS .............................. 28
- 11.2.6 USERNAME .................................... 28
- 11.2.7 PASSWORD .................................... 29
- 11.2.8 MESSAGE-INTEGRITY ........................... 29
- 11.2.9 ERROR-CODE .................................. 29
- 11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
- 11.2.11 REFLECTED-FROM .............................. 31
- 12. Security Considerations ................................... 31
- 12.1 Attacks on STUN ..................................... 31
- 12.1.1 Attack I: DDOS Against a Target ............. 32
- 12.1.2 Attack II: Silencing a Client ............... 32
- 12.1.3 Attack III: Assuming the Identity of a Client 32
- 12.1.4 Attack IV: Eavesdropping .................... 33
- 12.2 Launching the Attacks ............................... 33
- 12.2.1 Approach I: Compromise a Legitimate
- STUN Server ................................. 33
- 12.2.2 Approach II: DNS Attacks .................... 34
- 12.2.3 Approach III: Rogue Router or NAT ........... 34
- 12.2.4 Approach IV: MITM ........................... 35
- 12.2.5 Approach V: Response Injection Plus DoS ..... 35
- 12.2.6 Approach VI: Duplication .................... 35
- 12.3 Countermeasures ..................................... 36
- 12.4 Residual Threats .................................... 37
- 13. IANA Considerations ....................................... 38
- 14. IAB Considerations ........................................ 38
- 14.1 Problem Definition .................................. 38
- 14.2 Exit Strategy ....................................... 39
- 14.3 Brittleness Introduced by STUN ...................... 40
- 14.4 Requirements for a Long Term Solution ............... 42
- 14.5 Issues with Existing NAPT Boxes ..................... 43
- 14.6 In Closing .......................................... 43
-
-
-
-Rosenberg, et al. Standards Track [Page 2]
-
-RFC 3489 STUN March 2003
-
-
- 15. Acknowledgments ........................................... 44
- 16. Normative References ...................................... 44
- 17. Informative References .................................... 44
- 18. Authors' Addresses ........................................ 46
- 19. Full Copyright Statement................................... 47
-
-1. Applicability Statement
-
- This protocol is not a cure-all for the problems associated with NAT.
- It does not enable incoming TCP connections through NAT. It allows
- incoming UDP packets through NAT, but only through a subset of
- existing NAT types. In particular, STUN does not enable incoming UDP
- packets through symmetric NATs (defined below), which are common in
- large enterprises. STUN's discovery procedures are based on
- assumptions on NAT treatment of UDP; such assumptions may prove
- invalid down the road as new NAT devices are deployed. STUN does not
- work when it is used to obtain an address to communicate with a peer
- which happens to be behind the same NAT. STUN does not work when the
- STUN server is not in a common shared address realm. For a more
- complete discussion of the limitations of STUN, see Section 14.
-
-2. Introduction
-
- Network Address Translators (NATs), while providing many benefits,
- also come with many drawbacks. The most troublesome of those
- drawbacks is the fact that they break many existing IP applications,
- and make it difficult to deploy new ones. Guidelines have been
- developed [8] that describe how to build "NAT friendly" protocols,
- but many protocols simply cannot be constructed according to those
- guidelines. Examples of such protocols include almost all peer-to-
- peer protocols, such as multimedia communications, file sharing and
- games.
-
- To combat this problem, Application Layer Gateways (ALGs) have been
- embedded in NATs. ALGs perform the application layer functions
- required for a particular protocol to traverse a NAT. Typically,
- this involves rewriting application layer messages to contain
- translated addresses, rather than the ones inserted by the sender of
- the message. ALGs have serious limitations, including scalability,
- reliability, and speed of deploying new applications. To resolve
- these problems, the Middlebox Communications (MIDCOM) protocol is
- being developed [9]. MIDCOM allows an application entity, such as an
- end client or network server of some sort (like a Session Initiation
- Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order
- to obtain NAT bindings and open or close pinholes. In this way, NATs
- and applications can be separated once more, eliminating the need for
- embedding ALGs in NATs, and resolving the limitations imposed by
- current architectures.
-
-
-
-Rosenberg, et al. Standards Track [Page 3]
-
-RFC 3489 STUN March 2003
-
-
- Unfortunately, MIDCOM requires upgrades to existing NAT and
- firewalls, in addition to application components. Complete upgrades
- of these NAT and firewall products will take a long time, potentially
- years. This is due, in part, to the fact that the deployers of NAT
- and firewalls are not the same people who are deploying and using
- applications. As a result, the incentive to upgrade these devices
- will be low in many cases. Consider, for example, an airport
- Internet lounge that provides access with a NAT. A user connecting
- to the NATed network may wish to use a peer-to-peer service, but
- cannot, because the NAT doesn't support it. Since the administrators
- of the lounge are not the ones providing the service, they are not
- motivated to upgrade their NAT equipment to support it, using either
- an ALG, or MIDCOM.
-
- Another problem is that the MIDCOM protocol requires that the agent
- controlling the middleboxes know the identity of those middleboxes,
- and have a relationship with them which permits control. In many
- configurations, this will not be possible. For example, many cable
- access providers use NAT in front of their entire access network.
- This NAT could be in addition to a residential NAT purchased and
- operated by the end user. The end user will probably not have a
- control relationship with the NAT in the cable access network, and
- may not even know of its existence.
-
- Many existing proprietary protocols, such as those for online games
- (such as the games described in RFC 3027 [11]) and Voice over IP,
- have developed tricks that allow them to operate through NATs without
- changing those NATs. This document is an attempt to take some of
- those ideas, and codify them into an interoperable protocol that can
- meet the needs of many applications.
-
- The protocol described here, Simple Traversal of UDP Through NAT
- (STUN), allows entities behind a NAT to first discover the presence
- of a NAT and the type of NAT, and then to learn the addresses
- bindings allocated by the NAT. STUN requires no changes to NATs, and
- works with an arbitrary number of NATs in tandem between the
- application entity and the public Internet.
-
-3. Terminology
-
- In this document, the key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
- [1] and indicate requirement levels for compliant STUN
- implementations.
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 4]
-
-RFC 3489 STUN March 2003
-
-
-4. Definitions
-
- STUN Client: A STUN client (also just referred to as a client)
- is an entity that generates STUN requests. A STUN client can
- execute on an end system, such as a user's PC, or can run in a
- network element, such as a conferencing server.
-
- STUN Server: A STUN Server (also just referred to as a server)
- is an entity that receives STUN requests, and sends STUN
- responses. STUN servers are generally attached to the public
- Internet.
-
-5. NAT Variations
-
- It is assumed that the reader is familiar with NATs. It has been
- observed that NAT treatment of UDP varies among implementations. The
- four treatments observed in implementations are:
-
- Full Cone: A full cone NAT is one where all requests from the
- same internal IP address and port are mapped to the same external
- IP address and port. Furthermore, any external host can send a
- packet to the internal host, by sending a packet to the mapped
- external address.
-
- Restricted Cone: A restricted cone NAT is one where all requests
- from the same internal IP address and port are mapped to the same
- external IP address and port. Unlike a full cone NAT, an external
- host (with IP address X) can send a packet to the internal host
- only if the internal host had previously sent a packet to IP
- address X.
-
- Port Restricted Cone: A port restricted cone NAT is like a
- restricted cone NAT, but the restriction includes port numbers.
- Specifically, an external host can send a packet, with source IP
- address X and source port P, to the internal host only if the
- internal host had previously sent a packet to IP address X and
- port P.
-
- Symmetric: A symmetric NAT is one where all requests from the
- same internal IP address and port, to a specific destination IP
- address and port, are mapped to the same external IP address and
- port. If the same host sends a packet with the same source
- address and port, but to a different destination, a different
- mapping is used. Furthermore, only the external host that
- receives a packet can send a UDP packet back to the internal host.
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 5]
-
-RFC 3489 STUN March 2003
-
-
- Determining the type of NAT is important in many cases. Depending on
- what the application wants to do, it may need to take the particular
- behavior into account.
-
-6. Overview of Operation
-
- This section is descriptive only. Normative behavior is described in
- Sections 8 and 9.
-
- /-----\
- // STUN \\
- | Server |
- \\ //
- \-----/
-
-
- +--------------+ Public Internet
- ................| NAT 2 |.......................
- +--------------+
-
-
- +--------------+ Private NET 2
- ................| NAT 1 |.......................
- +--------------+
-
- /-----\
- // STUN \\
- | Client |
- \\ // Private NET 1
- \-----/
-
- Figure 1: STUN Configuration
-
- The typical STUN configuration is shown in Figure 1. A STUN client
- is connected to private network 1. This network connects to private
- network 2 through NAT 1. Private network 2 connects to the public
- Internet through NAT 2. The STUN server resides on the public
- Internet.
-
- STUN is a simple client-server protocol. A client sends a request to
- a server, and the server returns a response. There are two types of
- requests - Binding Requests, sent over UDP, and Shared Secret
- Requests, sent over TLS [2] over TCP. Shared Secret Requests ask the
- server to return a temporary username and password. This username
- and password are used in a subsequent Binding Request and Binding
- Response, for the purposes of authentication and message integrity.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 6]
-
-RFC 3489 STUN March 2003
-
-
- Binding requests are used to determine the bindings allocated by
- NATs. The client sends a Binding Request to the server, over UDP.
- The server examines the source IP address and port of the request,
- and copies them into a response that is sent back to the client.
- There are some parameters in the request that allow the client to ask
- that the response be sent elsewhere, or that the server send the
- response from a different address and port. There are attributes for
- providing message integrity and authentication.
-
- The trick is using STUN to discover the presence of NAT, and to learn
- and use the bindings they allocate.
-
- The STUN client is typically embedded in an application which needs
- to obtain a public IP address and port that can be used to receive
- data. For example, it might need to obtain an IP address and port to
- receive Real Time Transport Protocol (RTP) [12] traffic. When the
- application starts, the STUN client within the application sends a
- STUN Shared Secret Request to its server, obtains a username and
- password, and then sends it a Binding Request. STUN servers can be
- discovered through DNS SRV records [3], and it is generally assumed
- that the client is configured with the domain to use to find the STUN
- server. Generally, this will be the domain of the provider of the
- service the application is using (such a provider is incented to
- deploy STUN servers in order to allow its customers to use its
- application through NAT). Of course, a client can determine the
- address or domain name of a STUN server through other means. A STUN
- server can even be embedded within an end system.
-
- The STUN Binding Request is used to discover the presence of a NAT,
- and to discover the public IP address and port mappings generated by
- the NAT. Binding Requests are sent to the STUN server using UDP.
- When a Binding Request arrives at the STUN server, it may have passed
- through one or more NATs between the STUN client and the STUN server.
- As a result, the source address of the request received by the server
- will be the mapped address created by the NAT closest to the server.
- The STUN server copies that source IP address and port into a STUN
- Binding Response, and sends it back to the source IP address and port
- of the STUN request. For all of the NAT types above, this response
- will arrive at the STUN client.
-
- When the STUN client receives the STUN Binding Response, it compares
- the IP address and port in the packet with the local IP address and
- port it bound to when the request was sent. If these do not match,
- the STUN client is behind one or more NATs. In the case of a full-
- cone NAT, the IP address and port in the body of the STUN response
- are public, and can be used by any host on the public Internet to
- send packets to the application that sent the STUN request. An
- application need only listen on the IP address and port from which
-
-
-
-Rosenberg, et al. Standards Track [Page 7]
-
-RFC 3489 STUN March 2003
-
-
- the STUN request was sent. Any packets sent by a host on the public
- Internet to the public address and port learned by STUN will be
- received by the application.
-
- Of course, the host may not be behind a full-cone NAT. Indeed, it
- doesn't yet know what type of NAT it is behind. To determine that,
- the client uses additional STUN Binding Requests. The exact
- procedure is flexible, but would generally work as follows. The
- client would send a second STUN Binding Request, this time to a
- different IP address, but from the same source IP address and port.
- If the IP address and port in the response are different from those
- in the first response, the client knows it is behind a symmetric NAT.
- To determine if it's behind a full-cone NAT, the client can send a
- STUN Binding Request with flags that tell the STUN server to send a
- response from a different IP address and port than the request was
- received on. In other words, if the client sent a Binding Request to
- IP address/port A/B using a source IP address/port of X/Y, the STUN
- server would send the Binding Response to X/Y using source IP
- address/port C/D. If the client receives this response, it knows it
- is behind a full cone NAT.
-
- STUN also allows the client to ask the server to send the Binding
- Response from the same IP address the request was received on, but
- with a different port. This can be used to detect whether the client
- is behind a port restricted cone NAT or just a restricted cone NAT.
-
- It should be noted that the configuration in Figure 1 is not the only
- permissible configuration. The STUN server can be located anywhere,
- including within another client. The only requirement is that the
- STUN server is reachable by the client, and if the client is trying
- to obtain a publicly routable address, that the server reside on the
- public Internet.
-
-7. Message Overview
-
- STUN messages are TLV (type-length-value) encoded using big endian
- (network ordered) binary. All STUN messages start with a STUN
- header, followed by a STUN payload. The payload is a series of STUN
- attributes, the set of which depends on the message type. The STUN
- header contains a STUN message type, transaction ID, and length. The
- message type can be Binding Request, Binding Response, Binding Error
- Response, Shared Secret Request, Shared Secret Response, or Shared
- Secret Error Response. The transaction ID is used to correlate
- requests and responses. The length indicates the total length of the
- STUN payload, not including the header. This allows STUN to run over
- TCP. Shared Secret Requests are always sent over TCP (indeed, using
- TLS over TCP).
-
-
-
-
-Rosenberg, et al. Standards Track [Page 8]
-
-RFC 3489 STUN March 2003
-
-
- Several STUN attributes are defined. The first is a MAPPED-ADDRESS
- attribute, which is an IP address and port. It is always placed in
- the Binding Response, and it indicates the source IP address and port
- the server saw in the Binding Request. There is also a RESPONSE-
- ADDRESS attribute, which contains an IP address and port. The
- RESPONSE-ADDRESS attribute can be present in the Binding Request, and
- indicates where the Binding Response is to be sent. It's optional,
- and when not present, the Binding Response is sent to the source IP
- address and port of the Binding Request.
-
- The third attribute is the CHANGE-REQUEST attribute, and it contains
- two flags to control the IP address and port used to send the
- response. These flags are called "change IP" and "change port"
- flags. The CHANGE-REQUEST attribute is allowed only in the Binding
- Request. The "change IP" and "change port" flags are useful for
- determining whether the client is behind a restricted cone NAT or
- restricted port cone NAT. They instruct the server to send the
- Binding Responses from a different source IP address and port. The
- CHANGE-REQUEST attribute is optional in the Binding Request.
-
- The fourth attribute is the CHANGED-ADDRESS attribute. It is present
- in Binding Responses. It informs the client of the source IP address
- and port that would be used if the client requested the "change IP"
- and "change port" behavior.
-
- The fifth attribute is the SOURCE-ADDRESS attribute. It is only
- present in Binding Responses. It indicates the source IP address and
- port where the response was sent from. It is useful for detecting
- twice NAT configurations.
-
- The sixth attribute is the USERNAME attribute. It is present in a
- Shared Secret Response, which provides the client with a temporary
- username and password (encoded in the PASSWORD attribute). The
- USERNAME is also present in Binding Requests, serving as an index to
- the shared secret used for the integrity protection of the Binding
- Request. The seventh attribute, PASSWORD, is only found in Shared
- Secret Response messages. The eight attribute is the MESSAGE-
- INTEGRITY attribute, which contains a message integrity check over
- the Binding Request or Binding Response.
-
- The ninth attribute is the ERROR-CODE attribute. This is present in
- the Binding Error Response and Shared Secret Error Response. It
- indicates the error that has occurred. The tenth attribute is the
- UNKNOWN-ATTRIBUTES attribute, which is present in either the Binding
- Error Response or Shared Secret Error Response. It indicates the
- mandatory attributes from the request which were unknown. The
- eleventh attribute is the REFLECTED-FROM attribute, which is present
- in Binding Responses. It indicates the IP address and port of the
-
-
-
-Rosenberg, et al. Standards Track [Page 9]
-
-RFC 3489 STUN March 2003
-
-
- sender of a Binding Request, used for traceability purposes to
- prevent certain denial-of-service attacks.
-
-8. Server Behavior
-
- The server behavior depends on whether the request is a Binding
- Request or a Shared Secret Request.
-
-8.1 Binding Requests
-
- A STUN server MUST be prepared to receive Binding Requests on four
- address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2,
- P2). (A1, P1) represent the primary address and port, and these are
- the ones obtained through the client discovery procedures below.
- Typically, P1 will be port 3478, the default STUN port. A2 and P2
- are arbitrary. A2 and P2 are advertised by the server through the
- CHANGED-ADDRESS attribute, as described below.
-
- It is RECOMMENDED that the server check the Binding Request for a
- MESSAGE-INTEGRITY attribute. If not present, and the server requires
- integrity checks on the request, it generates a Binding Error
- Response with an ERROR-CODE attribute with response code 401. If the
- MESSAGE-INTEGRITY attribute was present, the server computes the HMAC
- over the request as described in Section 11.2.8. The key to use
- depends on the shared secret mechanism. If the STUN Shared Secret
- Request was used, the key MUST be the one associated with the
- USERNAME attribute present in the request. If the USERNAME attribute
- was not present, the server MUST generate a Binding Error Response.
- The Binding Error Response MUST include an ERROR-CODE attribute with
- response code 432. If the USERNAME is present, but the server
- doesn't remember the shared secret for that USERNAME (because it
- timed out, for example), the server MUST generate a Binding Error
- Response. The Binding Error Response MUST include an ERROR-CODE
- attribute with response code 430. If the server does know the shared
- secret, but the computed HMAC differs from the one in the request,
- the server MUST generate a Binding Error Response with an ERROR-CODE
- attribute with response code 431. The Binding Error Response is sent
- to the IP address and port the Binding Request came from, and sent
- from the IP address and port the Binding Request was sent to.
-
- Assuming the message integrity check passed, processing continues.
- The server MUST check for any attributes in the request with values
- less than or equal to 0x7fff which it does not understand. If it
- encounters any, the server MUST generate a Binding Error Response,
- and it MUST include an ERROR-CODE attribute with a 420 response code.
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 10]
-
-RFC 3489 STUN March 2003
-
-
- That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing
- the attributes with values less than or equal to 0x7fff which were
- not understood. The Binding Error Response is sent to the IP address
- and port the Binding Request came from, and sent from the IP address
- and port the Binding Request was sent to.
-
- Assuming the request was correctly formed, the server MUST generate a
- single Binding Response. The Binding Response MUST contain the same
- transaction ID contained in the Binding Request. The length in the
- message header MUST contain the total length of the message in bytes,
- excluding the header. The Binding Response MUST have a message type
- of "Binding Response".
-
- The server MUST add a MAPPED-ADDRESS attribute to the Binding
- Response. The IP address component of this attribute MUST be set to
- the source IP address observed in the Binding Request. The port
- component of this attribute MUST be set to the source port observed
- in the Binding Request.
-
- If the RESPONSE-ADDRESS attribute was absent from the Binding
- Request, the destination address and port of the Binding Response
- MUST be the same as the source address and port of the Binding
- Request. Otherwise, the destination address and port of the Binding
- Response MUST be the value of the IP address and port in the
- RESPONSE-ADDRESS attribute.
-
- The source address and port of the Binding Response depend on the
- value of the CHANGE-REQUEST attribute and on the address and port the
- Binding Request was received on, and are summarized in Table 1.
-
- Let Da represent the destination IP address of the Binding Request
- (which will be either A1 or A2), and Dp represent the destination
- port of the Binding Request (which will be either P1 or P2). Let Ca
- represent the other address, so that if Da is A1, Ca is A2. If Da is
- A2, Ca is A1. Similarly, let Cp represent the other port, so that if
- Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port"
- flag was set in CHANGE-REQUEST attribute of the Binding Request, and
- the "change IP" flag was not set, the source IP address of the
- Binding Response MUST be Da and the source port of the Binding
- Response MUST be Cp. If the "change IP" flag was set in the Binding
- Request, and the "change port" flag was not set, the source IP
- address of the Binding Response MUST be Ca and the source port of the
- Binding Response MUST be Dp. When both flags are set, the source IP
- address of the Binding Response MUST be Ca and the source port of the
- Binding Response MUST be Cp. If neither flag is set, or if the
- CHANGE-REQUEST attribute is absent entirely, the source IP address of
- the Binding Response MUST be Da and the source port of the Binding
- Response MUST be Dp.
-
-
-
-Rosenberg, et al. Standards Track [Page 11]
-
-RFC 3489 STUN March 2003
-
-
- Flags Source Address Source Port CHANGED-ADDRESS
- none Da Dp Ca:Cp
- Change IP Ca Dp Ca:Cp
- Change port Da Cp Ca:Cp
- Change IP and
- Change port Ca Cp Ca:Cp
-
- Table 1: Impact of Flags on Packet Source and CHANGED-ADDRESS
-
- The server MUST add a SOURCE-ADDRESS attribute to the Binding
- Response, containing the source address and port used to send the
- Binding Response.
-
- The server MUST add a CHANGED-ADDRESS attribute to the Binding
- Response. This contains the source IP address and port that would be
- used if the client had set the "change IP" and "change port" flags in
- the Binding Request. As summarized in Table 1, these are Ca and Cp,
- respectively, regardless of the value of the CHANGE-REQUEST flags.
-
- If the Binding Request contained both the USERNAME and MESSAGE-
- INTEGRITY attributes, the server MUST add a MESSAGE-INTEGRITY
- attribute to the Binding Response. The attribute contains an HMAC
- [13] over the response, as described in Section 11.2.8. The key to
- use depends on the shared secret mechanism. If the STUN Shared
- Secret Request was used, the key MUST be the one associated with the
- USERNAME attribute present in the Binding Request.
-
- If the Binding Request contained a RESPONSE-ADDRESS attribute, the
- server MUST add a REFLECTED-FROM attribute to the response. If the
- Binding Request was authenticated using a username obtained from a
- Shared Secret Request, the REFLECTED-FROM attribute MUST contain the
- source IP address and port where that Shared Secret Request came
- from. If the username present in the request was not allocated using
- a Shared Secret Request, the REFLECTED-FROM attribute MUST contain
- the source address and port of the entity which obtained the
- username, as best can be verified with the mechanism used to allocate
- the username. If the username was not present in the request, and
- the server was willing to process the request, the REFLECTED-FROM
- attribute SHOULD contain the source IP address and port where the
- request came from.
-
- The server SHOULD NOT retransmit the response. Reliability is
- achieved by having the client periodically resend the request, each
- of which triggers a response from the server.
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 12]
-
-RFC 3489 STUN March 2003
-
-
-8.2 Shared Secret Requests
-
- Shared Secret Requests are always received on TLS connections. When
- the server receives a request from the client to establish a TLS
- connection, it MUST proceed with TLS, and SHOULD present a site
- certificate. The TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA [4]
- SHOULD be used. Client TLS authentication MUST NOT be done, since
- the server is not allocating any resources to clients, and the
- computational burden can be a source of attacks.
-
- If the server receives a Shared Secret Request, it MUST verify that
- the request arrived on a TLS connection. If it did not receive the
- request over TLS, it MUST generate a Shared Secret Error Response,
- and it MUST include an ERROR-CODE attribute with a 433 response code.
- The destination for the error response depends on the transport on
- which the request was received. If the Shared Secret Request was
- received over TCP, the Shared Secret Error Response is sent over the
- same connection the request was received on. If the Shared Secret
- Request was receive over UDP, the Shared Secret Error Response is
- sent to the source IP address and port that the request came from.
-
- The server MUST check for any attributes in the request with values
- less than or equal to 0x7fff which it does not understand. If it
- encounters any, the server MUST generate a Shared Secret Error
- Response, and it MUST include an ERROR-CODE attribute with a 420
- response code. That response MUST contain an UNKNOWN-ATTRIBUTES
- attribute listing the attributes with values less than or equal to
- 0x7fff which were not understood. The Shared Secret Error Response
- is sent over the TLS connection.
-
- All Shared Secret Error Responses MUST contain the same transaction
- ID contained in the Shared Secret Request. The length in the message
- header MUST contain the total length of the message in bytes,
- excluding the header. The Shared Secret Error Response MUST have a
- message type of "Shared Secret Error Response" (0x0112).
-
- Assuming the request was properly constructed, the server creates a
- Shared Secret Response. The Shared Secret Response MUST contain the
- same transaction ID contained in the Shared Secret Request. The
- length in the message header MUST contain the total length of the
- message in bytes, excluding the header. The Shared Secret Response
- MUST have a message type of "Shared Secret Response". The Shared
- Secret Response MUST contain a USERNAME attribute and a PASSWORD
- attribute. The USERNAME attribute serves as an index to the
- password, which is contained in the PASSWORD attribute. The server
- can use any mechanism it chooses to generate the username. However,
- the username MUST be valid for a period of at least 10 minutes.
- Validity means that the server can compute the password for that
-
-
-
-Rosenberg, et al. Standards Track [Page 13]
-
-RFC 3489 STUN March 2003
-
-
- username. There MUST be a single password for each username. In
- other words, the server cannot, 10 minutes later, assign a different
- password to the same username. The server MUST hand out a different
- username for each distinct Shared Secret Request. Distinct, in this
- case, implies a different transaction ID. It is RECOMMENDED that the
- server explicitly invalidate the username after ten minutes. It MUST
- invalidate the username after 30 minutes. The PASSWORD contains the
- password bound to that username. The password MUST have at least 128
- bits. The likelihood that the server assigns the same password for
- two different usernames MUST be vanishingly small, and the passwords
- MUST be unguessable. In other words, they MUST be a
- cryptographically random function of the username.
-
- These requirements can still be met using a stateless server, by
- intelligently computing the USERNAME and PASSWORD. One approach is
- to construct the USERNAME as:
-
- USERNAME = <prefix,rounded-time,clientIP,hmac>
-
- Where prefix is some random text string (different for each shared
- secret request), rounded-time is the current time modulo 20 minutes,
- clientIP is the source IP address where the Shared Secret Request
- came from, and hmac is an HMAC [13] over the prefix, rounded-time,
- and client IP, using a server private key.
-
- The password is then computed as:
-
- password = <hmac(USERNAME,anotherprivatekey)>
-
- With this structure, the username itself, which will be present in
- the Binding Request, contains the source IP address where the Shared
- Secret Request came from. That allows the server to meet the
- requirements specified in Section 8.1 for constructing the
- REFLECTED-FROM attribute. The server can verify that the username
- was not tampered with, using the hmac present in the username.
-
- The Shared Secret Response is sent over the same TLS connection the
- request was received on. The server SHOULD keep the connection open,
- and let the client close it.
-
-9. Client Behavior
-
- The behavior of the client is very straightforward. Its task is to
- discover the STUN server, obtain a shared secret, formulate the
- Binding Request, handle request reliability, and process the Binding
- Responses.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 14]
-
-RFC 3489 STUN March 2003
-
-
-9.1 Discovery
-
- Generally, the client will be configured with a domain name of the
- provider of the STUN servers. This domain name is resolved to an IP
- address and port using the SRV procedures specified in RFC 2782 [3].
-
- Specifically, the service name is "stun". The protocol is "udp" for
- sending Binding Requests, or "tcp" for sending Shared Secret
- Requests. The procedures of RFC 2782 are followed to determine the
- server to contact. RFC 2782 spells out the details of how a set of
- SRV records are sorted and then tried. However, it only states that
- the client should "try to connect to the (protocol, address,
- service)" without giving any details on what happens in the event of
- failure. Those details are described here for STUN.
-
- For STUN requests, failure occurs if there is a transport failure of
- some sort (generally, due to fatal ICMP errors in UDP or connection
- failures in TCP). Failure also occurs if the transaction fails due
- to timeout. This occurs 9.5 seconds after the first request is sent,
- for both Shared Secret Requests and Binding Requests. See Section
- 9.3 for details on transaction timeouts for Binding Requests. If a
- failure occurs, the client SHOULD create a new request, which is
- identical to the previous, but has a different transaction ID and
- MESSAGE INTEGRITY attribute (the HMAC will change because the
- transaction ID has changed). That request is sent to the next
- element in the list as specified by RFC 2782.
-
- The default port for STUN requests is 3478, for both TCP and UDP.
- Administrators SHOULD use this port in their SRV records, but MAY use
- others.
-
- If no SRV records were found, the client performs an A record lookup
- of the domain name. The result will be a list of IP addresses, each
- of which can be contacted at the default port.
-
- This would allow a firewall admin to open the STUN port, so hosts
- within the enterprise could access new applications. Whether they
- will or won't do this is a good question.
-
-9.2 Obtaining a Shared Secret
-
- As discussed in Section 12, there are several attacks possible on
- STUN systems. Many of these are prevented through integrity of
- requests and responses. To provide that integrity, STUN makes use of
- a shared secret between client and server, used as the keying
- material for an HMAC used in both the Binding Request and Binding
- Response. STUN allows for the shared secret to be obtained in any
- way (for example, Kerberos [14]). However, it MUST have at least 128
-
-
-
-Rosenberg, et al. Standards Track [Page 15]
-
-RFC 3489 STUN March 2003
-
-
- bits of randomness. In order to ensure interoperability, this
- specification describes a TLS-based mechanism. This mechanism,
- described in this section, MUST be implemented by clients and
- servers.
-
- First, the client determines the IP address and port that it will
- open a TCP connection to. This is done using the discovery
- procedures in Section 9.1. The client opens up the connection to
- that address and port, and immediately begins TLS negotiation [2].
- The client MUST verify the identity of the server. To do that, it
- follows the identification procedures defined in Section 3.1 of RFC
- 2818 [5]. Those procedures assume the client is dereferencing a URI.
- For purposes of usage with this specification, the client treats the
- domain name or IP address used in Section 9.1 as the host portion of
- the URI that has been dereferenced.
-
- Once the connection is opened, the client sends a Shared Secret
- request. This request has no attributes, just the header. The
- transaction ID in the header MUST meet the requirements outlined for
- the transaction ID in a binding request, described in Section 9.3
- below. The server generates a response, which can either be a Shared
- Secret Response or a Shared Secret Error Response.
-
- If the response was a Shared Secret Error Response, the client checks
- the response code in the ERROR-CODE attribute. Interpretation of
- those response codes is identical to the processing of Section 9.4
- for the Binding Error Response.
-
- If a client receives a Shared Secret Response with an attribute whose
- type is greater than 0x7fff, the attribute MUST be ignored. If the
- client receives a Shared Secret Response with an attribute whose type
- is less than or equal to 0x7fff, the response is ignored.
-
- If the response was a Shared Secret Response, it will contain a short
- lived username and password, encoded in the USERNAME and PASSWORD
- attributes, respectively.
-
- The client MAY generate multiple Shared Secret Requests on the
- connection, and it MAY do so before receiving Shared Secret Responses
- to previous Shared Secret Requests. The client SHOULD close the
- connection as soon as it has finished obtaining usernames and
- passwords.
-
- Section 9.3 describes how these passwords are used to provide
- integrity protection over Binding Requests, and Section 8.1 describes
- how it is used in Binding Responses.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 16]
-
-RFC 3489 STUN March 2003
-
-
-9.3 Formulating the Binding Request
-
- A Binding Request formulated by the client follows the syntax rules
- defined in Section 11. Any two requests that are not bit-wise
- identical, and not sent to the same server from the same IP address
- and port, MUST carry different transaction IDs. The transaction ID
- MUST be uniformly and randomly distributed between 0 and 2**128 - 1.
- The large range is needed because the transaction ID serves as a form
- of randomization, helping to prevent replays of previously signed
- responses from the server. The message type of the request MUST be
- "Binding Request".
-
- The RESPONSE-ADDRESS attribute is optional in the Binding Request.
- It is used if the client wishes the response to be sent to a
- different IP address and port than the one the request was sent from.
- This is useful for determining whether the client is behind a
- firewall, and for applications that have separated control and data
- components. See Section 10.3 for more details. The CHANGE-REQUEST
- attribute is also optional. Whether it is present depends on what
- the application is trying to accomplish. See Section 10 for some
- example uses.
-
- The client SHOULD add a MESSAGE-INTEGRITY and USERNAME attribute to
- the Binding Request. This MESSAGE-INTEGRITY attribute contains an
- HMAC [13]. The value of the username, and the key to use in the
- MESSAGE-INTEGRITY attribute depend on the shared secret mechanism.
- If the STUN Shared Secret Request was used, the USERNAME must be a
- valid username obtained from a Shared Secret Response within the last
- nine minutes. The shared secret for the HMAC is the value of the
- PASSWORD attribute obtained from the same Shared Secret Response.
-
- Once formulated, the client sends the Binding Request. Reliability
- is accomplished through client retransmissions. Clients SHOULD
- retransmit the request starting with an interval of 100ms, doubling
- every retransmit until the interval reaches 1.6s. Retransmissions
- continue with intervals of 1.6s until a response is received, or a
- total of 9 requests have been sent. If no response is received by 1.6
- seconds after the last request has been sent, the client SHOULD
- consider the transaction to have failed. In other words, requests
- would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms,
- 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the
- transaction to have failed if no response has been received.
-
-9.4 Processing Binding Responses
-
- The response can either be a Binding Response or Binding Error
- Response. Binding Error Responses are always received on the source
- address and port the request was sent from. A Binding Response will
-
-
-
-Rosenberg, et al. Standards Track [Page 17]
-
-RFC 3489 STUN March 2003
-
-
- be received on the address and port placed in the RESPONSE-ADDRESS
- attribute of the request. If none was present, the Binding Responses
- will be received on the source address and port the request was sent
- from.
-
- If the response is a Binding Error Response, the client checks the
- response code from the ERROR-CODE attribute of the response. For a
- 400 response code, the client SHOULD display the reason phrase to the
- user. For a 420 response code, the client SHOULD retry the request,
- this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES
- attribute of the response. For a 430 response code, the client
- SHOULD obtain a new shared secret, and retry the Binding Request with
- a new transaction. For 401 and 432 response codes, if the client had
- omitted the USERNAME or MESSAGE-INTEGRITY attribute as indicated by
- the error, it SHOULD try again with those attributes. For a 431
- response code, the client SHOULD alert the user, and MAY try the
- request again after obtaining a new username and password. For a 500
- response code, the client MAY wait several seconds and then retry the
- request. For a 600 response code, the client MUST NOT retry the
- request, and SHOULD display the reason phrase to the user. Unknown
- attributes between 400 and 499 are treated like a 400, unknown
- attributes between 500 and 599 are treated like a 500, and unknown
- attributes between 600 and 699 are treated like a 600. Any response
- between 100 and 399 MUST result in the cessation of request
- retransmissions, but otherwise is discarded.
-
- If a client receives a response with an attribute whose type is
- greater than 0x7fff, the attribute MUST be ignored. If the client
- receives a response with an attribute whose type is less than or
- equal to 0x7fff, request retransmissions MUST cease, but the entire
- response is otherwise ignored.
-
- If the response is a Binding Response, the client SHOULD check the
- response for a MESSAGE-INTEGRITY attribute. If not present, and the
- client placed a MESSAGE-INTEGRITY attribute into the request, it MUST
- discard the response. If present, the client computes the HMAC over
- the response as described in Section 11.2.8. The key to use depends
- on the shared secret mechanism. If the STUN Shared Secret Request
- was used, the key MUST be same as used to compute the MESSAGE-
- INTEGRITY attribute in the request. If the computed HMAC differs
- from the one in the response, the client MUST discard the response,
- and SHOULD alert the user about a possible attack. If the computed
- HMAC matches the one from the response, processing continues.
-
- Reception of a response (either Binding Error Response or Binding
- Response) to a Binding Request will terminate retransmissions of that
- request. However, clients MUST continue to listen for responses to a
- Binding Request for 10 seconds after the first response. If it
-
-
-
-Rosenberg, et al. Standards Track [Page 18]
-
-RFC 3489 STUN March 2003
-
-
- receives any responses in this interval with different message types
- (Binding Responses and Binding Error Responses, for example) or
- different MAPPED-ADDRESSes, it is an indication of a possible attack.
- The client MUST NOT use the MAPPED-ADDRESS from any of the responses
- it received (either the first or the additional ones), and SHOULD
- alert the user.
-
- Furthermore, if a client receives more than twice as many Binding
- Responses as the number of Binding Requests it sent, it MUST NOT use
- the MAPPED-ADDRESS from any of those responses, and SHOULD alert the
- user about a potential attack.
-
- If the Binding Response is authenticated, and the MAPPED-ADDRESS was
- not discarded because of a potential attack, the CLIENT MAY use the
- MAPPED-ADDRESS and SOURCE-ADDRESS attributes.
-
-10. Use Cases
-
- The rules of Sections 8 and 9 describe exactly how a client and
- server interact to send requests and get responses. However, they do
- not dictate how the STUN protocol is used to accomplish useful tasks.
- That is at the discretion of the client. Here, we provide some
- useful scenarios for applying STUN.
-
-10.1 Discovery Process
-
- In this scenario, a user is running a multimedia application which
- needs to determine which of the following scenarios applies to it:
-
- o On the open Internet
-
- o Firewall that blocks UDP
-
- o Firewall that allows UDP out, and responses have to come back to
- the source of the request (like a symmetric NAT, but no
- translation. We call this a symmetric UDP Firewall)
-
- o Full-cone NAT
-
- o Symmetric NAT
-
- o Restricted cone or restricted port cone NAT
-
- Which of the six scenarios applies can be determined through the flow
- chart described in Figure 2. The chart refers only to the sequence
- of Binding Requests; Shared Secret Requests will, of course, be
- needed to authenticate each Binding Request used in the sequence.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 19]
-
-RFC 3489 STUN March 2003
-
-
- The flow makes use of three tests. In test I, the client sends a
- STUN Binding Request to a server, without any flags set in the
- CHANGE-REQUEST attribute, and without the RESPONSE-ADDRESS attribute.
- This causes the server to send the response back to the address and
- port that the request came from. In test II, the client sends a
- Binding Request with both the "change IP" and "change port" flags
- from the CHANGE-REQUEST attribute set. In test III, the client sends
- a Binding Request with only the "change port" flag set.
-
- The client begins by initiating test I. If this test yields no
- response, the client knows right away that it is not capable of UDP
- connectivity. If the test produces a response, the client examines
- the MAPPED-ADDRESS attribute. If this address and port are the same
- as the local IP address and port of the socket used to send the
- request, the client knows that it is not natted. It executes test
- II.
-
- If a response is received, the client knows that it has open access
- to the Internet (or, at least, its behind a firewall that behaves
- like a full-cone NAT, but without the translation). If no response
- is received, the client knows its behind a symmetric UDP firewall.
-
- In the event that the IP address and port of the socket did not match
- the MAPPED-ADDRESS attribute in the response to test I, the client
- knows that it is behind a NAT. It performs test II. If a response
- is received, the client knows that it is behind a full-cone NAT. If
- no response is received, it performs test I again, but this time,
- does so to the address and port from the CHANGED-ADDRESS attribute
- from the response to test I. If the IP address and port returned in
- the MAPPED-ADDRESS attribute are not the same as the ones from the
- first test I, the client knows its behind a symmetric NAT. If the
- address and port are the same, the client is either behind a
- restricted or port restricted NAT. To make a determination about
- which one it is behind, the client initiates test III. If a response
- is received, its behind a restricted NAT, and if no response is
- received, its behind a port restricted NAT.
-
- This procedure yields substantial information about the operating
- condition of the client application. In the event of multiple NATs
- between the client and the Internet, the type that is discovered will
- be the type of the most restrictive NAT between the client and the
- Internet. The types of NAT, in order of restrictiveness, from most
- to least, are symmetric, port restricted cone, restricted cone, and
- full cone.
-
- Typically, a client will re-do this discovery process periodically to
- detect changes, or look for inconsistent results. It is important to
- note that when the discovery process is redone, it should not
-
-
-
-Rosenberg, et al. Standards Track [Page 20]
-
-RFC 3489 STUN March 2003
-
-
- generally be done from the same local address and port used in the
- previous discovery process. If the same local address and port are
- reused, bindings from the previous test may still be in existence,
- and these will invalidate the results of the test. Using a different
- local address and port for subsequent tests resolves this problem.
- An alternative is to wait sufficiently long to be confident that the
- old bindings have expired (half an hour should more than suffice).
-
-10.2 Binding Lifetime Discovery
-
- STUN can also be used to discover the lifetimes of the bindings
- created by the NAT. In many cases, the client will need to refresh
- the binding, either through a new STUN request, or an application
- packet, in order for the application to continue to use the binding.
- By discovering the binding lifetime, the client can determine how
- frequently it needs to refresh.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 21]
-
-RFC 3489 STUN March 2003
-
-
- +--------+
- | Test |
- | I |
- +--------+
- |
- |
- V
- /\ /\
- N / \ Y / \ Y +--------+
- UDP <-------/Resp\--------->/ IP \------------->| Test |
- Blocked \ ? / \Same/ | II |
- \ / \? / +--------+
- \/ \/ |
- | N |
- | V
- V /\
- +--------+ Sym. N / \
- | Test | UDP <---/Resp\
- | II | Firewall \ ? /
- +--------+ \ /
- | \/
- V |Y
- /\ /\ |
- Symmetric N / \ +--------+ N / \ V
- NAT <--- / IP \<-----| Test |<--- /Resp\ Open
- \Same/ | I | \ ? / Internet
- \? / +--------+ \ /
- \/ \/
- | |Y
- | |
- | V
- | Full
- | Cone
- V /\
- +--------+ / \ Y
- | Test |------>/Resp\---->Restricted
- | III | \ ? /
- +--------+ \ /
- \/
- |N
- | Port
- +------>Restricted
-
- Figure 2: Flow for type discovery process
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 22]
-
-RFC 3489 STUN March 2003
-
-
- To determine the binding lifetime, the client first sends a Binding
- Request to the server from a particular socket, X. This creates a
- binding in the NAT. The response from the server contains a MAPPED-
- ADDRESS attribute, providing the public address and port on the NAT.
- Call this Pa and Pp, respectively. The client then starts a timer
- with a value of T seconds. When this timer fires, the client sends
- another Binding Request to the server, using the same destination
- address and port, but from a different socket, Y. This request
- contains a RESPONSE-ADDRESS address attribute, set to (Pa,Pp). This
- will create a new binding on the NAT, and cause the STUN server to
- send a Binding Response that would match the old binding, if it still
- exists. If the client receives the Binding Response on socket X, it
- knows that the binding has not expired. If the client receives the
- Binding Response on socket Y (which is possible if the old binding
- expired, and the NAT allocated the same public address and port to
- the new binding), or receives no response at all, it knows that the
- binding has expired.
-
- The client can find the value of the binding lifetime by doing a
- binary search through T, arriving eventually at the value where the
- response is not received for any timer greater than T, but is
- received for any timer less than T.
-
- This discovery process takes quite a bit of time, and is something
- that will typically be run in the background on a device once it
- boots.
-
- It is possible that the client can get inconsistent results each time
- this process is run. For example, if the NAT should reboot, or be
- reset for some reason, the process may discover a lifetime than is
- shorter than the actual one. For this reason, implementations are
- encouraged to run the test numerous times, and be prepared to get
- inconsistent results.
-
-10.3 Binding Acquisition
-
- Consider once more the case of a VoIP phone. It used the discovery
- process above when it started up, to discover its environment. Now,
- it wants to make a call. As part of the discovery process, it
- determined that it was behind a full-cone NAT.
-
- Consider further that this phone consists of two logically separated
- components - a control component that handles signaling, and a media
- component that handles the audio, video, and RTP [12]. Both are
- behind the same NAT. Because of this separation of control and
- media, we wish to minimize the communication required between them.
- In fact, they may not even run on the same host.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 23]
-
-RFC 3489 STUN March 2003
-
-
- In order to make a voice call, the phone needs to obtain an IP
- address and port that it can place in the call setup message as the
- destination for receiving audio.
-
- To obtain an address, the control component sends a Shared Secret
- Request to the server, obtains a shared secret, and then sends a
- Binding Request to the server. No CHANGE-REQUEST attribute is
- present in the Binding Request, and neither is the RESPONSE-ADDRESS
- attribute. The Binding Response contains a mapped address. The
- control component then formulates a second Binding Request. This
- request contains a RESPONSE-ADDRESS, which is set to the mapped
- address learned from the previous Binding Response. This Binding
- Request is passed to the media component, along with the IP address
- and port of the STUN server. The media component sends the Binding
- Request. The request goes to the STUN server, which sends the
- Binding Response back to the control component. The control
- component receives this, and now has learned an IP address and port
- that will be routed back to the media component that sent the
- request.
-
- The client will be able to receive media from anywhere on this mapped
- address.
-
- In the case of silence suppression, there may be periods where the
- client receives no media. In this case, the UDP bindings could
- timeout (UDP bindings in NATs are typically short; 30 seconds is
- common). To deal with this, the application can periodically
- retransmit the query in order to keep the binding fresh.
-
- It is possible that both participants in the multimedia session are
- behind the same NAT. In that case, both will repeat this procedure
- above, and both will obtain public address bindings. When one sends
- media to the other, the media is routed to the NAT, and then turns
- right back around to come back into the enterprise, where it is
- translated to the private address of the recipient. This is not
- particularly efficient, and unfortunately, does not work in many
- commercial NATs. In such cases, the clients may need to retry using
- private addresses.
-
-11. Protocol Details
-
- This section presents the detailed encoding of a STUN message.
-
- STUN is a request-response protocol. Clients send a request, and the
- server sends a response. There are two requests, Binding Request,
- and Shared Secret Request. The response to a Binding Request can
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 24]
-
-RFC 3489 STUN March 2003
-
-
- either be the Binding Response or Binding Error Response. The
- response to a Shared Secret Request can either be a Shared Secret
- Response or a Shared Secret Error Response.
-
- STUN messages are encoded using binary fields. All integer fields
- are carried in network byte order, that is, most significant byte
- (octet) first. This byte order is commonly known as big-endian. The
- transmission order is described in detail in Appendix B of RFC 791
- [6]. Unless otherwise noted, numeric constants are in decimal (base
- 10).
-
-11.1 Message Header
-
- All STUN messages consist of a 20 byte header:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | STUN Message Type | Message Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Transaction ID
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The Message Types can take on the following values:
-
- 0x0001 : Binding Request
- 0x0101 : Binding Response
- 0x0111 : Binding Error Response
- 0x0002 : Shared Secret Request
- 0x0102 : Shared Secret Response
- 0x0112 : Shared Secret Error Response
-
- The message length is the count, in bytes, of the size of the
- message, not including the 20 byte header.
-
- The transaction ID is a 128 bit identifier. It also serves as salt
- to randomize the request and the response. All responses carry the
- same identifier as the request they correspond to.
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 25]
-
-RFC 3489 STUN March 2003
-
-
-11.2 Message Attributes
-
- After the header are 0 or more attributes. Each attribute is TLV
- encoded, with a 16 bit type, 16 bit length, and variable value:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Value ....
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The following types are defined:
-
- 0x0001: MAPPED-ADDRESS
- 0x0002: RESPONSE-ADDRESS
- 0x0003: CHANGE-REQUEST
- 0x0004: SOURCE-ADDRESS
- 0x0005: CHANGED-ADDRESS
- 0x0006: USERNAME
- 0x0007: PASSWORD
- 0x0008: MESSAGE-INTEGRITY
- 0x0009: ERROR-CODE
- 0x000a: UNKNOWN-ATTRIBUTES
- 0x000b: REFLECTED-FROM
-
- To allow future revisions of this specification to add new attributes
- if needed, the attribute space is divided into optional and mandatory
- ones. Attributes with values greater than 0x7fff are optional, which
- means that the message can be processed by the client or server even
- though the attribute is not understood. Attributes with values less
- than or equal to 0x7fff are mandatory to understand, which means that
- the client or server cannot process the message unless it understands
- the attribute.
-
- The MESSAGE-INTEGRITY attribute MUST be the last attribute within a
- message. Any attributes that are known, but are not supposed to be
- present in a message (MAPPED-ADDRESS in a request, for example) MUST
- be ignored.
-
- Table 2 indicates which attributes are present in which messages. An
- M indicates that inclusion of the attribute in the message is
- mandatory, O means its optional, C means it's conditional based on
- some other aspect of the message, and N/A means that the attribute is
- not applicable to that message type.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 26]
-
-RFC 3489 STUN March 2003
-
-
- Binding Shared Shared Shared
- Binding Binding Error Secret Secret Secret
- Att. Req. Resp. Resp. Req. Resp. Error
- Resp.
- _____________________________________________________________________
- MAPPED-ADDRESS N/A M N/A N/A N/A N/A
- RESPONSE-ADDRESS O N/A N/A N/A N/A N/A
- CHANGE-REQUEST O N/A N/A N/A N/A N/A
- SOURCE-ADDRESS N/A M N/A N/A N/A N/A
- CHANGED-ADDRESS N/A M N/A N/A N/A N/A
- USERNAME O N/A N/A N/A M N/A
- PASSWORD N/A N/A N/A N/A M N/A
- MESSAGE-INTEGRITY O O N/A N/A N/A N/A
- ERROR-CODE N/A N/A M N/A N/A M
- UNKNOWN-ATTRIBUTES N/A N/A C N/A N/A C
- REFLECTED-FROM N/A C N/A N/A N/A N/A
-
- Table 2: Summary of Attributes
-
- The length refers to the length of the value element, expressed as an
- unsigned integral number of bytes.
-
-11.2.1 MAPPED-ADDRESS
-
- The MAPPED-ADDRESS attribute indicates the mapped IP address and
- port. It consists of an eight bit address family, and a sixteen bit
- port, followed by a fixed length value representing the IP address.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |x x x x x x x x| Family | Port |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The port is a network byte ordered representation of the mapped port.
- The address family is always 0x01, corresponding to IPv4. The first
- 8 bits of the MAPPED-ADDRESS are ignored, for the purposes of
- aligning parameters on natural boundaries. The IPv4 address is 32
- bits.
-
-11.2.2 RESPONSE-ADDRESS
-
- The RESPONSE-ADDRESS attribute indicates where the response to a
- Binding Request should be sent. Its syntax is identical to MAPPED-
- ADDRESS.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 27]
-
-RFC 3489 STUN March 2003
-
-
-11.2.3 CHANGED-ADDRESS
-
- The CHANGED-ADDRESS attribute indicates the IP address and port where
- responses would have been sent from if the "change IP" and "change
- port" flags had been set in the CHANGE-REQUEST attribute of the
- Binding Request. The attribute is always present in a Binding
- Response, independent of the value of the flags. Its syntax is
- identical to MAPPED-ADDRESS.
-
-11.2.4 CHANGE-REQUEST
-
- The CHANGE-REQUEST attribute is used by the client to request that
- the server use a different address and/or port when sending the
- response. The attribute is 32 bits long, although only two bits (A
- and B) are used:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The meaning of the flags is:
-
- A: This is the "change IP" flag. If true, it requests the server
- to send the Binding Response with a different IP address than the
- one the Binding Request was received on.
-
- B: This is the "change port" flag. If true, it requests the
- server to send the Binding Response with a different port than the
- one the Binding Request was received on.
-
-11.2.5 SOURCE-ADDRESS
-
- The SOURCE-ADDRESS attribute is present in Binding Responses. It
- indicates the source IP address and port that the server is sending
- the response from. Its syntax is identical to that of MAPPED-
- ADDRESS.
-
-11.2.6 USERNAME
-
- The USERNAME attribute is used for message integrity. It serves as a
- means to identify the shared secret used in the message integrity
- check. The USERNAME is always present in a Shared Secret Response,
- along with the PASSWORD. It is optionally present in a Binding
- Request when message integrity is used.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 28]
-
-RFC 3489 STUN March 2003
-
-
- The value of USERNAME is a variable length opaque value. Its length
- MUST be a multiple of 4 (measured in bytes) in order to guarantee
- alignment of attributes on word boundaries.
-
-11.2.7 PASSWORD
-
- The PASSWORD attribute is used in Shared Secret Responses. It is
- always present in a Shared Secret Response, along with the USERNAME.
-
- The value of PASSWORD is a variable length value that is to be used
- as a shared secret. Its length MUST be a multiple of 4 (measured in
- bytes) in order to guarantee alignment of attributes on word
- boundaries.
-
-11.2.8 MESSAGE-INTEGRITY
-
- The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [13] of the
- STUN message. It can be present in Binding Requests or Binding
- Responses. Since it uses the SHA1 hash, the HMAC will be 20 bytes.
- The text used as input to HMAC is the STUN message, including the
- header, up to and including the attribute preceding the MESSAGE-
- INTEGRITY attribute. That text is then padded with zeroes so as to be
- a multiple of 64 bytes. As a result, the MESSAGE-INTEGRITY attribute
- MUST be the last attribute in any STUN message. The key used as
- input to HMAC depends on the context.
-
-11.2.9 ERROR-CODE
-
- The ERROR-CODE attribute is present in the Binding Error Response and
- Shared Secret Error Response. It is a numeric value in the range of
- 100 to 699 plus a textual reason phrase encoded in UTF-8, and is
- consistent in its code assignments and semantics with SIP [10] and
- HTTP [15]. The reason phrase is meant for user consumption, and can
- be anything appropriate for the response code. The lengths of the
- reason phrases MUST be a multiple of 4 (measured in bytes). This can
- be accomplished by added spaces to the end of the text, if necessary.
- Recommended reason phrases for the defined response codes are
- presented below.
-
- To facilitate processing, the class of the error code (the hundreds
- digit) is encoded separately from the rest of the code.
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 29]
-
-RFC 3489 STUN March 2003
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 |Class| Number |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reason Phrase (variable) ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The class represents the hundreds digit of the response code. The
- value MUST be between 1 and 6. The number represents the response
- code modulo 100, and its value MUST be between 0 and 99.
-
- The following response codes, along with their recommended reason
- phrases (in brackets) are defined at this time:
-
- 400 (Bad Request): The request was malformed. The client should not
- retry the request without modification from the previous
- attempt.
-
- 401 (Unauthorized): The Binding Request did not contain a MESSAGE-
- INTEGRITY attribute.
-
- 420 (Unknown Attribute): The server did not understand a mandatory
- attribute in the request.
-
- 430 (Stale Credentials): The Binding Request did contain a MESSAGE-
- INTEGRITY attribute, but it used a shared secret that has
- expired. The client should obtain a new shared secret and try
- again.
-
- 431 (Integrity Check Failure): The Binding Request contained a
- MESSAGE-INTEGRITY attribute, but the HMAC failed verification.
- This could be a sign of a potential attack, or client
- implementation error.
-
- 432 (Missing Username): The Binding Request contained a MESSAGE-
- INTEGRITY attribute, but not a USERNAME attribute. Both must be
- present for integrity checks.
-
- 433 (Use TLS): The Shared Secret request has to be sent over TLS, but
- was not received over TLS.
-
- 500 (Server Error): The server has suffered a temporary error. The
- client should try again.
-
- 600 (Global Failure:) The server is refusing to fulfill the request.
- The client should not retry.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 30]
-
-RFC 3489 STUN March 2003
-
-
-11.2.10 UNKNOWN-ATTRIBUTES
-
- The UNKNOWN-ATTRIBUTES attribute is present only in a Binding Error
- Response or Shared Secret Error Response when the response code in
- the ERROR-CODE attribute is 420.
-
- The attribute contains a list of 16 bit values, each of which
- represents an attribute type that was not understood by the server.
- If the number of unknown attributes is an odd number, one of the
- attributes MUST be repeated in the list, so that the total length of
- the list is a multiple of 4 bytes.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attribute 1 Type | Attribute 2 Type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attribute 3 Type | Attribute 4 Type ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-11.2.11 REFLECTED-FROM
-
- The REFLECTED-FROM attribute is present only in Binding Responses,
- when the Binding Request contained a RESPONSE-ADDRESS attribute. The
- attribute contains the identity (in terms of IP address) of the
- source where the request came from. Its purpose is to provide
- traceability, so that a STUN server cannot be used as a reflector for
- denial-of-service attacks.
-
- Its syntax is identical to the MAPPED-ADDRESS attribute.
-
-12. Security Considerations
-
-12.1 Attacks on STUN
-
- Generally speaking, attacks on STUN can be classified into denial of
- service attacks and eavesdropping attacks. Denial of service attacks
- can be launched against a STUN server itself, or against other
- elements using the STUN protocol.
-
- STUN servers create state through the Shared Secret Request
- mechanism. To prevent being swamped with traffic, a STUN server
- SHOULD limit the number of simultaneous TLS connections it will hold
- open by dropping an existing connection when a new connection request
- arrives (based on an Least Recently Used (LRU) policy, for example).
- Similarly, it SHOULD limit the number of shared secrets it will
- store, in the event that the server is storing the shared secrets.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 31]
-
-RFC 3489 STUN March 2003
-
-
- The attacks of greater interest are those in which the STUN server
- and client are used to launch DOS attacks against other entities,
- including the client itself.
-
- Many of the attacks require the attacker to generate a response to a
- legitimate STUN request, in order to provide the client with a faked
- MAPPED-ADDRESS. The attacks that can be launched using such a
- technique include:
-
-12.1.1 Attack I: DDOS Against a Target
-
- In this case, the attacker provides a large number of clients with
- the same faked MAPPED-ADDRESS that points to the intended target.
- This will trick all the STUN clients into thinking that their
- addresses are equal to that of the target. The clients then hand out
- that address in order to receive traffic on it (for example, in SIP
- or H.323 messages). However, all of that traffic becomes focused at
- the intended target. The attack can provide substantial
- amplification, especially when used with clients that are using STUN
- to enable multimedia applications.
-
-12.1.2 Attack II: Silencing a Client
-
- In this attack, the attacker seeks to deny a client access to
- services enabled by STUN (for example, a client using STUN to enable
- SIP-based multimedia traffic). To do that, the attacker provides
- that client with a faked MAPPED-ADDRESS. The MAPPED-ADDRESS it
- provides is an IP address that routes to nowhere. As a result, the
- client won't receive any of the packets it expects to receive when it
- hands out the MAPPED-ADDRESS.
-
- This exploitation is not very interesting for the attacker. It
- impacts a single client, which is frequently not the desired target.
- Moreover, any attacker that can mount the attack could also deny
- service to the client by other means, such as preventing the client
- from receiving any response from the STUN server, or even a DHCP
- server.
-
-12.1.3 Attack III: Assuming the Identity of a Client
-
- This attack is similar to attack II. However, the faked MAPPED-
- ADDRESS points to the attacker themself. This allows the attacker to
- receive traffic which was destined for the client.
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 32]
-
-RFC 3489 STUN March 2003
-
-
-12.1.4 Attack IV: Eavesdropping
-
- In this attack, the attacker forces the client to use a MAPPED-
- ADDRESS that routes to itself. It then forwards any packets it
- receives to the client. This attack would allow the attacker to
- observe all packets sent to the client. However, in order to launch
- the attack, the attacker must have already been able to observe
- packets from the client to the STUN server. In most cases (such as
- when the attack is launched from an access network), this means that
- the attacker could already observe packets sent to the client. This
- attack is, as a result, only useful for observing traffic by
- attackers on the path from the client to the STUN server, but not
- generally on the path of packets being routed towards the client.
-
-12.2 Launching the Attacks
-
- It is important to note that attacks of this nature (injecting
- responses with fake MAPPED-ADDRESSes) require that the attacker be
- capable of eavesdropping requests sent from the client to the server
- (or to act as a MITM for such attacks). This is because STUN
- requests contain a transaction identifier, selected by the client,
- which is random with 128 bits of entropy. The server echoes this
- value in the response, and the client ignores any responses that
- don't have a matching transaction ID. Therefore, in order for an
- attacker to provide a faked response that is accepted by the client,
- the attacker needs to know what the transaction ID in the request
- was. The large amount of randomness, combined with the need to know
- when the client sends a request, precludes attacks that involve
- guessing the transaction ID.
-
- Since all of the above attacks rely on this one primitive - injecting
- a response with a faked MAPPED-ADDRESS - preventing the attacks is
- accomplished by preventing this one operation. To prevent it, we
- need to consider the various ways in which it can be accomplished.
- There are several:
-
-12.2.1 Approach I: Compromise a Legitimate STUN Server
-
- In this attack, the attacker compromises a legitimate STUN server
- through a virus or Trojan horse. Presumably, this would allow the
- attacker to take over the STUN server, and control the types of
- responses it generates.
-
- Compromise of a STUN server can also lead to discovery of open ports.
- Knowledge of an open port creates an opportunity for DoS attacks on
- those ports (or DDoS attacks if the traversed NAT is a full cone
- NAT). Discovering open ports is already fairly trivial using port
- probing, so this does not represent a major threat.
-
-
-
-Rosenberg, et al. Standards Track [Page 33]
-
-RFC 3489 STUN March 2003
-
-
-12.2.2 Approach II: DNS Attacks
-
- STUN servers are discovered using DNS SRV records. If an attacker
- can compromise the DNS, it can inject fake records which map a domain
- name to the IP address of a STUN server run by the attacker. This
- will allow it to inject fake responses to launch any of the attacks
- above.
-
-12.2.3 Approach III: Rogue Router or NAT
-
- Rather than compromise the STUN server, an attacker can cause a STUN
- server to generate responses with the wrong MAPPED-ADDRESS by
- compromising a router or NAT on the path from the client to the STUN
- server. When the STUN request passes through the rogue router or
- NAT, it rewrites the source address of the packet to be that of the
- desired MAPPED-ADDRESS. This address cannot be arbitrary. If the
- attacker is on the public Internet (that is, there are no NATs
- between it and the STUN server), and the attacker doesn't modify the
- STUN request, the address has to have the property that packets sent
- from the STUN server to that address would route through the
- compromised router. This is because the STUN server will send the
- responses back to the source address of the request. With a modified
- source address, the only way they can reach the client is if the
- compromised router directs them there. If the attacker is on the
- public Internet, but they can modify the STUN request, they can
- insert a RESPONSE-ADDRESS attribute into the request, containing the
- actual source address of the STUN request. This will cause the
- server to send the response to the client, independent of the source
- address the STUN server sees. This gives the attacker the ability to
- forge an arbitrary source address when it forwards the STUN request.
-
- If the attacker is on a private network (that is, there are NATs
- between it and the STUN server), the attacker will not be able to
- force the server to generate arbitrary MAPPED-ADRESSes in responses.
- They will only be able force the STUN server to generate MAPPED-
- ADDRESSes which route to the private network. This is because the
- NAT between the attacker and the STUN server will rewrite the source
- address of the STUN request, mapping it to a public address that
- routes to the private network. Because of this, the attacker can
- only force the server to generate faked mapped addresses that route
- to the private network. Unfortunately, it is possible that a low
- quality NAT would be willing to map an allocated public address to
- another public address (as opposed to an internal private address),
- in which case the attacker could forge the source address in a STUN
- request to be an arbitrary public address. This kind of behavior
- from NATs does appear to be rare.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 34]
-
-RFC 3489 STUN March 2003
-
-
-12.2.4 Approach IV: MITM
-
- As an alternative to approach III, if the attacker can place an
- element on the path from the client to the server, the element can
- act as a man-in-the-middle. In that case, it can intercept a STUN
- request, and generate a STUN response directly with any desired value
- of the MAPPED-ADDRESS field. Alternatively, it can forward the STUN
- request to the server (after potential modification), receive the
- response, and forward it to the client. When forwarding the request
- and response, this attack is subject to the same limitations on the
- MAPPED-ADDRESS described in Section 12.2.3.
-
-12.2.5 Approach V: Response Injection Plus DoS
-
- In this approach, the attacker does not need to be a MITM (as in
- approaches III and IV). Rather, it only needs to be able to
- eavesdrop onto a network segment that carries STUN requests. This is
- easily done in multiple access networks such as ethernet or
- unprotected 802.11. To inject the fake response, the attacker
- listens on the network for a STUN request. When it sees one, it
- simultaneously launches a DoS attack on the STUN server, and
- generates its own STUN response with the desired MAPPED-ADDRESS
- value. The STUN response generated by the attacker will reach the
- client, and the DoS attack against the server is aimed at preventing
- the legitimate response from the server from reaching the client.
- Arguably, the attacker can do without the DoS attack on the server,
- so long as the faked response beats the real response back to the
- client, and the client uses the first response, and ignores the
- second (even though it's different).
-
-12.2.6 Approach VI: Duplication
-
- This approach is similar to approach V. The attacker listens on the
- network for a STUN request. When it sees it, it generates its own
- STUN request towards the server. This STUN request is identical to
- the one it saw, but with a spoofed source IP address. The spoofed
- address is equal to the one that the attacker desires to have placed
- in the MAPPED-ADDRESS of the STUN response. In fact, the attacker
- generates a flood of such packets. The STUN server will receive the
- one original request, plus a flood of duplicate fake ones. It
- generates responses to all of them. If the flood is sufficiently
- large for the responses to congest routers or some other equipment,
- there is a reasonable probability that the one real response is lost
- (along with many of the faked ones), but the net result is that only
- the faked responses are received by the STUN client. These responses
- are all identical and all contain the MAPPED-ADDRESS that the
- attacker wanted the client to use.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 35]
-
-RFC 3489 STUN March 2003
-
-
- The flood of duplicate packets is not needed (that is, only one faked
- request is sent), so long as the faked response beats the real
- response back to the client, and the client uses the first response,
- and ignores the second (even though it's different).
-
- Note that, in this approach, launching a DoS attack against the STUN
- server or the IP network, to prevent the valid response from being
- sent or received, is problematic. The attacker needs the STUN server
- to be available to handle its own request. Due to the periodic
- retransmissions of the request from the client, this leaves a very
- tiny window of opportunity. The attacker must start the DoS attack
- immediately after the actual request from the client, causing the
- correct response to be discarded, and then cease the DoS attack in
- order to send its own request, all before the next retransmission
- from the client. Due to the close spacing of the retransmits (100ms
- to a few seconds), this is very difficult to do.
-
- Besides DoS attacks, there may be other ways to prevent the actual
- request from the client from reaching the server. Layer 2
- manipulations, for example, might be able to accomplish it.
-
- Fortunately, Approach IV is subject to the same limitations
- documented in Section 12.2.3, which limit the range of MAPPED-
- ADDRESSes the attacker can cause the STUN server to generate.
-
-12.3 Countermeasures
-
- STUN provides mechanisms to counter the approaches described above,
- and additional, non-STUN techniques can be used as well.
-
- First off, it is RECOMMENDED that networks with STUN clients
- implement ingress source filtering (RFC 2827 [7]). This is
- particularly important for the NATs themselves. As Section 12.2.3
- explains, NATs which do not perform this check can be used as
- "reflectors" in DDoS attacks. Most NATs do perform this check as a
- default mode of operation. We strongly advise people that purchase
- NATs to ensure that this capability is present and enabled.
-
- Secondly, it is RECOMMENDED that STUN servers be run on hosts
- dedicated to STUN, with all UDP and TCP ports disabled except for the
- STUN ports. This is to prevent viruses and Trojan horses from
- infecting STUN servers, in order to prevent their compromise. This
- helps mitigate Approach I (Section 12.2.1).
-
- Thirdly, to prevent the DNS attack of Section 12.2.2, Section 9.2
- recommends that the client verify the credentials provided by the
- server with the name used in the DNS lookup.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 36]
-
-RFC 3489 STUN March 2003
-
-
- Finally, all of the attacks above rely on the client taking the
- mapped address it learned from STUN, and using it in application
- layer protocols. If encryption and message integrity are provided
- within those protocols, the eavesdropping and identity assumption
- attacks can be prevented. As such, applications that make use of
- STUN addresses in application protocols SHOULD use integrity and
- encryption, even if a SHOULD level strength is not specified for that
- protocol. For example, multimedia applications using STUN addresses
- to receive RTP traffic would use secure RTP [16].
-
- The above three techniques are non-STUN mechanisms. STUN itself
- provides several countermeasures.
-
- Approaches IV (Section 12.2.4), when generating the response locally,
- and V (Section 12.2.5) require an attacker to generate a faked
- response. This attack is prevented using the message integrity
- mechanism provided in STUN, described in Section 8.1.
-
- Approaches III (Section 12.2.3) IV (Section 12.2.4), when using the
- relaying technique, and VI (12.2.6), however, are not preventable
- through server signatures. Both approaches are most potent when the
- attacker can modify the request, inserting a RESPONSE-ADDRESS that
- routes to the client. Fortunately, such modifications are
- preventable using the message integrity techniques described in
- Section 9.3. However, these three approaches are still functional
- when the attacker modifies nothing but the source address of the STUN
- request. Sadly, this is the one thing that cannot be protected
- through cryptographic means, as this is the change that STUN itself
- is seeking to detect and report. It is therefore an inherent
- weakness in NAT, and not fixable in STUN. To help mitigate these
- attacks, Section 9.4 provides several heuristics for the client to
- follow. The client looks for inconsistent or extra responses, both
- of which are signs of the attacks described above. However, these
- heuristics are just that - heuristics, and cannot be guaranteed to
- prevent attacks. The heuristics appear to prevent the attacks as we
- know how to launch them today. Implementors should stay posted for
- information on new heuristics that might be required in the future.
- Such information will be distributed on the IETF MIDCOM mailing list,
- midcom@ietf.org.
-
-12.4 Residual Threats
-
- None of the countermeasures listed above can prevent the attacks
- described in Section 12.2.3 if the attacker is in the appropriate
- network paths. Specifically, consider the case in which the attacker
- wishes to convince client C that it has address V. The attacker
- needs to have a network element on the path between A and the server
- (in order to modify the request) and on the path between the server
-
-
-
-Rosenberg, et al. Standards Track [Page 37]
-
-RFC 3489 STUN March 2003
-
-
- and V so that it can forward the response to C. Furthermore, if
- there is a NAT between the attacker and the server, V must also be
- behind the same NAT. In such a situation, the attacker can either
- gain access to all the application-layer traffic or mount the DDOS
- attack described in Section 12.1.1. Note that any host which exists
- in the correct topological relationship can be DDOSed. It need not
- be using STUN.
-
-13. IANA Considerations
-
- STUN cannot be extended. Changes to the protocol are made through a
- standards track revision of this specification. As a result, no IANA
- registries are needed. Any future extensions will establish any
- needed registries.
-
-14. IAB Considerations
-
- The IAB has studied the problem of "Unilateral Self Address Fixing",
- which is the general process by which a client attempts to determine
- its address in another realm on the other side of a NAT through a
- collaborative protocol reflection mechanism (RFC 3424 [17]). STUN is
- an example of a protocol that performs this type of function. The
- IAB has mandated that any protocols developed for this purpose
- document a specific set of considerations. This section meets those
- requirements.
-
-14.1 Problem Definition
-
- From RFC 3424 [17], any UNSAF proposal must provide:
-
- Precise definition of a specific, limited-scope problem that is to
- be solved with the UNSAF proposal. A short term fix should not be
- generalized to solve other problems; this is why "short term fixes
- usually aren't".
-
- The specific problems being solved by STUN are:
-
- o Provide a means for a client to detect the presence of one or more
- NATs between it and a server run by a service provider on the
- public Internet. The purpose of such detection is to determine
- additional steps that might be necessary in order to receive
- service from that particular provider.
-
- o Provide a means for a client to detect the presence of one or more
- NATs between it and another client, where the second client is
- reachable from the first, but it is not known whether the second
- client resides on the public Internet.
-
-
-
-
-Rosenberg, et al. Standards Track [Page 38]
-
-RFC 3489 STUN March 2003
-
-
- o Provide a means for a client to obtain an address on the public
- Internet from a non-symmetric NAT, for the express purpose of
- receiving incoming UDP traffic from another host, targeted to that
- address.
-
- STUN does not address TCP, either incoming or outgoing, and does not
- address outgoing UDP communications.
-
-14.2 Exit Strategy
-
- From [17], any UNSAF proposal must provide:
-
- Description of an exit strategy/transition plan. The better short
- term fixes are the ones that will naturally see less and less use
- as the appropriate technology is deployed.
-
- STUN comes with its own built in exit strategy. This strategy is the
- detection operation that is performed as a precursor to the actual
- UNSAF address-fixing operation. This discovery operation, documented
- in Section 10.1, attempts to discover the existence of, and type of,
- any NATS between the client and the service provider network. Whilst
- the detection of the specific type of NAT may be brittle, the
- discovery of the existence of NAT is itself quite robust. As NATs
- are phased out through the deployment of IPv6, the discovery
- operation will return immediately with the result that there is no
- NAT, and no further operations are required. Indeed, the discovery
- operation itself can be used to help motivate deployment of IPv6; if
- a user detects a NAT between themselves and the public Internet, they
- can call up their access provider and complain about it.
-
- STUN can also help facilitate the introduction of midcom. As
- midcom-capable NATs are deployed, applications will, instead of using
- STUN (which also resides at the application layer), first allocate an
- address binding using midcom. However, it is a well-known limitation
- of midcom that it only works when the agent knows the middleboxes
- through which its traffic will flow. Once bindings have been
- allocated from those middleboxes, a STUN detection procedure can
- validate that there are no additional middleboxes on the path from
- the public Internet to the client. If this is the case, the
- application can continue operation using the address bindings
- allocated from midcom. If it is not the case, STUN provides a
- mechanism for self-address fixing through the remaining midcom-
- unaware middleboxes. Thus, STUN provides a way to help transition to
- full midcom-aware networks.
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 39]
-
-RFC 3489 STUN March 2003
-
-
-14.3 Brittleness Introduced by STUN
-
- From [17], any UNSAF proposal must provide:
-
- Discussion of specific issues that may render systems more
- "brittle". For example, approaches that involve using data at
- multiple network layers create more dependencies, increase
- debugging challenges, and make it harder to transition.
-
- STUN introduces brittleness into the system in several ways:
-
- o The discovery process assumes a certain classification of devices
- based on their treatment of UDP. There could be other types of
- NATs that are deployed that would not fit into one of these molds.
- Therefore, future NATs may not be properly detected by STUN. STUN
- clients (but not servers) would need to change to accommodate
- that.
-
- o The binding acquisition usage of STUN does not work for all NAT
- types. It will work for any application for full cone NATs only.
- For restricted cone and port restricted cone NAT, it will work for
- some applications depending on the application. Application
- specific processing will generally be needed. For symmetric NATs,
- the binding acquisition will not yield a usable address. The
- tight dependency on the specific type of NAT makes the protocol
- brittle.
-
- o STUN assumes that the server exists on the public Internet. If
- the server is located in another private address realm, the user
- may or may not be able to use its discovered address to
- communicate with other users. There is no way to detect such a
- condition.
-
- o The bindings allocated from the NAT need to be continuously
- refreshed. Since the timeouts for these bindings is very
- implementation specific, the refresh interval cannot easily be
- determined. When the binding is not being actively used to
- receive traffic, but to wait for an incoming message, the binding
- refresh will needlessly consume network bandwidth.
-
- o The use of the STUN server as an additional network element
- introduces another point of potential security attack. These
- attacks are largely prevented by the security measures provided by
- STUN, but not entirely.
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 40]
-
-RFC 3489 STUN March 2003
-
-
- o The use of the STUN server as an additional network element
- introduces another point of failure. If the client cannot locate
- a STUN server, or if the server should be unavailable due to
- failure, the application cannot function.
-
- o The use of STUN to discover address bindings will result in an
- increase in latency for applications. For example, a Voice over
- IP application will see an increase of call setup delays equal to
- at least one RTT to the STUN server.
-
- o The discovery of binding lifetimes is prone to error. It assumes
- that the same lifetime will exist for all bindings. This may not
- be true if the NAT uses dynamic binding lifetimes to handle
- overload, or if the NAT itself reboots during the discovery
- process.
-
- o STUN imposes some restrictions on the network topologies for
- proper operation. If client A obtains an address from STUN server
- X, and sends it to client B, B may not be able to send to A using
- that IP address. The address will not work if any of the
- following is true:
-
- - The STUN server is not in an address realm that is a common
- ancestor (topologically) of both clients A and B. For example,
- consider client A and B, both of which have residential NAT
- devices. Both devices connect them to their cable operators,
- but both clients have different providers. Each provider has a
- NAT in front of their entire network, connecting it to the
- public Internet. If the STUN server used by A is in A's cable
- operator's network, an address obtained by it will not be
- usable by B. The STUN server must be in the network which is a
- common ancestor to both - in this case, the public Internet.
-
- - The STUN server is in an address realm that is a common
- ancestor to both clients, but both clients are behind the same
- NAT connecting to that address realm. For example, if the two
- clients in the previous example had the same cable operator,
- that cable operator had a single NAT connecting their network
- to the public Internet, and the STUN server was on the public
- Internet, the address obtained by A would not be usable by B.
- That is because some NATs will not accept an internal packet
- sent to a public IP address which is mapped back to an internal
- address. To deal with this, additional protocol mechanisms or
- configuration parameters need to be introduced which detect
- this case.
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 41]
-
-RFC 3489 STUN March 2003
-
-
- o Most significantly, STUN introduces potential security threats
- which cannot be eliminated. This specification describes
- heuristics that can be used to mitigate the problem, but it is
- provably unsolvable given what STUN is trying to accomplish.
- These security problems are described fully in Section 12.
-
-14.4 Requirements for a Long Term Solution
-
- From [17], any UNSAF proposal must provide:
-
- Identify requirements for longer term, sound technical solutions
- -- contribute to the process of finding the right longer term
- solution.
-
- Our experience with STUN has led to the following requirements for a
- long term solution to the NAT problem:
-
- Requests for bindings and control of other resources in a NAT
- need to be explicit. Much of the brittleness in STUN derives from
- its guessing at the parameters of the NAT, rather than telling the
- NAT what parameters to use.
-
- Control needs to be "in-band". There are far too many scenarios
- in which the client will not know about the location of
- middleboxes ahead of time. Instead, control of such boxes needs
- to occur in-band, traveling along the same path as the data will
- itself travel. This guarantees that the right set of middleboxes
- are controlled. This is only true for first-party controls;
- third-party controls are best handled using the midcom framework.
-
- Control needs to be limited. Users will need to communicate
- through NATs which are outside of their administrative control.
- In order for providers to be willing to deploy NATs which can be
- controlled by users in different domains, the scope of such
- controls needs to be extremely limited - typically, allocating a
- binding to reach the address where the control packets are coming
- from.
-
- Simplicity is Paramount. The control protocol will need to be
- implement in very simple clients. The servers will need to
- support extremely high loads. The protocol will need to be
- extremely robust, being the precursor to a host of application
- protocols. As such, simplicity is key.
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 42]
-
-RFC 3489 STUN March 2003
-
-
-14.5 Issues with Existing NAPT Boxes
-
- From [17], any UNSAF proposal must provide:
-
- Discussion of the impact of the noted practical issues with
- existing, deployed NA[P]Ts and experience reports.
-
- Several of the practical issues with STUN involve future proofing -
- breaking the protocol when new NAT types get deployed. Fortunately,
- this is not an issue at the current time, since most of the deployed
- NATs are of the types assumed by STUN. The primary usage STUN has
- found is in the area of VoIP, to facilitate allocation of addresses
- for receiving RTP [12] traffic. In that application, the periodic
- keepalives are provided by the RTP traffic itself. However, several
- practical problems arise for RTP. First, RTP assumes that RTCP
- traffic is on a port one higher than the RTP traffic. This pairing
- property cannot be guaranteed through NATs that are not directly
- controllable. As a result, RTCP traffic may not be properly
- received. Protocol extensions to SDP have been proposed which
- mitigate this by allowing the client to signal a different port for
- RTCP [18]. However, there will be interoperability problems for some
- time.
-
- For VoIP, silence suppression can cause a gap in the transmission of
- RTP packets. This could result in the loss of a binding in the
- middle of a call, if that silence period exceeds the binding timeout.
- This can be mitigated by sending occasional silence packets to keep
- the binding alive. However, the result is additional brittleness;
- proper operation depends on the silence suppression algorithm in use,
- the usage of a comfort noise codec, the duration of the silence
- period, and the binding lifetime in the NAT.
-
-14.6 In Closing
-
- The problems with STUN are not design flaws in STUN. The problems in
- STUN have to do with the lack of standardized behaviors and controls
- in NATs. The result of this lack of standardization has been a
- proliferation of devices whose behavior is highly unpredictable,
- extremely variable, and uncontrollable. STUN does the best it can in
- such a hostile environment. Ultimately, the solution is to make the
- environment less hostile, and to introduce controls and standardized
- behaviors into NAT. However, until such time as that happens, STUN
- provides a good short term solution given the terrible conditions
- under which it is forced to operate.
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 43]
-
-RFC 3489 STUN March 2003
-
-
-15. Acknowledgments
-
- The authors would like to thank Cedric Aoun, Pete Cordell, Cullen
- Jennings, Bob Penfield and Chris Sullivan for their comments, and
- Baruch Sterman and Alan Hawrylyshen for initial implementations.
- Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning
- Schulzrinne for IESG and IAB input on this work.
-
-16. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to indicate requirement
- levels", BCP 14, RFC 2119, March 1997.
-
- [2] Dierks, T. and C. Allen, "The TLS protocol Version 1.0", RFC
- 2246, January 1999.
-
- [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
- Transport Layer Security (TLS)", RFC 3268, June 2002.
-
- [5] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
-
- [6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
-
- [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
- Denial of Service Attacks which employ IP Source Address
- Spoofing", BCP 38, RFC 2827, May 2000.
-
-17. Informative References
-
- [8] Senie, D., "Network Address Translator (NAT)-Friendly
- Application Design Guidelines", RFC 3235, January 2002.
-
- [9] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
- Rayhan, "Middlebox Communication Architecture and Framework",
- RFC 3303, August 2002.
-
- [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
- Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
- Session Initiation Protocol", RFC 3261, June 2002.
-
- [11] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
- IP Network Address Translator", RFC 3027, January 2001.
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 44]
-
-RFC 3489 STUN March 2003
-
-
- [12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
- "RTP: A Transport Protocol for Real-Time Applications", RFC
- 1889, January 1996.
-
- [13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
- for Message Authentication", RFC 2104, February 1997.
-
- [14] Kohl, J. and C. Neuman, "The kerberos Network Authentication
- Service (V5)", RFC 1510, September 1993.
-
- [15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
- HTTP/1.1", RFC 2616, June 1999.
-
- [16] Baugher M., et al., "The secure real-time transport protocol",
- Work in Progress.
-
- [17] Daigle, L., Editor, "IAB Considerations for UNilateral Self-
- Address Fixing (UNSAF) Across Network Address Translation", RFC
- 3424, November 2002.
-
- [18] Huitema, C., "RTCP attribute in SDP", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 45]
-
-RFC 3489 STUN March 2003
-
-
-18. Authors' Addresses
-
- Jonathan Rosenberg
- dynamicsoft
- 72 Eagle Rock Avenue
- First Floor
- East Hanover, NJ 07936
-
- EMail: jdrosen@dynamicsoft.com
-
-
- Joel Weinberger
- dynamicsoft
- 72 Eagle Rock Avenue
- First Floor
- East Hanover, NJ 07936
-
- EMail: jweinberger@dynamicsoft.com
-
-
- Christian Huitema
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
-
- EMail: huitema@microsoft.com
-
-
- Rohan Mahy
- Cisco Systems
- 101 Cooper St
- Santa Cruz, CA 95060
-
- EMail: rohan@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 46]
-
-RFC 3489 STUN March 2003
-
-
-19. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et al. Standards Track [Page 47]
-
diff --git a/libs/stund/root.pem b/libs/stund/root.pem
deleted file mode 100644
index 3495f58c7c75cc36101bf0860f8403dd28a5ec3e..0000000000000000000000000000000000000000
--- a/libs/stund/root.pem
+++ /dev/null
@@ -1,20 +0,0 @@
------BEGIN CERTIFICATE-----
-MIIDWTCCAsKgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBgDELMAkGA1UEBhMCVUEx
-CzAJBgNVBAgTAkNBMREwDwYDVQQHEwhNaWxwaXRhczEOMAwGA1UEChMFRm9vQ28x
-EzARBgNVBAsTCndpZGdldCBkaXYxEjAQBgNVBAMTCWxvY2FsaG9zdDEYMBYGCSqG
-SIb3DQEJARYJZm9vQGZvby5jMB4XDTAyMTEwMTAzMDUwOFoXDTAyMTIwMTAzMDUw
-OFowgYAxCzAJBgNVBAYTAlVBMQswCQYDVQQIEwJDQTERMA8GA1UEBxMITWlscGl0
-YXMxDjAMBgNVBAoTBUZvb0NvMRMwEQYDVQQLEwp3aWRnZXQgZGl2MRIwEAYDVQQD
-Ewlsb2NhbGhvc3QxGDAWBgkqhkiG9w0BCQEWCWZvb0Bmb28uYzCBnzANBgkqhkiG
-9w0BAQEFAAOBjQAwgYkCgYEAwgvATkHnZzuN3poEtJ+l3p8rWlRVN4QnT4hW/pxI
-kZgs+U3/2QX2HZtGBcm+YJCfAICWdsnMDwhPlyp/YXdpyhe2wkl1LdukvMav8j+H
-shEQdcO+qPrjUZ8VLkMsMxM56b+UNT1m3CEoQ3qnIGuIb0DjvwfJRaiTo15LZv5j
-1wkCAwEAAaOB4DCB3TAdBgNVHQ4EFgQUlnqNTIdfldOWBuAsqXVxr8OB4p4wga0G
-A1UdIwSBpTCBooAUlnqNTIdfldOWBuAsqXVxr8OB4p6hgYakgYMwgYAxCzAJBgNV
-BAYTAlVBMQswCQYDVQQIEwJDQTERMA8GA1UEBxMITWlscGl0YXMxDjAMBgNVBAoT
-BUZvb0NvMRMwEQYDVQQLEwp3aWRnZXQgZGl2MRIwEAYDVQQDEwlsb2NhbGhvc3Qx
-GDAWBgkqhkiG9w0BCQEWCWZvb0Bmb28uY4IBADAMBgNVHRMEBTADAQH/MA0GCSqG
-SIb3DQEBBAUAA4GBAC0j/qC+PRfpIRwISxQALNm/HPtIFbQDNFwYBfVgxxQOm9cT
-gP1S9zRU8Z6K7E0ZYu6VvZAzuY9qOJK4M6X0gdGlx60QqR7poAnFiWtUtrWzs6YS
-M6ZGUjSXnnqMkP1vauvbmV72CdYLR9dIQ6OMQqJ6GKznOGJd0hW8nHzhvBUh
------END CERTIFICATE-----
diff --git a/libs/stund/server.cxx b/libs/stund/server.cxx
deleted file mode 100644
index 2319592db515daf61cb832bea4e8ea7f0aada444..0000000000000000000000000000000000000000
--- a/libs/stund/server.cxx
+++ /dev/null
@@ -1,292 +0,0 @@
-#include <cassert>
-#include <cstring>
-#include <iostream>
-#include <cstdlib>
-
-#ifndef WIN32
-#include <sys/time.h>
-#include <sys/types.h>
-#include <unistd.h>
-#include <netinet/in.h>
-#include <errno.h>
-#include <stdlib.h>
-#endif
-
-#include "udp.h"
-#include "stun.h"
-
-
-using namespace std;
-
-
-void
-usage()
-{
- cerr << "Usage: " << endl
- << " ./server [-v] [-h] [-h IP_Address] [-a IP_Address] [-p port] [-o port] [-m mediaport]" << endl
- << " " << endl
- << " If the IP addresses of your NIC are 10.0.1.150 and 10.0.1.151, run this program with" << endl
- << " ./server -v -h 10.0.1.150 -a 10.0.1.151" << endl
- << " STUN servers need two IP addresses and two ports, these can be specified with:" << endl
- << " -h sets the primary IP" << endl
- << " -a sets the secondary IP" << endl
- << " -p sets the primary port and defaults to 3478" << endl
- << " -o sets the secondary port and defaults to 3479" << endl
- << " -b makes the program run in the backgroud" << endl
- << " -m sets up a STERN server starting at port m" << endl
- << " -v runs in verbose mode" << endl
- // in makefile too
- << endl;
-}
-
-
-int
-main(int argc, char* argv[])
-{
- assert( sizeof(UInt8 ) == 1 );
- assert( sizeof(UInt16) == 2 );
- assert( sizeof(UInt32) == 4 );
-
- initNetwork();
-
- clog << "STUN server version " << STUN_VERSION << endl;
-
- StunAddress4 myAddr;
- StunAddress4 altAddr;
- bool verbose=false;
- bool background=false;
-
- myAddr.addr = 0;
- altAddr.addr = 0;
- myAddr.port = STUN_PORT;
- altAddr.port = STUN_PORT+1;
- int myPort = 0;
- int altPort = 0;
- int myMediaPort = 0;
-
- UInt32 interfaces[10];
- int numInterfaces = stunFindLocalInterfaces(interfaces,10);
-
- if (numInterfaces == 2)
- {
- myAddr.addr = interfaces[0];
- myAddr.port = STUN_PORT;
- altAddr.addr = interfaces[1];
- altAddr.port = STUN_PORT+1;
- }
-
- for ( int arg = 1; arg<argc; arg++ )
- {
- if ( !strcmp( argv[arg] , "-v" ) )
- {
- verbose = true;
- }
- else if ( !strcmp( argv[arg] , "-b" ) )
- {
- background = true;
- }
- else if ( !strcmp( argv[arg] , "-h" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- stunParseServerName(argv[arg], myAddr);
- }
- else if ( !strcmp( argv[arg] , "-a" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- stunParseServerName(argv[arg], altAddr);
- }
- else if ( !strcmp( argv[arg] , "-p" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- myPort = UInt16(strtol( argv[arg], NULL, 10));
- }
- else if ( !strcmp( argv[arg] , "-o" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- altPort = UInt16(strtol( argv[arg], NULL, 10));
- }
- else if ( !strcmp( argv[arg] , "-m" ) )
- {
- arg++;
- if ( argc <= arg )
- {
- usage();
- exit(-1);
- }
- myMediaPort = UInt16(strtol( argv[arg], NULL, 10));
- }
- else
- {
- usage();
- exit(-1);
- }
- }
-
- if ( myPort != 0 )
- {
- myAddr.port = myPort;
- }
- if ( altPort != 0 )
- {
- altAddr.port = altPort;
- }
-
- if ( (myAddr.addr == 0) || (altAddr.addr == 0) )
- {
- clog << "If your machine does not have exactly two ethernet interfaces, "
- << "you must specify the server and alt server" << endl;
- //usage();
- //exit(-1);
- }
-
- if ( myAddr.port == altAddr.port )
- {
- altAddr.port = myAddr.port+1;
- }
-
- if ( verbose )
- {
- clog << "Running with on interface "
- << myAddr << " with alternate "
- << altAddr << endl;
- }
-
- if (
- ( myAddr.addr == 0 ) ||
- ( myAddr.port == 0 ) ||
- //( altAddr.addr == 0 ) ||
- ( altAddr.port == 0 )
- )
- {
- cerr << "Bad command line" << endl;
- exit(1);
- }
-
- if ( altAddr.addr == 0 )
- {
- cerr << "Warning - no alternate ip address STUN will not work" << endl;
- //exit(1);
- }
-
-#if defined(WIN32)
- int pid=0;
-
- if ( background )
- {
- cerr << "The -b background option does not work in windows" << endl;
- exit(-1);
- }
-#else
- pid_t pid=0;
-
- if ( background )
- {
- pid = fork();
-
- if (pid < 0)
- {
- cerr << "fork: unable to fork" << endl;
- exit(-1);
- }
- }
-#endif
-
- if (pid == 0) //child or not using background
- {
- StunServerInfo info;
- bool ok = stunInitServer(info, myAddr, altAddr, myMediaPort, verbose);
-
- int c=0;
- while (ok)
- {
- ok = stunServerProcess(info, verbose);
- c++;
- if ( c%1000 == 0 )
- {
- clog << "*";
- }
- }
- // Notreached
- }
-
- return 0;
-}
-
-
-/* ====================================================================
- * The Vovida Software License, Version 1.0
- *
- * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. The names "VOCAL", "Vovida Open Communication Application Library",
- * and "Vovida Open Communication Application Library (VOCAL)" must
- * not be used to endorse or promote products derived from this
- * software without prior written permission. For written
- * permission, please contact vocal@vovida.org.
- *
- * 4. Products derived from this software may not be called "VOCAL", nor
- * may "VOCAL" appear in their name, without prior written
- * permission of Vovida Networks, Inc.
- *
- * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
- * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA
- * NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES
- * IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
- * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
- * DAMAGE.
- *
- * ====================================================================
- *
- * This software consists of voluntary contributions made by Vovida
- * Networks, Inc. and many individuals on behalf of Vovida Networks,
- * Inc. For more information on Vovida Networks, Inc., please see
- * <http://www.vovida.org/>.
- *
- */
-
-
-// Local Variables:
-// mode:c++
-// c-file-style:"ellemtel"
-// c-file-offsets:((case-label . +))
-// indent-tabs-mode:nil
-// End:
diff --git a/libs/stund/server.sln b/libs/stund/server.sln
deleted file mode 100644
index d943a29e6ba437a17795830496854f394bee7b61..0000000000000000000000000000000000000000
--- a/libs/stund/server.sln
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsoft Visual Studio Solution File, Format Version 7.00
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "server", "server.vcproj", "{2011B7B6-6932-431D-83A3-E825A271F8A8}"
-EndProject
-Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug
- ConfigName.1 = Release
- EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Debug.ActiveCfg = Debug|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Debug.Build.0 = Debug|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Release.ActiveCfg = Release|Win32
- {2011B7B6-6932-431D-83A3-E825A271F8A8}.Release.Build.0 = Release|Win32
- EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
-EndGlobal
diff --git a/libs/stund/server.vcproj b/libs/stund/server.vcproj
deleted file mode 100644
index 8fb6e97a9bc732a5aab6ff9841b06d5984b66830..0000000000000000000000000000000000000000
--- a/libs/stund/server.vcproj
+++ /dev/null
@@ -1,134 +0,0 @@
-<?xml version="1.0" encoding = "Windows-1252"?>
-<VisualStudioProject
- ProjectType="Visual C++"
- Version="7.00"
- Name="server"
- ProjectGUID="{2011B7B6-6932-431D-83A3-E825A271F8A8}"
- Keyword="Win32Proj">
- <Platforms>
- <Platform
- Name="Win32"/>
- </Platforms>
- <Configurations>
- <Configuration
- Name="Debug|Win32"
- OutputDirectory="ServerDebug"
- IntermediateDirectory="ServerDebug"
- ConfigurationType="1"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="0"
- PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
- MinimalRebuild="TRUE"
- BasicRuntimeChecks="3"
- RuntimeLibrary="5"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="4"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- AdditionalDependencies="Ws2_32.lib"
- OutputFile="$(OutDir)/server.exe"
- LinkIncremental="2"
- GenerateDebugInformation="TRUE"
- ProgramDatabaseFile="$(OutDir)/server.pdb"
- SubSystem="1"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- <Configuration
- Name="Release|Win32"
- OutputDirectory="ServerRelease"
- IntermediateDirectory="ServerRelease"
- ConfigurationType="1"
- CharacterSet="2">
- <Tool
- Name="VCCLCompilerTool"
- Optimization="2"
- InlineFunctionExpansion="1"
- OmitFramePointers="TRUE"
- PreprocessorDefinitions="WIN32;NDEBUG;_CONSOLE"
- StringPooling="TRUE"
- RuntimeLibrary="4"
- EnableFunctionLevelLinking="TRUE"
- UsePrecompiledHeader="0"
- WarningLevel="3"
- Detect64BitPortabilityProblems="FALSE"
- DebugInformationFormat="3"/>
- <Tool
- Name="VCCustomBuildTool"/>
- <Tool
- Name="VCLinkerTool"
- AdditionalDependencies="Ws2_32.lib"
- OutputFile="$(OutDir)/server.exe"
- LinkIncremental="1"
- GenerateDebugInformation="TRUE"
- SubSystem="1"
- OptimizeReferences="2"
- EnableCOMDATFolding="2"
- TargetMachine="1"/>
- <Tool
- Name="VCMIDLTool"/>
- <Tool
- Name="VCPostBuildEventTool"/>
- <Tool
- Name="VCPreBuildEventTool"/>
- <Tool
- Name="VCPreLinkEventTool"/>
- <Tool
- Name="VCResourceCompilerTool"/>
- <Tool
- Name="VCWebServiceProxyGeneratorTool"/>
- <Tool
- Name="VCWebDeploymentTool"/>
- </Configuration>
- </Configurations>
- <Files>
- <Filter
- Name="Source Files"
- Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm">
- <File
- RelativePath="server.cxx">
- </File>
- <File
- RelativePath="stun.cxx">
- </File>
- <File
- RelativePath="udp.cxx">
- </File>
- </Filter>
- <Filter
- Name="Header Files"
- Filter="h;hpp;hxx;hm;inl;inc">
- <File
- RelativePath="stun.h">
- </File>
- <File
- RelativePath="udp.h">
- </File>
- </Filter>
- <Filter
- Name="Resource Files"
- Filter="rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe">
- </Filter>
- </Files>
- <Globals>
- </Globals>
-</VisualStudioProject>
diff --git a/libs/stund/tlsServer.cxx b/libs/stund/tlsServer.cxx
deleted file mode 100644
index c1b819b9c0fc1f546dcbd35abafa6c893cb8ec35..0000000000000000000000000000000000000000
--- a/libs/stund/tlsServer.cxx
+++ /dev/null
@@ -1,502 +0,0 @@
-
-/*
- This program takes no arguments. It opens the STUN tcp port and rus a tls server
- on it.
-*/
-
-#include <sys/types.h>
-#include <string.h>
-#include <openssl/e_os2.h>
-#include <openssl/evp.h>
-#include <openssl/crypto.h>
-#include <openssl/err.h>
-#include <openssl/pem.h>
-#include <openssl/pkcs7.h>
-#include <openssl/x509.h>
-#include <openssl/x509v3.h>
-#include <openssl/ssl.h>
-#ifdef WIN32
-#include <errno.h>
-#include <winsock2.h>
-#include <io.h>
-#endif
-
-#ifndef WIN32
-#include <sys/types.h>
-#include <sys/time.h>
-#include <sys/socket.h>
-#include <sys/select.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <unistd.h>
-#endif
-
-#ifdef WIN32
-# include <windows.h>
-# include <winbase.h>
-# include <errno.h>
-# include <winsock2.h>
-# include <io.h>
-typedef unsigned int u_int32_t;
-#endif
-
-#include <cassert>
-#include <fcntl.h>
-
-#include <iostream>
-#include <cstdlib>
-#include <stdio.h>
-
-#ifdef __MACH__
-typedef int socklen_t;
-#endif
-
-#include "stun.h"
-
-using namespace std;
-
-
-
-#define MAX_CONNECTIONS 64
-
-
-#ifdef WIN32
-typedef int socklen_t;
-//#define errno WSAGetLastError()
-typedef SOCKET Socket;
-#else
-typedef int Socket;
-static const Socket INVALID_SOCKET = -1;
-static const int SOCKET_ERROR = -1;
-#endif
-
-
-
-// TODO - !cj! - need to deal with closing connections
-
-
-void
-makeSocketNonBlocking(Socket fd)
-{
-#if WIN32
- unsigned long noBlock = 1;
- int errNoBlock = ioctlsocket( fd, FIONBIO , &noBlock );
- if ( errNoBlock != 0 )
- {
- assert(0);
- }
-#else
- int flags = fcntl( fd, F_GETFL, 0);
- int errNoBlock = fcntl(fd, F_SETFL, flags | O_NONBLOCK );
- if ( errNoBlock != 0 ) // !cj! I may have messed up this line
- {
- assert(0);
- }
-#endif
-}
-
-
-int
-main()
-{
-#ifdef WIN32
- WORD wVersionRequested = MAKEWORD( 2, 2 );
- WSADATA wsaData;
- int err;
-
- err = WSAStartup( wVersionRequested, &wsaData );
- if ( err != 0 )
- {
- // could not find a usable WinSock DLL
- //cerr << "Could not load winsock" << endl;
- assert(0); // is this is failing, try a different version that 2.2, 1.0 or later will likely work
- exit(1);
- }
-#endif
-
- // contexts for each connection
- SSL* ssl[MAX_CONNECTIONS];
-
- // buffers for each connection
- BIO* bio[MAX_CONNECTIONS];
-
- // file descriptors for each connection
- Socket fd[MAX_CONNECTIONS];
-
- // ip address of other side of connection
- int peerip[MAX_CONNECTIONS];
-
- // root cert list
- X509_STORE* certAuthorities;
- // my public cert
- X509* publicCert;
- // my private key
- EVP_PKEY* privateKey;
- // SSL Context
- SSL_CTX* ctx;
-
- Socket mFd;
-
- char* password = "password";
-
-
- for ( int i=0; i<MAX_CONNECTIONS; i++ )
- {
- fd[i]=-1;
- bio[i]=0;
- ssl[i]=0;
- }
-
-
- // load public cert
- FILE* fp = fopen("id.pem","rb");
- if ( !fp )
- {
- cerr << "Could not read public cert" <<endl; exit(1);
- }
- publicCert = PEM_read_X509(fp,NULL,NULL,NULL);
- if (!publicCert)
- {
- cerr << "Error reading contents of public cert"<<endl; exit(1);
- }
- cerr << "Loaded public cert"<<endl;
-
-
- // load private key
- fp = fopen("id_key.pem","rb");
- if ( !fp )
- {
- cerr << "Could not read private key"<<endl; exit(1);
- }
- privateKey = PEM_read_PrivateKey(fp,NULL,NULL,password);
- if (!privateKey)
- {
- cerr << "Error reading contents of private key file "<<endl;exit(1);
- }
- cerr << "Loaded private key "<<endl;
-
- // load root certs
- certAuthorities = X509_STORE_new();
- assert( certAuthorities );
- if ( X509_STORE_load_locations(certAuthorities,"root.pem",NULL) != 1 )
- {
- cerr << "Error reading contents of root cert file "<<endl;
- }
- cerr << "Loaded public CAs"<<endl;
-
-
- // set up main security context
- SSL_library_init();
-
- SSL_load_error_strings();
-
- OpenSSL_add_all_ciphers();
- OpenSSL_add_all_digests();
-
- ERR_load_crypto_strings();
-
- ctx=SSL_CTX_new( TLSv1_method() );
- assert( ctx );
-
- int ok;
- ok = SSL_CTX_use_certificate(ctx, publicCert);
- assert( ok == 1);
-
- ok = SSL_CTX_use_PrivateKey(ctx,privateKey);
- assert( ok == 1);
-
- assert( certAuthorities );
- SSL_CTX_set_cert_store(ctx, certAuthorities);
-
-
- // open a socket to listen for requests on
- mFd = socket(PF_INET, SOCK_STREAM, 0);
-
- sockaddr_in addr;
- addr.sin_family = AF_INET;
- addr.sin_addr.s_addr = htonl(INADDR_ANY);
- addr.sin_port = htons(STUN_PORT);
-
- if ( bind( mFd, (struct sockaddr*) &addr, sizeof(addr)) == SOCKET_ERROR )
- {
- int err = errno;
- if ( err == EADDRINUSE )
- {
- cerr << "Port already in use"<<endl;
- }
- else
- {
- cerr << "Could not bind to port"<<endl;
- }
-
- exit(0);
- }
-
- makeSocketNonBlocking(mFd);
-
- int e = listen(mFd,64 );
- if (e != 0 )
- {
- assert(0);
- }
-
-
- cerr << "Ready for requests" << endl;
-
- while ( true )
- {
- // set up the read fd set for select
- fd_set read;
- FD_ZERO(&read);
- int size=0;
-
- FD_SET(mFd, &read);
- size = mFd+1;
-
- for ( int i=0; i<MAX_CONNECTIONS; i++ )
- {
- if ( fd[i] > 0 )
- {
- FD_SET(fd[i], &read);
- size = ( int(fd[i]+1) > size) ? int(fd[i]+1) : size;
- }
-
- }
-
-
- // do a select
- unsigned long ms = 500;
- struct timeval tv;
- tv.tv_sec = (ms/1000);
- tv.tv_usec = (ms%1000)*1000;
- int e = select(size, &read, NULL, NULL, &tv);
-
- cerr << "." ;
-
- // process any new connections
- if ( FD_ISSET(mFd, &read))
- {
- cerr << "Got a new connection" << endl;
-
- // find an unused connection
- int i=0;
- for ( ; i<MAX_CONNECTIONS; i++ )
- {
- if ( fd[i] == -1 )
- {
- break;
- }
- }
-
- if ( i >= MAX_CONNECTIONS )
- {
- cerr << "Ran out of connections to use "<<endl;
- break;
- }
-
- struct sockaddr_in peer;
- int peerLen=sizeof(peer);
- fd[i] = accept( mFd, (struct sockaddr*)&peer,(socklen_t*)&peerLen);
- if ( fd[i] == -1 )
- {
- int err = errno;
- cerr << "Error on accept: " << strerror(err)<<endl;
- break;
- }
-
- int* ptr = (int*)( &peer.sin_addr );
- peerip[i] = *ptr;
-
- ssl[i] = NULL;
-
- ssl[i] = SSL_new(ctx);
- assert(ssl[i]);
-
- bio[i] = BIO_new_socket(fd[i],0/*close flag*/);
- assert( bio[i] );
-
- SSL_set_bio( ssl[i], bio[i], bio[i] );
-
- int ok=0;
- ok = SSL_accept(ssl[i]);
-
- if ( ok != 1 )
- {
- int err = SSL_get_error(ssl[i],ok);
- char buf[256];
- ERR_error_string_n(err,buf,sizeof(buf));
-
- cerr << "ssl connection failed "<<endl;
-
- bio[i] = NULL;
- }
-
- makeSocketNonBlocking(fd[i]);
- }
-
-
- // process reads and writes
- for (int i=0; i<MAX_CONNECTIONS; i++)
- {
- if ( ssl[i] )
- if ( FD_ISSET( fd[i], &read) || SSL_pending(ssl[i]) )
- {
- cerr << "got a message on connection " << i << endl;
-
- char buf[STUN_MAX_MESSAGE_SIZE];
-
- int ret = SSL_read(ssl[i],buf,sizeof(buf));
- if (ret < 0 )
- {
- int err = SSL_get_error(ssl[i],ret);
- switch (err)
- {
- case SSL_ERROR_WANT_READ:
- case SSL_ERROR_WANT_WRITE:
- case SSL_ERROR_NONE:
- {
- cerr << "Got TLS read got condition of " << err <<endl;
- }
- break;
- default:
- {
- char buf[256];
- ERR_error_string_n(err,buf,sizeof(buf));
- cerr << "Got TLS read error " << err << " " << buf <<endl;
- }
- break;
- }
- // !cj! - big mem leak here - need to close and cleanup
- closesocket( fd[i] );
- fd[i] = -1;
- ssl[i]=0;
- }
-
- cerr << "Received message with " << ret << " bytes"<<endl;
-
- StunAddress4 from;
- StunAddress4 myAddr;
- StunAddress4 altAddr;
- StunMessage resp;
- StunAddress4 destination;
- StunAtrString hmacPassword;
- bool changePort;
- bool changeIp;
-
- from.addr = peerip[i];
-
- bool ok = stunServerProcessMsg( buf,ret,
- from,
- myAddr,
- altAddr,
- &resp,
- &destination,
- &hmacPassword,
- &changePort,
- &changeIp,
- true /*verbose*/ );
-
- if (!ok )
- {
- cerr << "Message did not parse - closeing conneciton " << i <<endl;
- closesocket( fd[i] );
- fd[i] = -1;
- ssl[i]=0;
- }
-
- if (ok)
- {
- int len = stunEncodeMessage( resp, buf, sizeof(buf), hmacPassword );
-
- ret = SSL_write(ssl[i],(const char*)buf,len);
-
- if (ret < 0 )
- {
- int err = SSL_get_error(ssl[i],ret);
- switch (err)
- {
- case SSL_ERROR_WANT_READ:
- case SSL_ERROR_WANT_WRITE:
- case SSL_ERROR_NONE:
- {
- cerr << "Got TLS write got codition of " << err <<endl;
- }
- break;
- default:
- {
- cerr << "Got TLS write error " << err <<endl;
- }
- break;
- }
- // !cj! big mem leak - need to cleanup
- closesocket( fd[i] );
- fd[i] = -1;
- ssl[i]=0;
- }
- }
- }
- }
- }
-
- return 0;
-}
-
-
-/* ====================================================================
- * The Vovida Software License, Version 1.0
- *
- * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. The names "VOCAL", "Vovida Open Communication Application Library",
- * and "Vovida Open Communication Application Library (VOCAL)" must
- * not be used to endorse or promote products derived from this
- * software without prior written permission. For written
- * permission, please contact vocal@vovida.org.
- *
- * 4. Products derived from this software may not be called "VOCAL", nor
- * may "VOCAL" appear in their name, without prior written
- * permission of Vovida Networks, Inc.
- *
- * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
- * NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA
- * NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES
- * IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
- * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
- * DAMAGE.
- *
- * ====================================================================
- *
- * This software consists of voluntary contributions made by Vovida
- * Networks, Inc. and many individuals on behalf of Vovida Networks,
- * Inc. For more information on Vovida Networks, Inc., please see
- * <http://www.vovida.org/>.
- *
- */
-
-// Local Variables:
-// mode:c++
-// c-file-style:"ellemtel"
-// c-file-offsets:((case-label . +))
-// indent-tabs-mode:nil
-// End:
-
-
diff --git a/libs/stund/wnattest.bat b/libs/stund/wnattest.bat
deleted file mode 100644
index edd9fdef34cf6c668f54236e1d1acc8a8c24d436..0000000000000000000000000000000000000000
--- a/libs/stund/wnattest.bat
+++ /dev/null
@@ -1,40 +0,0 @@
-@echo off
-rem wnattest.bat
-if defined %4 (
- goto usage
-) else if defined %3 (
- goto start
-) else (
- goto usage
-)
-:start
-stunner %1 -i %2 -i2 %3
-if %errorlevel% == -1 (
- echo "ERROR! the STUN test program had an error" (
-) else if %errorlevel% == 10 (
- echo "[PASS] (Address) Restricted Cone NAT with Hairpinning"
-) else if %errorlevel% == 21 (
- echo "[PASS] Port Restricted Cone NAT with Hairpinning"
-) else if %errorlevel% == 8 (
- echo "[No NAT] You have open internet access"
-) else if %errorlevel% == 2 (
- echo "[FAIL] Your (Address) Restricted Cone NAT doesn't do hairpinning"
-) else if %errorlevel% == 3 (
- echo "[FAIL] Your Port Restricted Cone NAT doesn't do hairpinning"
-) else (
- echo "[FAIL] You have a NAT or Firewall type which is NOT RECOMMENDED. "
- if %errorlevel% LSS 8 (
- echo "It also does not support hairpinning"
- ) else (
- each "it does at least support hairpinning"
- )
-)
-goto end
-:usage
-echo Usage:
-echo wnattest <server-ip> <client-primary-ip> <client-secondary-ip>
-echo.
-echo Example: wnattest 1.1.1.2 192.168.0.2 192.168.0.3
-echo.
-:end
-